Re: [Acme] WG Last Call for draft-ietf-acme-integrations-07

["Owen Friel (ofriel)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Deb Cooley
Sent: Thursday 16 June 2022 18:36
To: IETF ACME <[e-mail]>
Cc: Dorothy E Cooley <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Russ Housley <[e-mail]<mailto:[e-mail]>>
Date: Thursday, May 26, 2022 at 10:25 AM
To: Deb Cooley <[e-mail]<mailto:[e-mail]>>, Dorothy E Cooley <[e-mail]<mailto:[e-mail]>>
Cc: IETF ACME <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/acme

_______________________________________________ Acme mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/acme