Hmm. I don't remember discussing the motivations much in 124—rewatching the video, the discussion was mostly about whether to propose it as a profiles PR or a separate draft—but I'm certainly happy to talk about it now! That is the point of bringing stuff here, after all. Plus it's a more interesting topic than document administrivia. :-)
For folks who missed it, I talked a bit about the motivation in both the draft and 124, so here are the links to what happened in 124. This is a pretty tiny mechanism, so there's not a lot to skim through there: https://datatracker.ietf.org/meeting/124/materials/slides-124-acme-acme-profile-sets-00 https://youtu.be/agFEJPXX1XU?si=E-WYbSbEzVEkGr1H&t=4539 To expand on that a bit, the aim of this draft is to deal with cases where the ACME client, for whatever reason, needs multiple flavors of certificates to satisfy all its relying parties. This could be multiple trust anchors, multiple signature algorithms, or whatnot. As Mike suggests, this is common with a PKI transition. To improve security, performance, etc., newer relying parties make changes because... - ...ECDSA roots start being available and using those saves bytes - ...some CA was found untrustworthy and was removed. - ...SHA-1 is broken and relying parties start requiring SHA-256 signatures. - ...all of classical cryptography is broken and we need to transition to PQC. But older relying parties still have the old behavior, and ACME clients (web servers) may still need to support both generations. When this is too difficult, there are costs to performance (they can't move to ECDSA), availability (they broke with old or new relying parties), or security (relying parties are unable to, say, drop SHA-1 because web servers aren't ready). One way to square this circle is to have a couple of certificates that, together, cover all your supported relying parties. Maybe you have both an ECDSA and RSA option and you send the RSA to older relying parties. Maybe you get certs from the old and new CA. Maybe you have certificates signed with SHA-1 and SHA-256. Maybe you have a classical and PQC chain. To do that, you needed to know to obtain multiple certificates and which ones. This draft is a way for ACME servers to tell ACME clients which variations to ask for, within the context of *one* set of subject information. This way, transitions which fit in that mold (more on that later) do not require reconfiguring the ACME client. It can just pick it up automatically. As PKIs generally have far more ACME clients than ACME servers, and ACME servers are close to the goings on of the PKI, this give folks a tool to automate a class of transitions. > Does it have usefulness in steady state "Transition" vs "steady state" aren't quite mutually exclusive here. The Internet is messy, and old relying parties take a long time to get updated out. I think most large web server operators will tell you that old relying parties last practically forever. Sure, web browsers and such auto-update, but the long tail of unupdatable TV set-top boxes, unupdatable IoT devices, unupdatable point of sale devices, laptops that just woke up from years in the attic, etc., stick around. So transitions are not single brief events, but steady state situations that can last increasingly long times for different parties. In my own experience: - I work with a significant web server deployment which sees old clients all the time. - I also work with a significant web client deployment. The web server partners I talk to in that work see this as well. (Last year, someone proudly told me they finally disabled SSL 3.0 because they dropped Windows CE!) - I see this talking to CAs. CAs are, quite understandably, reluctant to change their issuing profiles based on what would be optimal or necessary for new relying parties: it's a risk. *Some* subscriber may care about *some* old relying party that hasn't been updated and is worth a lot to them to keep supporting. So, yes, it is useful in the steady state. > Or is the underlying assumption that over the next decade, the CA landscape is going to be changing so much that CA Migration Events will be a kind of steady state? On the Web at least, a decade ago, the CA landscape *was* quite different. SHA-1 was still accepted. CT was not yet required by any browser. ECDSA support was far from ubiquitous. Some trusted CAs, that today are quite significant in the PKI, either did not exist or were just starting out. Many CAs that are no longer trusted today were trusted then. So, yes, based on the last decade, I expect over the next decade the PKI *will* look different. If nothing else, I certainly hope we will have made some progress in the PQ transition! :-D And as the range of Internet-connected devices balloons, we can expect the effects of diverse old relying parties to go up. This draft tries to apply lessons from last decade's pain points, to try to make these sorts of things smoother for CAs, subscribers, and relying parties, and, ultimately, so that the underlying security, performance, and availability goals underpinning all these things translate to end user improvements smoothly and quickly. > for example, in the PQ Migration usecase it's not just that the Client will fire the same CSR at both the "RSA" and "ML-DSA" cert profiles; it actually needs to create separate RSA and ML-DSA keys / CSRs Ah yes, this is an interesting one. There are actually two separate migrations here: 1. PQ for the PKI (CA keys and signatures they make in certificates) 2. PQ for the end-entity (EE keys and the signatures in TLS, etc.) (2) is indeed not helped by this draft. I don't think we can reasonably hope to automate that because it inherently involves a software update to add that. There's no escaping having to touch O(num_acme_clients) things. But (1) *does* benefit from this draft. This draft means, by touching only O(num_acme_servers) things, provision a PQ-rooted version of web servers' existing keys, even if most of those keys are still classical. Why is this useful? This updates the roots of trust and gives us downgrade protection: In this model, there are three plausible states a web server could be in: a. Classical->Classical only b. Classical->Classical + PQ->Classical c. Classical->Classical + PQ->PQ We want to get everyone to (c). But any given web server will need to do manual work because they need PQ-capable software and to provision PQ key. (b), on the other hand, can be automated. As soon as every web server has gotten out of state (a), the relying parties can transition to *only* trusting the PQ roots, long before they start requiring PQ EE keys. Once they do that, users have downgrade protection. In these relying parties that only trust PQ CAs, a quantum attacker *cannot forge a PQ->Classical certificate*. That means the attacker *cannot* trick the relying party into thinking a PQ-secure server (c) is in transition (b), and then attack the classical EE codepath. This kind of downgrade protection is crucial for long timescale transitions. It lets you incrementally protect servers as they migrate, without holding everyone back to the slowest of the long tail. We use it in TLS all the time. Of course, how much we can do this for *this* transition is less clear given the mechanism doesn't exist today. (Though it is pretty short and simple.) But everything we do at IETF is forward-looking anyway. But I think, looking at this transition, and others of the past decade, it's clear that this is a valuable tool to set ourselves with for the future: - The SHA-1 to SHA-256 transition did not need any changes to EE keys and could have used this. We got lucky that SHA-256 support was common (but not ubiquitous) in clients by then. - If you need to get a certificate from an old CA and a new CA, the subject information between the two needn't be different. These transitions are very disruptive and maybe we can reduce this. - RSA to ECDSA was a size optimization. Even if your EE key is still RSA, getting the CA key to ECDSA would have still saved bytes. We didn't get to do this optimization and RSA is still common. - If, after ML-DSA, we get a smaller PQ signature scheme, same story: migrating the CA half would likewise be a bandwidth saving that's orthogonal to migrating the EE half. > Or S/MIME and TLS_Client certs may have different sets of SANs (email vs domain userid) I'm not convinced that the currently-proposed mechanism -- which at its core is human-readable profile descriptions -- is rich enough to fully automate that successfully. Think I covered this above, but this draft is not intended to cover cases where the different certificates need different subject information. In that case, the ACME client presumably has pre-existing knowledge about the two cases anyway and there's no benefit to a discovery protocol. But when you are certifying the same subject information, the ACME client does *not* need pre-existing knowledge, so we *can* build a discovery protocol. The human-readable framing is a good one. To expand on that, where a human had to make a decision (details of provisioning keys, which software to run, which high-level profile to ask the CA for, etc) is configuration and not automatable. And thus profiles rightly uses human-readable descriptions. Where a human did *not* have to make a decision, we can automate. The observation of profile sets is that, within the bounds of a human-level certificate profile ("I want to convince this class of relying parties that this is my key"), the best response may be multiple "subprofiles" that jointly meet that human request. And then by automating *that*, we get a useful tool for a large class of transitions. This has gotten quite long despite my best attempts to cut it down, so if you read to the end, thank you! I hope this helps elaborate on the motivation a bit. :-) David On Wed, Jan 7, 2026 at 6:42 PM Mike Ounsworth <[email protected]> wrote: > [chair-hat-off] > > The usecase for draft-ietf-acme-profiles is clear to me: the ACME > Server can advertise the different "products" that it offers, And the > Client can say "I'd like to order a TLS_Server_and_TLS_Client cert > please", or "I'd like to order a QWAC cert please" or "I'd like to > order an S/MIME cert, please". That's like, "How was that not in the > base RFC8555??". > > draft-davidben-acme-profile-sets, I'm a much less clear on what it's > doing and why. The minutes from 124 were a little sparse on the > discussion about this draft [1], but my recollection is that the room > shared my uncertainty about what this draft is trying to accomplish. > > The operative sentence in the draft seems to be this one: > > "If configured with a profile set, the ACME Client SHOULD request > certificates from each profile in the profile set, creating > independent, parallel orders for each." > > So a profile-set is a collection of profiles offered by the same ACME > Server (which usually means from the same CA operator) where the ACME > Server expects ... or, I guess, actually is recommending ... that > clients will want one cert from each profile. I can imagine some > usefulness when the CA is rolling over to a new algorithm (PQ) and > you're recommending that Client get both an RSA and ML-DSA version of > every cert, or if the new default cert profile is adding some crazy > new OID that will cause old clients to explode. So this is a mechanism > to deal with some kind of CA migration event? Does it have usefulness > in steady state; like does the CA want to use profile-sets to offer > "packages" like "S/MIME + TLS_Client"? But since the mechanism > described in the -00 draft still requires the Client to create > independent newOrders, is this really adding value there? If the > client needs both a S/MIME and a TLS_Client, does it really need the > ACME Server to list that as a package? Or is the underlying assumption > that over the next decade, the CA landscape is going to be changing so > much that CA Migration Events will be a kind of steady state? > > I'm with Tim Hollebeek that profile-sets feels like the kind of thing > that's gonna be more complex than it looks on the surface; for > example, in the PQ Migration usecase it's not just that the Client > will fire the same CSR at both the "RSA" and "ML-DSA" cert profiles; > it actually needs to create separate RSA and ML-DSA keys / CSRs. Or > S/MIME and TLS_Client certs may have different sets of SANs (email vs > domain userid). I'm not convinced that the currently-proposed > mechanism -- which at its core is human-readable profile descriptions > -- is rich enough to fully automate that successfully. > > So I'm not convinced that this draft is meaningfully solving a > meaningful problem, unless there's some killer usecase for this that > I'm not seeing. > > [1]: > https://datatracker.ietf.org/doc/minutes-124-acme-202511041930/#draft-davidben-acme-profile-sets---david-benjamin > > > On Wed, 7 Jan 2026 at 15:42, Sven A Rajala <[email protected]> > wrote: > > > > To break the ice, what is the contention about? Sadly I missed the F2F > meeting 124 and I didn’t see any traffic on the mailing list. > > > > Kindly, > > > > Sven Rajala > > > > International PKI Man of Mystery > > > > > > > > M: +1 540 687 0761 <(540)%20687-0761> > > > > [email protected] > > > > > > > > From: Mike Ounsworth via Datatracker <[email protected]> > > Date: Wednesday, 2026 January 7 at 16:13 > > To: [email protected] <[email protected]>, [email protected] < > [email protected]>, [email protected] < > [email protected]> > > Subject: [Acme] Call for adoption: draft-davidben-acme-profile-sets-00 > (Ends 2026-01-21) > > > > This Message Is From an External Sender > > This message came from outside your organization. > > Report Suspicious > > > > > > This message starts a acme WG Call for Adoption of: > > draft-davidben-acme-profile-sets-00 > > > > This Working Group Call for Adoption ends on 2026-01-21 > > > > Chair note: > > This is the last of the documents that asked for adoption at 124. > > This one was also the most contentious, so instead of the usual "I > support adoption", I would like to see proponents of this draft explain > what problem they are facing in their production environments, and why this > draft is the right solution. > > > > > > Abstract: > > This document defines how an ACME Server may indicate collections of > > related certificate profiles to ACME Clients. > > > > Please reply to this message and indicate whether or not you support > adoption > > of this Internet-Draft by the acme WG. Comments to explain your > preference > > are greatly appreciated. Please reply to all recipients of this message > and > > include this message in your response. > > > > Authors, and WG participants in general, are reminded of the Intellectual > > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > > Appropriate IPR disclosures required for full conformance with the > provisions > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > > Sanctions available for application to violators of IETF IPR Policy can > be > > found at [3]. > > > > Thank you. > > [1] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkq33Hn5mw$ > > [2] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkqKrhPGZ4$ > > [3] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkq9sTZf6E$ > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-davidben-acme-profile-sets/__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkqW50-2Gw$ > > > > There is also an HTML version available at: > > > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-davidben-acme-profile-sets-00.html__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkqqgSwOX4$ > > > > _______________________________________________ > > 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] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
