x- prefixes were for experimental. They are bad because they inevitably fail. either the experiment fails and is forgotten or it succeeds and all the software has to check for both in perpetuity. Its just bad. Do not do.
acme-foo acme-bar etc. Is a totally different proposition. That is a good thing provided that you don't go expecting the software to treat these as anything other than opaque labels. As it won't. On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau <[email protected]> wrote: > > > https://github.com/ietf-wg-acme/acme/pull/332 > Alright, if the ACME spec wants to genericise its validation methods > registry, I'm okay with the validation-methods change as-is. > > Questions: > > 1. Should we drop "non-acme", since any non-ACME method can have its own > identifier listed? I think probably. > > 2. An ACME validation method, such as http-01, can only be used in the > context of using ACME. Conversely, should non-ACME validation methods > only be usable in non-ACME contexts? > > For example, suppose someone registered a "cabf-dv-http" validation > method generically referring to CABF-compliant HTTP-based DV. > If someone wants to use ACME, they can list http-01 specifically, > so I think ACME CAs should ignore method specifiers like this. > These method names would be applicable solely to non-ACME CAs. > > (This is sort of implied already by the subtext that an act of > validation has exactly one validation method name applicable to it, > but we could be clearer about this.) > > > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather > than a prefix, really that useful? > > RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific > prefixes like domain names are still OK. So we could amend the ACME > specification allowing challenge method names of the form > "[email protected]", say (this is inspired by SSH capability names). This > would have utility for vendors both in and outside of the context of > ACME-CAA. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
