An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates
RFC 9115
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Roman Danyliw Yes
Alvaro Retana No Objection
Erik Kline No Objection
[ section 2.1 ] * I know it's a list of prereqs, but I was wondering if "NDC is required" might want to be "NDC is REQUIRED".
Francesca Palombini (was Discuss, No Objection) No Objection
Thank you for addressing my DISCUSS and the non blocking comments (archived at https://mailarchive.ietf.org/arch/msg/acme/KojTzwwWZrWnOI7bCErfeJq_YVk/ ). Thanks again to Carsten Bormann and Richard Barnes for their reviews! Francesca
Lars Eggert (was Discuss) No Objection
Section 1, paragraph 8, comment: > We note that other ongoing efforts address the problem of certificate > delegation for TLS connections, specifically [I-D.ietf-tls-subcerts] > and [I-D.mglt-lurk-tls13]. Compared to these other solutions, the > current document does not introduce additional latency to the TLS > connection, nor does it require changes to the TLS network stack of > either the client or the server. This paragraph should probably be removed upon publication as an RFC? ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 3.1, paragraph 10, nit: - e.g. by restricting field lengths. In this regard, note that a + e.g., by restricting field lengths. In this regard, note that a + + Section 4.1, paragraph 3, nit: - This section uses specifically CDNI terminology, e.g. "uCDN" and + This section uses specifically CDNI terminology, e.g., "uCDN" and + + Section 4.1.2.1, paragraph 5, nit: - Unlike HTTP based redirection, where the original URL is supplanted - ^ + Unlike HTTP-based redirection, where the original URL is supplanted + ^
Martin Duke No Objection
Murray Kucherawy No Objection
I support Lars' DISCUSS about the IANA Considerations.
Robert Wilton No Objection
Zaheduzzaman Sarker No Objection
I support Ben's discuss and by doing this I also support Francesca and Lars's discuss.
Éric Vyncke No Objection
Thank you for the work put into this document. The usefulness of this specification is clear and important! Special thanks for the doc shepherd's write-up as it writes about the WG consensus/discussion. Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- Should "delegated identifier" be more defined ? Honestly, after reading the abstract, I have no clue... -- Section 1 -- In "This document is a companion document to [RFC8739]" is "companion" the right word? I am not a native English speaker but "companion" sounds like the fates of two documents are bound together, suggest to use "complements" ? In the abstract CDN is just a use case while, in this introduction section, it is the main goal. Please expand "NDC" at first use ? Perhaps moving section 1.1 earlier ? "We note that other ongoing efforts address the problem of certificate delegation for TLS connections, specifically [I-D.ietf-tls-subcerts] and [I-D.mglt-lurk-tls13]." I am trusting the responsible ADs (SEC & TSV) about having 2+ competing IETF standards... -- Section 2 -- It is a little unclear whether there is one NDC (one per CDN) or multiple NDC (one per edge-cache). The latter could have scalability issues. Section 1.1 seems to indicate the former but it may be ambiguous. -- Section 2.3.1.2 -- As I am not an expert in CDN, I wonder whether the example entry for 'cname-map' is correct? (I would have used "abc.ido.ndc.example." as the value). == NITS == -- Abstract -- s/This memo defines/This document defines/ AFAIK, the 'memo' wording was used back in the XXth century ;-) -- Section 1.1 -- s/symmetry/similarity/ ?
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thanks for the (extensive!) changes to resolve my previous review remarks!
Just a few notes left from looking at the diff between -07 and -08:
Section 2.3.1.3
In order to indicate which specific delegation applies to the
requested certificate a new "delegation" attribute is added to the
Order object on the NDC-IdO side (see Figure 4). The value of this
We might want to get the phrase "request object" in here somehow, since
we go on to talk about returning an error response, which is of course
only possible if there is a corresponding request. (The next section
does talk about the "request object created by the NDC").
Section 2.3.2
If the delegation is for a STAR certificate, the request object
created by the NDC:
[...]
* MUST have entries in the "identifiers" field for each delegated
name present in the configuration;
Just to confirm: this is saying that the request/order must request a
certificate for all names covered by the delegation; it cannot request
only a subset of the names in the particular delegation object? On
first read this seems a bit restrictive, but I suppose it can make state
handling at the IdO easier since the information from the delegation
object can be used to construct the request to the actual CA.
(Similarly for the non-STAR case in §2.3.3, of course.)
The example delegation URL in Figure 4 doesn't match the URL structure
used for the example delegation list in Section 2.3.1.2. (This is not
inherently problematic, but could cause a small amount of reader
confusion.) The same identifier occurs in several subsequent figures,
as well.
Section 2.4
[Just noting that the text about the IdO being able to decide on a
per-identity basis whether to proxy vs act as IdO remains confusing to
me, but this is the same comment I made on the previous version and I
expect no further changes to be made and no further discussion on the
topic.]
Section 3
Although most of this document, and in particular Section 2 is
focused on the protocol between the NDC and to IdO, the protocol does
affect the ACME server running in the CA. A CA that wishes to
support certificate delegation MUST also support unauthenticated
Is it correct to say "non-STAR certificate delegation" here? (The
corresponding change needed to support STAR delegation would have been
done already to support non-delegated STAR issuance, if I understand
correctly.)
Section 7.2
The ACME account associated with the delegation plays a crucial role
in the overall security of the presented protocol. This, in turn,
means that in delegation scenarios the security requirements and
verification associated with an ACME account may be more stringent
than in traditional ACME, since the out-of-band configuration of
delegations that an account is authorized to use, combined with
account authentication, takes the place of the normal ACME
authorization challenge procedures. Therefore, the IdO MUST ensure
that each account is associated with the exact policy (via a
"delegation" object) that defines which domain names can be delegated
to the account and how. The IdO is expected to use out of band means
to pre-register each NDC to the corresponding account.
Please double-check and confirm that the singular 'policy' and
'"delegation" object" are as intended here. IIRC we do allow multiple
delegation objects to be associated with a single account.
(Martin Vigoureux; former steering group member) No Objection