Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
draft-ietf-acme-caa-10

Thank you for addressing my DISCUSS position.

Hugo, thank you for the work put into this document. Adding some examples was a good idea.

I found it interesting that the security section represents roughly 50% of the document ;-)

I have two comments and one nit. See below.

== COMMENTS ==


-- Section 2 --

Please use RFC 8174 boiler template for this section ;-)

-- Section 3 --

The word 'applicable' is used but never strictly defined. If defined in another document, please add a reference (perhaps in the section 2), else please define it.

== NIT ==

-- abstract --

Expand CAA, CA in the abstract ?

Thanks to everyone who worked on this extension.

I support Barry's first DISCUSS point.  Beyond that concern, I have only one
comment.

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

§5.4:

>  Suppose that both CA A and CA B issue account URIs of the form
>
>  "account-id:1234"

This is a little concerning as an example, as "account-id" isn't a registered
URI scheme. Consider instead using:

  urn:example:account-id:1234

(1) I can't claim to fully understand the contents of this document.  However, I find the use of Normative language in the following sentence in the IANA Considerations confusing: "This document merely specifies a RECOMMENDED semantic for parameters..."

First of all, there's nothing that can be Normatively enforced in that piece of text.  Second, Sections 3-4, where the parameters are specified, are the appropriate place for the Normative specification.

Solution: s/RECOMMENDED/recommended

(2) I don't think that there's a significant impact, or any at all...but it seems to me that this document should reference draft-ietf-lamps-rfc6844bis instead of RFC6844.

— 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

Thanks for addressing my Discuss (and Comment!) points!

While adding the discussion of  the privacy considerations of publishing account URLs
suffices to clear my discuss point, I will mention that if we wanted to obscure or anonymize
the published information relating to specific account, there are pretty standard ways to
do so and I'm happy to talk about it if that's desired.