Just for context here: I think the original operating model for CAA was that the CA would tell the customer what values to put in there in order to authorize issuance. So it was safe to use arbitrary values because it was basically a closed loop CA -> Customer -> CAA -> CA.
Nonetheless, I sympathize with your point here. With ACME, we're moving things in a more standardized / automated direction, so we can automate out some of the CA interaction around CAA if we standardize some values. Note that the ACME challenge type values are already registered. Would it be sufficient to say something like "Tokens registered as ACME challenge types MUST NOT be used to identify non-ACME validation methods"? --- This reminds me a related point that I forgot in my initial review. It would be nice if it were possible to specify a validation method policy independent of CA. So I wouldn't have to authorize each CA I interact with individually, but I would be able to say "Only validate my domains using dns-01". In fact, is there any reason to have different validation methods per CA? It's a property of the domain owner / certificate applicant, not the CA. Is there a reason you would trust CA X to do "http-01" but not CA Y? (I totally understand why "account-uri" is CA-specific, though.) I would suggest pulling out "validation-methods" from being an attribute to being a "tag" / "property", parallel to "issue" and "issuewild". On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > I support moving forward with the document. > > However I think the treatment of the acme-methods (or validation-methods) > param is inconsistent, before and certainly after Richard's PR. The > original draft only allows ACME methods and the special name "non-acme". > This leaves the responsibility to ensure names are well defined with the > IETF. > > If we allow mixing ACME methods with CA-defined methods per Richard's > proposal, we should make sure that there is no overlap. And even if names > are defined by individual CAs, the CA should provide a precise definition > of each validation method. IMO there are two good options: > > - Define an IANA registry for the validation-methods values. (This is > simple enough, and would be my preference). > - Define an IANA registry for prefixes (such as "cabf" mentioned in > Richard's text) and specify that everything else must be defined by ACME. > > Thanks, > Yaron > > > > https://github.com/ietf-wg-acme/acme-caa/pull/2 >> >> On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich <rs...@akamai.com> wrote: >> >> There's no listing going on here, since there's no registry for the >>>> >>> values. CABF could put tokens in their documents if they like. >>> >>> Okay, please propose wording (or did you? Sorry if so) to change for the >>> CAA draft. >>> >>> >>> >> > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
