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

[Hugo Landau <[e-mail]>]

> 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.