Hi Mike,
The current RFC8555 is for TLS/SSL certificate only, and RFC 8823 is for S/MIME certificate ACME。 This RFC draft is for Client Certificate including Client Authentication Certificate, code signing certificate and document signing certificate, so all type certificates that CA issued support ACME, this is a VERY necessary standard that the industrial need. For CSR with code signing certificate OID, just need to set it in OpenSSL configuration file (e.g., csr.conf), this is one of the solution, this can be realized by other method. Best Regards Richard Wang www.zotrus.com <http://www.zotrus.com> From: Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org> Sent: Monday, July 21, 2025 7:01 PM To: IETF ACME <acme@ietf.org> Subject: [Acme] Personal review of draft-ietf-acme-client 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. 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 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 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 would remove the entire sections on Code Signing and Document Signing since I think that’s a distraction from the core of the draft �C 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 �C particularly the /new-order �C 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. I think the draft’s Introduction and Security Considerations needs some discussion that this draft changes the philosophical nature of the ACME protocol �C 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). [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 -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
