Subject: [Acme] Comments on draft-ietf-acme-integrations

From: Russ Housley <[email-masked]>
Date: Mon, 2 Aug 2021 15:20:12 -0400

During the IETF 111 session, I agreed to review draft-ietf-acme-integrations.  I have a few comments.

MAJOR:

Sections 3, 4, 5, and 7.2 seem to have a misunderstanding of EST CSR Attrs, which were recently explained by Dan Harkins on the LAMPS WG mail list:

	https://mailarchive.ietf.org/arch/msg/spasm/Rr2H6WNEKeRphQ065sEoQ0rGTac/

Dan says, "The intent of the CSR Attrs request is for the RA to ask the client to construct the CSR in some particular way."

This portion of all of these sections need to be reconciled with this understanding of EST CSR Attrs. In fact, BRSKI (RFC 8995) will probably need to be updated to reconcile the specifications.

EDITORIAL:

Section 1, first para: please add a reference to RFC 5280 after "X.509 (PKIX) certificate".

Section 1, last para: s/certificate authority/certification authority (CA)/

Section 2: For CMC, please add a reference to RFC 5272, RFC 5273, RFC 5274 and RFC 6402.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Aug 2021 16:07:05 -0400

> Sections 3, 4, 5, and 7.2 seem to have a misunderstanding of EST CSR
    > Attrs, which were recently explained by Dan Harkins on the LAMPS WG
    > mail list:

In light of this, I agree.

We will have to figure out how to communicate to the client/pledge the
desired subjectAltName.   This part is inherited from RFC8995.

In the meantime, do you have any other major comments/concerns?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Aug 2021 16:34:54 -0400

> In the meantime, do you have any other major comments/concerns?

My point is that we need to make the handling of CSR Attrs consistent all of these specifications, and a deeper dive into this document is not useful until that higher-level approach is figured out.

Russ