Hi Matt, Charles, and team, Thank you for sharing this thoughtful summary ahead of IETF 123. The work being done in 3GPP SA3 and the broader collaboration between stakeholders such as Google, Cisco, NSA, NCSC, and Johns Hopkins is impressive and timely. I wanted to express my strong interest in this direction and offer some feedback and perspective from the enterprise certificate lifecycle management and PKI automation domain.
The problem space you’ve outlined—particularly the orchestration-heavy, ephemeral infrastructure within modern 5G and cloud-native environments—resonates strongly with challenges we also see in broader enterprise and zero-trust adoption contexts. As organizations move toward short-lived certificates, decentralized architectures, and service mesh integrations, the boundaries between issuance, validation, and identity attestation are becoming more dynamic and orchestrator-driven. Bringing this into the ACME WG’s radar is a natural progression. While RFC 8555 served as a solid foundation for automated certificate issuance, real-world deployments increasingly stretch those assumptions. Your proposal surfaces much-needed discussion on: - Expanding EAB capabilities through more flexible, non-pre-shared mechanisms such as certificate-based or OAuth-backed flows—something that could benefit ACME use cases across Kubernetes, mesh systems, and IoT as well. - Leveraging orchestrator-issued client certs for stronger identity binding, particularly in ephemeral environments where long-lived keying material is a liability. - Adapting challenges (e.g., TLS-ALPN, HTTP-01) to support internal trust anchors and private service environments with constrained networking—common in both telco and enterprise zero-trust setups. These are highly relevant topics, not just for 5G, but for any orchestrated PKI model. I believe these ideas would be most impactful if they could be aligned with a general-purpose ACME extension framework rather than a limited-purpose RFC. Specifically: - A new draft or update to RFC 8555 could explore pluggable account creation/authentication models, incorporating OAuth2, client certificate authentication, or token-bound identifiers, without breaking backwards compatibility. - The notion of delegated trust or orchestrator-mediated ACME flows could be a valuable extension area for the WG to consider formally, especially as vendors begin incorporating ACME into DevOps pipelines, SD-WANs, and cloud edge scenarios. - While TLS client auth is indeed being phased out in public web PKI, it’s still a valid pattern for private PKI and internal mTLS deployments, especially if anchored in orchestrator-issued credentials. I’m very interested in contributing to this effort—whether through providing input, helping draft a general-purpose ACME extension RFC. If there’s interest, I’d be happy to help bridge insights from enterprise and hybrid cloud PKI automation use cases into this workstream. Thanks again for initiating this discussion—it’s very encouraging to see orchestration-centric certificate management challenges gaining traction in the ACME WG. Ganesh Mallaya On Wed, Jul 9, 2025 at 15:26 Matt G1 <[email protected]> wrote: > Hi, > > > > I'm putting this on the mailing list ahead of IETF 123 hoping to prompt > some > > discussion based on some work done recently in 3GPP SA3. This follow-up > comes > > out of discussions between Google, Cisco, Johns Hopkins, NSA, and NCSC. > > > > At this point we would really appreciate the ACME group's input on two > options > > for proceeding: > > > > - Would there be sufficient interest to incorporate any of the ideas below > into > > a future RFC for general-purpose ACME? Perhaps the group is aware of > > up-coming drafts that might be willing to adopt/include things? > > - Or would the working group prefer to see a limited purpose RFC instead? > > > > > > If the group felt some agenda time was available in Madrid then a couple of > > people involved in the 3GPP work will be in attendance: Charles Eckel and > me. > > > > Background: SA3 recently concluded work on a new informative text for use > of > > ACME in the 5G Core. The updated version of the base spec with these change > > incorporated is available at: > > > > https://www.3gpp.org/ftp/Specs/archive/33_series/33.310/33310-j40.zip > > > > See Appendix J, p. 72 (note docx format stored in zip file - 3GPP norm). > > > > The consensus was to follow parts of the base RFC 8555, complemented with > TKAuth > > validation per RFC 9447 with a new identifier and challenge type for 5G > > (currently being registered with IANA). > > > > There were some ideas generated which weren't quite vanilla RFC-8555, and > thus > > not pursued, but which would have been beneficial if available to us. The > > extensions would be to parts of the RFC that were not marked as extensible. > > > > I will include some inline feedback kindly passed on by Andy Warner > (Google) > > who was involved in the discussions. > > > > ---------- > > > > Brief overview of problem space and solution adopted: > > > > The 5G Core fits the following model: > > > > 1. Orchestrator/OAM: > > - can issue short term credentials and inject them into > network functions when > > spinning them up > > - in the solution chosen, can act as TK Auth server. > > 2. Network functions/NF > > - virtualized > > - should have limited privileges > > - will have an ACME client > > 3. CA > > - distinct entity from the orchestrator/OAM > > > > > > External Account Binding (EAB) is used to secure account creation. > > TK Auth is used for identifier/identity validation. > > TK Auth token signed by OAM includes not just SAN fields but bespoke 5G > X.509 > > extension (as defined in RFC 9509) for NFType. > > > > ----------- > > > > Acme Extensions In Orchestrate Use-cases (AEIOU) > > > > > > 1. External Account binding ideas > > > > EAB is adopted in our work to authorize account creation. > > > > This requires an every-time communication: every time an NF is created the > OAM > > and CA must communicate to share the new MAC key, and other account > specific > > information. > > > > If, say, certificate based options for digital signature were permitted > the > > need for every-time OAM-CA communication could be alleviated (depending on > > what is encoded in the certificate - the NFType parameter in our case can > be). > > > > We avoid the bootstrap problem since case the OAM can be assumed to be a > > secondary CA. > > > > Initial feedback suggests this is most inline with existing implementation. > > > > A finer-grained option would be to introduce OAuth (or similar) to account > > creation. This gives more flexibility in providing account information than > > just certificate extensions. In the orchestrated case the OAM can be the > OAuth > > auth server. > > > > Initial feedback suggests this has interesting potential but is a > significant > > change to the existing procedures. > > > > > > 2. Client certificates > > > > In our situation of having the OAM able to issue temporary certificates, we > > could use them in a couple of ways: > > > > a. the newAccount message to authenticate via mTLS at account creation > instead > > of using EAB > > b. require them on TLS-ALPN challenges to limit on-path-attackers > > c. require them on HTTP challenges where the ACME client redirects to HTTPS > > > > Initial feedback from Andy highlighted the fact clientAuth is being pushed > out > > of public trust stores, and that that TLS-ALPN is not as widely supported > on > > the client side as I may have assumed. > > > > I also have reservations about b. and c. within the 5G use case as they > require > > NFs which may not need open inbound ports for any other reason to start > > punching holes in their firewalls solely for the purpose of certificate > issuance. > > However, for completeness I am mentioning them here. > > > > Your thoughts on these or other paths forward would be greatly appreciated. > > > > Matt G, NCSC, with input from Andy Warner (Google) and Charles Eckel > (Cisco). > > > > > > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
