My understanding of EAB is that you use it to register your account with the ACME server that way you can restrict access to enroll. Otherwise anyone could try to enroll using the ACME server. When I explain that customers I tell them it’s like 2FA for your ACME enrollments. It’s commonly used with customers I work with too for their private ACME PKI enrollments.
There is support for private/pub key to use as well as the option Micheal mentioned below. I don’t recall what ACME clients support it though. Kindly, Sven Rajala International PKI Man of Mystery M: +1 540 687 0761 [email protected]<https://www.keyfactor.com/> From: Mike Ounsworth <[email protected]> Date: Monday, 2025 October 27 at 09:47 To: Michael Richardson <[email protected]> Cc: [email protected] <[email protected]> Subject: [Acme] Re: questions about RFC8555, externalAccountBinding usage This Message Is From an External Sender This message came from outside your organization. Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BjbSd3t9V7AnTp3tuV-82YaK!_uQhDA8nmlmoNEaf_nrSeVIuIzh0OwXRMqMLKyOFSfIcPVmRfrxh4la7q9iAI3HMhwt297qHS1n_9GQBZUKNZ9n8Pjk1IIkBHrr1QMbfuULqutAdrUXgW6MPransLvqG$> Hi Richard, I was not in the room when EAB was invented, but my understanding is that it is a dance around both a technical and legal issue. People who have been here longer than I, please correct. Technical: if I run Mike's Web Hosting, inc, and I run one certbot with one JWK for my billions of subscriber domains, when Mike's acmebot JWK requests a cert for bobsblog.com<https://urldefense.com/v3/__http://bobsblog.com__;!!BjbSd3t9V7AnTp3tuV-82YaK!yZHuZ3MHfs2ALYgGAI0MRpp-IUMD5-3DAbtiX5UdGSvga4appmb9ZgTQJGkVtN_lBRdUQAbFwWxhyioM614xCD8nUtM2Xw$> against a CA cert profile that costs money, who do we bill? Legal: the ACME protocol can carry a Terms of Service Agreement down the pipe to be accepted by the human user, and accepted via a "termsOfServiceAgreed": true in the new-account creation. The issue is, which human has to accept the ToS? Mike's Web Hosting (who owns the acmebot) or Bob who owns bobsblog.com<https://urldefense.com/v3/__http://bobsblog.com__;!!BjbSd3t9V7AnTp3tuV-82YaK!yZHuZ3MHfs2ALYgGAI0MRpp-IUMD5-3DAbtiX5UdGSvga4appmb9ZgTQJGkVtN_lBRdUQAbFwWxhyioM614xCD8nUtM2Xw$>? In cases where it needs to be Bob, he can read and agree to the ToS in advance through the CA's portal and then the CA knows (via the EAB) that ToS does not need to be done in-band in new-account. (I'm only like 40% confident about this info, so someone please correct me. On Sun, 26 Oct 2025 at 11:00, Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: My understanding of the externalAccountBinding mechanism in RFC8555 is that is allows a JWS account key to be approved/endorsed by some longer term key that the CA/customer have exchanged. I see support in the "certbot" client via the --eab* options, so I'm guessing that it's in use by at least one CA. My understanding is that a customer would login to some CA "sales" portal. They do whatever dance is required to be authorized for the extra stuff. (Whether that's EV certificates, higher transactions/hour, or just payment) The CA sends the MAC key/ID, and the operator then runs "certbot register .." on each machine that is going to act as a client. That binds the locally generated JWS account key in the CA's database with the service. The client then operates as "normal" Are there CAs for which this is not the end? For instance, are there CAs that would then ask the operator to login to approve the binding, and/or adjust the attributes on the account? Are there any for which the bindings requires multiple authorizations? (Like from the CTO and the CISO, or 2 out of 3...) I'm asking because I'm trying to understand/brainstorm around innovation/extension around per-issurance authorizations. (ps: are there clients which know how to store this symmetric account binding MAC in some other HSM/TPM? Clearly a local issue) -- Michael Richardson <[email protected]<mailto:mcr%[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ 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]
