Hi Mike, I checked EST: https://www.rfc-editor.org/rfc/rfc7030 that released on 2013, early than RFC8555. Let me try to explain why not EST but ACME: (1) the most important reason is ACME is widely used worldwide, EST not; (2) Grok told me that "EST Server Scenario: An enterprise with an internal CA uses an EST server to issue certificates for IoT devices", but we need ACME for public CA to issue publicly trusted certificate. (3) This draft is just add more challenge type to ACME facility that widely used, then all type certificates support automation, this is the easy way for certificate automation then EST.
So I strongly recommend use ACME, not EST. And we need this draft for client certificate including code signing certificate and document signing certificate, thanks. Best Regards Richard Wang -----Original Message----- From: Michael Richardson <[email protected]> Sent: Wednesday, July 23, 2025 7:57 PM To: [email protected] Cc: 'Mike Ounsworth' <[email protected]>; 'IETF ACME' <[email protected]> Subject: Re: [Acme] Re: Personal review of draft-ietf-acme-client <[email protected]> wrote: > 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. Can you speculate as to why EST is not being used? -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
