[Acme] Barry Leiba's No Objection on draft-ietf-acme-caa-07: (with COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

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

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/



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

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

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.

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.

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

No longer a DISCUSS, and no need for further response, but if you
can re-word this to explain the situation a bit better, that'd be
great.

---------------------------------------------

=== These have been resolved and/or explained; thanks for that ===

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

(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