Hi Kathleen, Another thought related to this draft. This one came out of a parallel thread with Aaron, but I'll post it here too.
A number of the ACME-related discussions today have had me wondering if people are trying to evolve ACME to encroach into the functionality space of EST, and if in fact the right answer to a lot of these usecases is "Don't use ACME, use EST instead". EST is an HTTP-over-TLS enrollment protocol that uses TLS client-auth as the fundamental auth mechanism. So you already have 1/3 of Kathleen's draft as core functionality of EST. You could add all the OTP stuff by using psk or pake TLS mode. And there's independent work on attested-tls that would do the webauthn-auth and rats stuff. On Tue, 22 Jul 2025 at 08:20, Mike Ounsworth <[email protected]> wrote: > I want to say on the list (no-hat), that during today's meeting someone (Q > I believe) pointed out that draft-acme-device-attest also defines a > WebAuthn Challenge, and draft-liu-acme-rats does something similar. > > I believe that these are using WebAuthn for very different purposes: > > As I understand these drafts, draft-device-attest as using the WebAuthn to > validate control of the requested identifiers. For example, I want a cert > with a device serial number in it, and the WebAuthn provides > proof-of-control of the device with that serial number. > > Whereas draft-acme-client is serving usecases like: I go to my CA's web > interface and tee up a code-signing cert for "DN=Mike Software Corp, inc". > There's no identity there that can be automatably verified. So instead, > draft-acme-client wants the user to be able to set up an MFA ({email / SMS} > OTP, {T/H}OTP, Client Cert, WebAuthn) so that we can strongly link an ACME > request to some setup done previously in, for example, a web browser. Here > we are using WebAuthn as an MFA authentication, not as a > proof-of-ownership-of-requested-identifier. In other words, I think it's > clear enough that the "pkp-01" challenge type that draft-acme-client is > registering is WebAuthn for authentication whereas "device-attest-01" that > draft-acme-device-attest is WebAuthn for proof-of-ownership. > > So I don't see a conflict between these two drafts; nor do I think these > two drafts should attempt to merge. > > On Tue, 22 Jul 2025 at 04:06, Kathleen Moriarty < > [email protected]> wrote: > >> 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] >> >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
