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]> 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]> on behalf of Russ Housley < > [email protected]> > *Date: *Thursday, May 26, 2022 at 10:25 AM > *To: *Deb Cooley <[email protected]>, Dorothy E Cooley < > [email protected]> > *Cc: *IETF ACME <[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]> 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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
