OFFICIAL This (private) usage is certainly one I'm interest in for 3GPP systems, or anything similar, where there needs to be some transfer of trust from the OAM internal CA (whatever's built in to Kubernetes probably) over to the operator's private PKI CA - please note this is an established idea and I cannot comment on the details of how/why so please do not ask, it just is a thing they have.
In this context this needs only be a one-time event at account creation, not every time at certificate issue. Having something other than symmetric MAC keys standardized would be a fantastic improvement in minimizing out-of-band comms down to a one-time hand over of a root certificate, and as a side effect improving security since we don't need the HSM in the CA to store symmetric keys that Mike R alludes to Matt G1 - NCSC Telecoms Security Consultant (Standards) [email protected] OFFICIAL From: Sven A Rajala <[email protected]> Sent: 27 October 2025 01:53 To: Mike Ounsworth <[email protected]>; Michael Richardson <[email protected]> Cc: [email protected] Subject: [Acme] Re: questions about RFC8555, externalAccountBinding usage You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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]
