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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Sun, 26 May 2019 08:02:07 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-acme-caa-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-caa/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

— Section 4 —

   If appropriate non-ACME identifiers are not present in the
   ACME Validation Methods IANA registry, the CA MUST use identifiers
   beginning with the string "ca-", which are defined to have CA-
   specific meaning.

Was the working group aware of BCP 178 (RFC 6648), and did they consider the
“ca-“ prefix in that context?  If so, how does the working group propose to
avoid the problems outlined by BCP 178?

— Section 5.4 —

   CAs MUST satisfy this requirement by using URIs which include an
   authority:
   "https://a.example.com/account/1234"

First (this is not the DISCUSS part), readers who are not extremely familiar
with how URIs are constructed — and given that “authority” is a normal English
word with a meaning outside the URI world — might not really understand what
you mean here.  A reference will help, and I suggest it” “…include an authority
(see Section 3.2 of [RFC3986])”.

Second (this is the DISCUSS part), does this mean that all CAs MUST use URIs
that include an authority?  Or does it only apply to those with the sort of
situation you describe in this section?  If the latter, it seems odd that
you’re prescribing, at MUST level, a particular solution, where there are
certainly others (such as ensuring that the account numbers are unique in the
first place).

— Section 6 —
I have no idea what you’re trying to say here.  This is a Proposed Standard,
right?  It defines two new parameters.  Are you now trying to say that we have
not really defined anything?  I don’t understand.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(General: I hope the RFC Editor will be changing most “which” in this document
to “that”, according to the Chicago Manual of Style, but I’ll let the RFC
Editor address those.)

(Also general: For a very short document, this was quite a difficult read. 
There are quite a few very long, heavy, hard-to-parse sentences, with lots of
things run together.  While the sentences are grammatically correct, they’re
harder on the reader than they ought to be.  Picking one of many as an example:

   Because CAA records are located during validation by walking up the
   DNS hierarchy until one or more records are found, the use of the
   "accounturi" and "validationmethods" parameters, or any CAA policy,
   is not an effective way to restrict or control issuance for
   subdomains of a domain, where control over those subdomains is
   delegated to another party (such as via DNS delegation or by
   providing limited access to manage subdomain DNS records).

That’s one sentence.  The document in general would benefit from breaking up
those sorts of sentences to make it easier to get the sense of what it’s trying
to say.  For example, the above might go something like this:

   CAA records are located during validation by walking up the
   DNS hierarchy until one or more records are found. Sometimes,
   control over subdomains of a domain is delegated to another
   party — via DNS delegation, or by providing limited access to
   manage subdomain DNS records.  In those cases CAA policy,
   including the use of the "accounturi" and "validationmethods"
   parameters, is not an effective way to restrict or control
   issuance for subdomains.
)

— Section 3 —

   "CA account" means an object maintained by a specific CA representing
   a specific entity, or group of related entities, which may request
   the issuance of certificates.

I’m not clear on what the “which” clause goes with:

1. Do you mean that the “specific CA” may request the issuance?
2. Do you mean that the entity or group of entities may request it?
3. Do you mean that the object may be used to request the issuance?

Some of this confusion might come from the that/which issue, but I think it’s
really the structure of the sentence.  I suggest that you re-word the sentence
to make it clearer.  Maybe (assuming (2) above is correct):

NEW
   A “CA account” is an object maintained by a specific CA, representing
   a specific entity or group of entities.  Those entities may request the
   issuance of certificates from that CA.
END

   A property with multiple "accounturi" parameters is
   unsatisfiable.

OK, but why not say, then, that there MUST NOT be multiple “accounturi”
parameters in a given property?

— Section 3.2 —

   The use of specific kinds of URI may be specified in future RFCs, and
   CAs not implementing ACME MAY assign and recognise their own URIs
   arbitrarily.

Isn’t this true of CAs that do implement ACME also?  The “MAY” in Section 3.1
implies that, surely.

-- Section 5.3 —

   A CA which is unable to ensure consistent processing of the
   "accounturi" or "validationmethods" parameters for a given CA domain
   name as specifiable in CAA "issue" or "issuewild" properties MUST NOT
   implement support for these parameters.  Failure to do so will result
   in an implementation of these parameters which does not provide
   effective security.

“Failure to do so” seems odd after “MUST NOT”.  It also makes it sound as
though failure to comply with a MUST NOT is an option.  I suggest, “Otherwise,
the CA would have an implementation…”

