OK; thanks again for taking the time for a nice explanation. I appreciate it, and it sounds like you have things in hand. We're good; carry on. :-)
Barry On Thu, May 30, 2019 at 9:52 PM Hugo Landau <[email protected]> wrote: > > > This all makes sense. Would it be reasonable to recommend not just > > "ca-", but "ca-<caidentifier>-"? Experience has shown that if "flarb" > > is a common thing among CAs (or whatever) and Verisign implements a > > "ca-flarb", that will tend to leak and become an unregistered > > standard... but that's far less likely to happen if it's > > "ca-verisign-flarb". I'm not suggesting any formalization nor > > registry for the <caidentifier> part, but just the fact that it's > > included tends to get us away from the problem that BCP 178 is > > addressing. > The important thing to consider is that these identifiers always occur > in a context scoped to a specific CA: > > example.com. IN CAA 0 issue "example.net; validationmethods=ca-foo" > > where example.net is some CA. So if you like, you can think of the > validation method expressed here as being the tuple ("example.net", > "ca-foo"). It's pretty much isomorphic to if, for example, one chose > URIs instead along the lines of validationmethod://example.net/foo. But > since all parameters on a CAA property are implicitly qualified by the > CA's domain, this seemed very overkill. > > It is possible that different CAs will allocate the same identifiers to > mean approximately the same thing — for example, if 10 different CAs > elected to use "ca-email" for generic non-ACME email-based domain > validation. They might also allocate the same identifiers to mean very > different things. The premise of the ca- prefix, however, is that an > entity requesting certificates is willing to establish a relationship > with a CA in a non-automated fashion. In this case, that means reading a > CA's documentation on supported validationmethods identifiers and > understanding their semantics. > > I think this is reasonable since people don't change CAs frequently or > automatically, or at least in the non-ACME cases. With ACME things can > be automated much more — and in that case, the validationmethods > identifiers used are fully standardised. > > So "identifier cross-pollination" between CAs is I think a non-issue. > What I think you're trying to express is the possibility that e.g. > Verisign has some method "ca-foo" and Digicert has some very different > method also called "ca-foo", and at some point Digicert wants to let > people refer to Verisign's "ca-foo" method. > > But reusing the same identifier isn't useful for the reasons given > above; switching CAs in the non-ACME case is necessarily a manual > process and will necessitate having some understanding of a CA's > published (natural language) policies. > > Moreover, enabling CAs to reference validation method identifiers used > by other CAs would undermine the point of the prefix, which is to be > explicitly local to the specific CA whose domain is given. > > Perhaps most seriously though, this would make the first CA vulnerable > to the possibility that the second CA subseqently changes their policy > for the given identifier. In practice, CAs are extremely unlikely to > want to create policy dependencies on other legal entities like this. It > would be tantamount to a CA's CPS section on validation saying "We do > the same thing Verisign does." > > So, if anything I think a scheme such as "ca-verisign-foo" is riskier. > > > > The CAA specification allows parameters to be attached to CAA > > > properties, but this is a CA-specific namespace. Per CAA, there is no > > > IANA registry for CAA parameters, and a CA is not required to give the > > > meaning given in this I-D to "accounturi" or "validationmethods" > > > parameters, unless it chooses to implement this RFC. See "Restrictions > > > Ineffective without CA Recognition". > > > > OK; no longer a DISCUSS, and no need for further response, but if you > > can re-word that to explain the situation a bit better, that'd be > > great. > Tweaked it a little. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
