Hi Mike, The ‘why ACME?’ question was something that puzzled me greatly when 3GPP started looking at it about 18 months ago when they already had a semi-custom cert management protocol based on CMPv2.
The initial arguments for ACME as an alternative were based on cloud-native, wide deployment and support in the right places. I’m not sure I personally completely bought into those, but I include them for reference. At the end of the work, however, other benefits came to light from my view. Primarily, the challenge-at-each-issuance fits more naturally into a zero trust design philosophy. The EST proof of identity (and the 3GPP CMPv2 based solution) issue a new certificate based on the fact you have (they key for) the previous one, and maybe some credentials issued at enrolment. Is it better to build on EST or ACME to get to where we want to get to? I am agnostic about that at this moment in time – one of my hopes in joining in with this WG was to get the views of the experts on which would be best. Matt From: Mike Ounsworth <[email protected]> Sent: 22 July 2025 22:35 To: Kathleen Moriarty <[email protected]> Cc: Mike Ounsworth <[email protected]>; IETF ACME <[email protected]> Subject: [Acme] Re: Personal review of draft-ietf-acme-client You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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]<mailto: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]<mailto:[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 <[email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Best regards, Kathleen _______________________________________________ Acme mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
