> > 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
