Re: [Acme] Secdir last call review of draft-ietf-acme-star-delegation-06

[Thomas Fossati <[e-mail]>]

Hi Russ,

Thanks very much for your clear and thorough review!

Your comments are now tracked in the following tickets:

On 14/03/2021, 22:02, "Russ Housley via Datatracker" <[e-mail]> wrote:
> Abstract: It says: "...  party access to a certificate associated with
> said identifier."  This is odd wording, and it is incorrect.  The
> party needs access to the private key that corresponds to the public
> key in the certificate, and the certificate needs to contain the
> subject for "said identifier".  Clearly, all of that should not go in
> the Abstract, but what does appear in the Abstract needs to be
> technically accurate.

https://github.com/yaronf/I-D/issues/139

> Section 1 says: "...   name matches the authority ...".  I find this
> description confusing.  I think it would be more clear to say that the
> cache server needs to present a certificate whose subject name matches
> the domain name of the URL that is requested.  The current wording is
> very easy to confuse name of the Certification Authority.

https://github.com/yaronf/I-D/issues/140

> Section 1 says:
>
>    While the primary use case we address is delegation of STAR
>    certificates, the mechanism proposed here accommodates any
>    certificate managed with the ACME protocol.  See Section 2.4 for
>    details.
>
> This is not much of a hint that long-term certificates are supported
> in addition to STAR certificates.  Further, a hint about the handling
> of revocation is appropriate here.  Support for long-lived
> certificates is in conflict with the title of the document.  Please
> adjust the title of the document accordingly.

https://github.com/yaronf/I-D/issues/141

> Section 2.3.2 says: "Besides, when delegation is for a STAR
> certificate, ..." (in four places in this section).  I find this part
> of the document structure a bit confusing.  Maybe it is the lask ot
> adequate warning about support for long-lived certificates.  Maybe it
> the the mixing of STAR certificate and long-lived certificate
> processing in one section.  I suggest that separate sections be used
> to present STAR certificate and long-lived certificate processing

https://github.com/yaronf/I-D/issues/142

> In Section 2.3.4, the text is begging for one more sentence.  Please
> say something about the fact that the STAR certificate will expire
> shortly after the automatic renewal process is stopped by the IdO.

https://github.com/yaronf/I-D/issues/143

> Section 2.4 is not sufficient to explain the revocation processing.
> Only the NDC has the private key needed to make the ACME revocation
> request, but this does not get stated in the text.  Also, it is not
> clear to me how the NDC knows where to send the revocation request
> since the IdO is the ACME account owner.  In addition, the phrase
> "would create a self-inflicted DoS" needs more explanation.

https://github.com/yaronf/I-D/issues/144

> Section 5.6 registers a string name for each extendedKeyUsage OID.
> There should be a way to provide the OID in dotted decimal format as
> well.  New OIDs are being assigned all the time, and some of them may
> not be registered with IANA.

https://github.com/yaronf/I-D/issues/145

> Section 5.6 registers a string name for each type of subjectAltName.
> This include otherName, which are identified by an OID.  New OIDs are
> being assigned all the time.  For example, draft-ietf-anima-autonomic-
> control-plane-30 creates a new otherName.  There should be a way to
> provide the the otherName OID in dotted decimal format as well.

https://github.com/yaronf/I-D/issues/146

> Minor Concerns:
>
> Abstract: Please spell out ACME, CDN, and STAR.  These are not marked
> as "well known" in the RFC Editor abbreviation expansion list.
>
> Section 1.1: Please change CA to "Certification Authority".  See
> Section 3 of RFC 5280.  This changes is also needed elsewhere in the
> document.
>
> Section 1.1: Please add CDNI, uCDN, dCDN, PASSPorT, CSR and FQDN to
> the list of terms.

https://github.com/yaronf/I-D/issues/147

> Section 1 describes [I-D.mglt-lurk-tls13] as an ongoing effort.  This
> is not accurate.  The LURK BoF did not lead to a WG or an effort in an
> existing WG.  I think the best way forward is to drop this reference.

https://github.com/yaronf/I-D/issues/148

> Nits:
>
> Section 2 says: "... in this draft ...".  Please use a work that will
> still be appropriate when this document becomes an RFC.
>
> Section 2.4: s/Sec. 7.6/Section 7.6/  (and many other places)

https://github.com/yaronf/I-D/issues/149

> IDnits reports:
>
>   ** There are 3 instances of too long lines in the document, the
>      longest one  being 4 characters in excess of 72.
>
>   == There are 4 instances of lines with non-RFC6890-compliant IPv4
>      addresses in the document.  If these are example addresses, they
>      should be changed.
>
> [I suspect these are not IPv4 addresses, but OIDs in dotted decimal.]

https://github.com/yaronf/I-D/issues/150

We'll be back to you as soon as we have addressed them or for further
clarifications, if needed.

Cheers, and thanks again.






IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.