— Section 5.8 —

   Because they express a restrictive security policy, misconfiguration
   of the "accounturi" or "validationmethods" parameters may result in
   legitimate issuance requests being refused.

As written, “they” goes with “misconfiguration”, which is clearly not what you
meant (I think you mean it to refer to “the … parameters”).

NEW
   Because the "accounturi" or "validationmethods" parameters express
   a restrictive security policy, misconfiguration of them may result
   in legitimate issuance requests being refused.
END

---

From: Hugo Landau <[email-masked]>
Date: Thu, 30 May 2019 18:42:30 +0100

Yes.

All of these identifiers are already scoped to a specific CA via a
domain name, due to the nature of the CAA specification. The CAA
specification also provides that parameters in general are a CA-specific
namespace.

The core complaint of RFC 6648 is that nonstandard values tend to
graduate to being standard values, and at that point need to be renamed.

Because "ca-" methods are CA-specific and unrelated to ACME, it is
essentially necessary that they be configured in relation to, and in
knowledge of, a specific CA and its issuance and validation practices.
In this regard it is not the same concept as an X- prefix, which defines
nonstandard parameters in the vague hope that such parameters will be
adopted by numerous implementations and entities across the net. This is
a permanent reservation for CA-specific meaning and there is no
expectation that one CA's "ca-foo" method is the same as another CA's
"ca-foo" method.

This reservation is necessary because a CA may engage in both ACME and
non-ACME issuance, so there is an unavoidable need to be able to
communicate about both. However, there are likely to be as many non-ACME
validation methods as there are CAs (more, actually), and seeking to
register all of these in the ACME Validation Methods registry would be
both impractical and out of scope for the ACME WG.

> (see Section 3.2 of [RFC3986])”.
Done.

> certainly others (such as ensuring that the account numbers are unique in the

  Thus, CAs MUST ensure that the URIs they recognise as pertaining to a specific
  account of that CA are unique within the scope of all domain names which they
  recognise as identifying that CA for the purpose of CAA record validation.

  CAs MUST satisfy this requirement by using URIs which include an authority (see
  Section 3.2 of {{RFC3986}}):

I agree that the second MUST should be changed to SHOULD here.

> not really defined anything?  I don’t understand.
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".

Changed to

  CAA records are located during validation by walking up the DNS
  hierarchy until one or more records are found. CAA records are
  therefore not an effective way of restricting or controlling issuance
  for subdomains of a domain, where control over those subdomains is
  delegated to another party (such as via DNS delegation or by providing
  limited access to manage subdomain DNS records).

>    issuance of certificates from that CA.
The third meaning was intended. Changed to:

  "CA account" means an object, maintained by a specific CA and which may request
  the issuance of certificates, which represents a specific entity or group of
  related entities.

> parameters in a given property?
This specifies how properties are to be processed, not generated. Even
if a normative prohibition were to be added here, this sentence would
remain necessary.

> Isn’t this true of CAs that do implement ACME also?  The “MAY” in Section 3.1
The MAY in section 3.1 confers an option for identifying an ACME account
object.

The MAY in section 3.2 confers an option for identifying entities which
may or may not be ACME account objects.

> the CA would have an implementation…”
s/will/would/

>    in legitimate issuance requests being refused.

Changed to:
  Because the "accounturi" and "validationmethods" parameters express restrictive
  security policies, misconfiguration of said parameters may result in legitimate
  issuance requests being refused.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 30 May 2019 20:22:26 +0100

Thanks, Hugo; this is all good, and thanks for the response.  I'll
clear the DISCUSS, though I still would like to discuss the "ca-"
thing a little more.  But the main point is that the BCP was known and
considered, and the working group made an informed choice.

> expectation that one CA's "ca-foo" method is the same as another CA's

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.

Again, this is no longer at DISCUSS level, and if the working group
thinks this isn't a good idea, go ahead as planned.  But please chew
it over a bit and see if you can swallow it.

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

Thanks again,
Barry

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 30 May 2019 19:23:46 +0000

Thanks for the review and feedback, Barry.

Hugo, please post a new draft with your proposed changes; nothing there seems other than editorial clarifications.

---

From: Hugo Landau <[email-masked]>
Date: Thu, 30 May 2019 21:51:50 +0100

> included tends to get us away from the problem that BCP 178 is
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.

> can re-word that to explain the situation a bit better, that'd be
Tweaked it a little.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 30 May 2019 22:32:53 +0100

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

---

From: Hugo Landau <[email-masked]>
Date: Fri, 31 May 2019 01:33:30 +0100

Done.