Hi Mike, Thank you for your review!
I am hoping we get some additional feedback in the session on who will use this draft. Anecdotally, a few have expressed interest in this extension for their use cases. On Mon, Jul 21, 2025 at 1:01 PM Mike Ounsworth <Mike.Ounsworth= [email protected]> wrote: > Hi ACME! > > > > I provide this review as an individual, with my Chair-Hat off. I will > start a separate thread to provide some Chair's questions / comments on how > to progress this adopted draft. > > > > Document / version reviewed: draft-ietf-acme-client-13 > > > > > > The goal of this document seems to be to extend ACME to support cert > enrollments where control of the requested identifiers cannot be verified > in an automated way in-band in the ACME protocol; particularly, this seems > to be in support of issuing certs to cloud workloads and is a > building-block for the WIMSE WG. Specifically, this draft adds > authentication challenges to ACME: OTP, Client Cert, and WebAuthn. > Yes, so you have initial authentication to set up the ACME certificate management and I have heard the WebAuthn and PKI would be useful. I'm not certain about the OTP as things have changed since 2019. > > > I think this is a reasonable goal, but I don’t think the current draft > articulates this particularly well; it took me until Section 7 to realize > that’s what it’s doing. > > So, I suggest that this draft re-brand itself to make the core content > clearer. > > > > I would change the title to “ACME Client Authentication Challenges”, or > something similar. > I am fine with this change. > > > I suggest the abstract be changed > > OLD: > > Abstract > > > > Automated Certificate Management Environment (ACME) core protocol > addresses the use case of web server certificates for TLS. This document > extends the ACME protocol to support service account authentication > credentials, micro-service accounts credentials, device client, code > signing, document signing certificates and keys. > > > > NEW: > > Abstract > > > > Automated Certificate Management Environment (ACME) core protocol > addresses certificate issuance use cases where identity proofing can be > performed inline, for example verifying > Did you mean online instead of inline? > control of a DNS record or HTTP endpoint. In cases where identity proofing > is performed out-of-band, then the ACME protocol merely needs to > authenticate the certificate requester. This document extends the ACME > protocol to add OTP, PKI and WebAuthn based authentication Challenges that > give a CA greater flexibility in how it authenticates the ACME client. > > > > I would suggest re-structuring the Intro to start by cleanly defining the > terms “identity proofing” and “authentication”; explaining that the > Challenge types in RFC8555 only address inline and automatable identity > proofing; this draft extends ACME to cover certificate issuance cases that > cannot do inline identity proofing by adding Authentication Challenge types > so that an ACME Server can authenticate this request against the same > entity who had previously performed identity proofing via some other means. > I can scope down the text. Identity proofing does not occur with all credential types, it depends on the account type and the policy surrounding it. Identity proofing may be off-line (in person checking of physical credentials such as a license) or on-line. I'll think about how to write this concisely. > > I would remove the entire sections on Code Signing and Document Signing > since I think that’s a distraction from the core of the draft – I would > turn them into a passing “Motivating use cases” paragraph in the Intro. The > CSR discussion in these sections is confusing; it says “CSR MUST be set to > the correct values for the CA”, but my understanding of RFC8555 – > particularly the /new-order – is that the CSR is only a container for the > public key, and all the actual metadata (requested identifiers, requested > cert lifetime) go in the JSON body of the /new-order, so I’m not sure what > “correct values” the CSR is supposed to contain? I also worry that some of > the normative stuff in the Code Signing and Document Signing sections could > come into conflict with CA/B Forum or ETSI requirements for Code Signing > and Document Signing certs, so maybe best to just not go there and focus > this draft on the OTP, Client Cert, and WebAuthn authentication mechanisms > that it’s adding. > Do we have additional input on this before I remove sections as the document signing section was just requested by another reviewer? It doesn't matter to me as the challenge types are distinct from the certificate types requested using the ACME protocol. > > > I think the draft’s Introduction and Security Considerations needs some > discussion that this draft changes the philosophical nature of the ACME > protocol – whereas the Challenge types in RFC8555 are all focused on > establishing proof-of-control of a reachable identifier (DNS Name or email > address), this draft moves all of that out-of-band and actually brings the > ACME protocol closer to existing PKI enrollment protocols in terms of > functionality offered (CMP, EST, CSR-pasted-into-webpage, etc). > I'd like some more input here as I think this boils down to recent views on ACME versus the initial work in 2018/2019. These added controls, especially when policy ties it to an in-person identity proofing to receive the initial credentials make it a bit stronger. I'm happy to make changes and will do the next iteration quickly (this week) with agreement. Thank you very much for your review and comments! Kathleen > > > > > [PS: I'm fighting with the IETF mail server and multiple personal email > addresses; so apologies if this sends twice] > > > > > > --- > Mike Ounsworth > Software Security Architect, Entrust > > > *Any email and files/attachments transmitted with it are intended solely > for the use of the individual or entity to whom they are addressed. If this > message has been sent to you in error, you must not copy, distribute or > disclose of the information it contains. Please notify Entrust immediately > and delete the message from your system.* > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Best regards, Kathleen
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
