Hi, There were 12 individual comments/issues raised. I tracked them all as separate github issues. 10 have been addressed and fixes checked into https://github.com/upros/acme-integrations. There are only two outstanding issues, and we are noodling over the correct text. Expect an update in the next couple of days and draft-ietf-acme-integrations-08 to be pushed. Thanks for the detailed comments. Owen
From: Acme <[email protected]> On Behalf Of Deb Cooley Sent: Thursday 16 June 2022 18:36 To: IETF ACME <[email protected]> Cc: Dorothy E Cooley <[email protected]> Subject: Re: [Acme] WG Last Call for draft-ietf-acme-integrations-07 Thanks for the two reviews w/ comments. When the authors have addressed the comments, we can issue a short WGLC. For the ACME chairs, Deb Cooley On Fri, May 27, 2022 at 9:44 AM Carl Wallace <[email protected]<mailto:[email protected]>> wrote: I’ll reply here to add one comment. The introduction of the potential for errors due to domains the RA is authorized for and those may be requested is not called out to any extent. It is likely something that is mostly addressed by authentication to the RA and could be noted as such in section 7.1. Section 7.5 gets at the issue with the mapping for badIdentity, but it could be called out as something that occurs upon submission of request to the RA (vs mapping an ACME error back to the protocol of interest after failed interaction with the ACME server). From: Acme <[email protected]<mailto:[email protected]>> on behalf of Russ Housley <[email protected]<mailto:[email protected]>> Date: Thursday, May 26, 2022 at 10:25 AM To: Deb Cooley <[email protected]<mailto:[email protected]>>, Dorothy E Cooley <[email protected]<mailto:[email protected]>> Cc: IETF ACME <[email protected]<mailto:[email protected]>> Subject: Re: [Acme] WG Last Call for draft-ietf-acme-integrations-07 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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
