> [1]https://github.com/ietf-wg-acme/acme-caa/pull/2
1. I'm not sure what the point of changing "acme-methods" to "validation-methods" is. It still has the "non-acme" value, so it's clearly defined in relation to ACME. (Even if it wasn't, how is this namespace supposed to be defined? Should an IANA registry be requested rather than reusing the ACME validation methods registry? If so, it creates the possibility of divergence between the ACME methods registry and the validation methods registry. That, in turn, could be solved via some sort of inheritance between the two registries, but that would require changes to the ACME validation method registry, insofar that if someone registers string X in the ACME-CAA validation method registry for something unrelated to ACME, string X cannot thereafter be registered as an ACME validation method. Since this would restrain the ACME validation methods registry, consent would need to be obtained for this.) I see some of these concerns have already been mentioned. The prefix registry proposal works: Have an "acme" prefix which accesses the ACME validation methods namespace, e.g. "validation-methods=acme:dns-01,acme:tls-sni-02,cabf:foo". There could be an "unknown" value which would represent any validation method without an assigned identifier - but now that I think about it, since this structure would enable all parties to assign identifiers to even legacy validation methods, that seems like an unnecessary footgun. Vendor-assigned identifiers could be supported as such: vnd:example.com/custom-method But now we're reinventing URIs. So perhaps we should just switch to URIs and define an URN mapping for ACME validation methods. I'd support that. To summarise, I think we should keep "acme-methods" (and rely on the extensibility of CAA at the parameter level where non-ACME validation method constraints are to be expressed) or replace it with "validation-methods" taking a list of URIs (and defining a mapping from ACME validation method names to URNs). 2. Adding a reference to CABF is weird because it references a policy body. This is quite orthogonal to the IETF's mission, and these things should probably be kept separate. Since all commercial CAs need to be aware of the requirements of the CA/Browser forum anyway, the utility of this statement seems to be zero, and unnecessarily politicises the standard (for some value of politics). 3. Changing CA A to CA X, etc. is fine. (Splitting this up into multiple PRs would probably be desirable.) _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
