Note: This ballot was opened for revision 06 and is now closed.
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.
Thank you for addressing my DISCUSS position.
— 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
(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.
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
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 ?