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 <carl@redhoundsoftware.com>
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 <acme-bounces@ietf.org> on behalf of Russ Housley <
> housley@vigilsec.com>
> *Date: *Thursday, May 26, 2022 at 10:25 AM
> *To: *Deb Cooley <debcooley1@gmail.com>, Dorothy E Cooley <
> decoole@radium.ncsc.mil>
> *Cc: *IETF ACME <acme@ietf.org>
> *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 <debcooley1@gmail.com> 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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
>
> _______________________________________________ Acme mailing list
> Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
>