I have a few comments. Only one of them will be difficult to sort out.
Section 1, para 1: Please add a cite to [RFC5280] after "X.509 (PKIX)
certificate".
Section 1, last para: Please reword. Something like:
Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a
useful optimization when ACME is used to issue certificates for large
numbers of devices; it reduces the domain ownership proof traffic as
well as the ACME traffic overhead. This is accomplished by completing
a challenge against the parent domain instead of a challenge against
each explicit subdomain. Use of ACME for subdomains is not a
necessary requirement.
Section 2: Please add a reference for CSR. Consider [RFC2986].
Section 2: Please add a reference for RA. Consider [RFC5280].
Section 2: Please add a reference for TLV. Consider [RFC7170].
Section 4: Please fix the markdown typo: Refer to section {csr-attributes} for
more details.
Section 7.2 says:
EST [RFC7030] is not clear on how the CSR Attributes response should
be structured, and in particular is not clear on how a server can
instruct a client to include specific attribute values in its CSR.
[I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can
use CSR Attributes response to specify specific values for attributes
that the client should include in its CSR.
Servers MUST use this mechanism to tell the client what identifiers
to include in CSR request. ...
This is a MUST, but is is not really nailed down. Can we get to a simple MUST
statement here? If not, can we at least narrow the possibilities?
Section 7.2: s/The identifier must/The identifier MUST/
Section 7.3: s/certificate MAY be omitted from the chain/certificate SHOULD be
omitted from the chain/
Section 7.3.2: Please provide references for PKCS#7 and PKCS#10.
Section 7.4: s/id-kp-cmcRA extended key usage bit/id-kp-cmcRA extended key
usage OID/ (multiple places)
Russ
> On May 26, 2022, at 6:58 AM, Deb Cooley <[email protected]> wrote:
>
> Title: ACME Integrations
>
> Authors: O.Friel, R.Barnes, R. Shekh-Yusef, M.Richardson
>
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/
> <https://datatracker.ietf.org/doc/draft-ietf-lamps-8410-ku-clarifications>
>
> This document outlines multiple advanced use cases and integrations that ACME
> facilitates without any modifications or
> enhancements required to the base ACME specification. The use cases include
> ACMEintegration with EST, BRSKI and TEAP.
>
> Please respond to this WG last Call by 9 June 2022.
>
> For the ACME WG Chairs,
> Deb
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
