Re: [Acme] Barry Leiba's Discuss on draft-ietf-acme-caa-07: (with DISCUSS and COMMENT)

[Barry Leiba <[e-mail]>]

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 <[e-mail]> 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.