On Wed, Jul 5, 2017 at 5:48 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
> The problem with saying "Tokens registered as ACME challenge types MUST > NOT be used to identify non-ACME validation methods" is that ACME might > want to come up with additional method names in the future, and those just > might happen to conflict with methods that have been used by other > organizations in the meantime. This is exactly the kind of mess that IANA > is designed to prevent. > > A simple way to go around this issue is if we changed the draft to use > "acme-dns-01" instead of "dns-01" and similarly for all ACME methods. Then > we COULD say that non-ACME CAs MUST not use "acme-*" methods. > You could also set aside a vendor prefix (e.g., "vnd-", "ca-") that ACME stuff would be ruled out of. But your proposed solution seems better to me in light of the lessons of of RFC 6648. https://tools.ietf.org/html/rfc6648 > To your second point, many enterprise users will want the extra security > of "use this specific CA AND only with this method". There are probably > other use cases though. > I was about to say that such users could just specify an "issue" directive and a "validation-methods" directive, but the CAA spec is actually unclear on how the rules combine. I suppose that's because CAA right now is really only a CA whitelist, so there's no need for combining. If we want the CAA "tag" space to be extensible, it seems like there needs to be an update to the CAA spec to decide this. ISTM the conservative rule would be "You must satisfy one rule of each tag type; if you don't understand a tag type, don't issue". That would create the semantic I mention above. That part should probably go into a separate minor update spec, though, not in this spec. --Richard > > Thanks, > > Yaron > > > On 06/07/17 00:17, Richard Barnes wrote: > >> 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 >> <mailto: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 >> <https://github.com/ietf-wg-acme/acme-caa/pull/2> >> >> On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich <rs...@akamai.com >> <mailto: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 <mailto:Acme@ietf.org> >> https://www.ietf.org/mailman/listinfo/acme >> <https://www.ietf.org/mailman/listinfo/acme> >> >> >> >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
