Subject: [Acme] Re: Call for adoption: draft-davidben-acme-profile-sets-00 (Ends 2026-01-21)
From: David Benjamin <[email-masked]>
To: Mike Ounsworth <[email-masked]>
Cc: Sven A Rajala <[email-masked]>, Mike Ounsworth <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 7 Jan 2026 21:43:04 -0500
List-Id: Automated Certificate Management Environment <acme.ietf.org>

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-masked]>
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-masked]>
> 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-masked]
> >
> >
> >
> > From: Mike Ounsworth via Datatracker <[email-masked]>
> > Date: Wednesday, 2026 January 7 at 16:13
> > To: [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>
> > 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-masked]
> > To unsubscribe send an email to [email-masked]
> >
> > _______________________________________________
> > Acme mailing list -- [email-masked]
> > To unsubscribe send an email to [email-masked]
>