MIME-Version: 1.0
References: 
 <176782035446.3829944.17475670312912489816@dt-datatracker-5656579b89-p6k4r>
 <24181.1767891597@obiwan.sandelman.ca>
In-Reply-To: <24181.1767891597@obiwan.sandelman.ca>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 8 Jan 2026 13:01:15 -0500
Message-ID: 
 <CAF8qwaA_YoS88c+wdijQ_L7enhTqJR2mfA5qPtxK0i4Zp9iMKA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="000000000000f3f58d0647e4325a"
Message-ID-Hash: 7SHDPH34AW2GDQ7SW7YVCIJSYETMITYQ
CC: acme@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BAcme=5D_Re=3A_Call_for_adoption=3A_draft-davidben-acme-profile-?=
 =?utf-8?q?sets-00_=28Ends_2026-01-21=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/acme/2gYlgq_Kxz2Gqlb0Ak5b2Nhr3ig>

--000000000000f3f58d0647e4325a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 8, 2026 at 12:03=E2=80=AFPM Michael Richardson <mcr+ietf@sandel=
man.ca>
wrote:

>
> I have read acme-profile-sets, (and quickly re-read acme-profile).
> I don't have a specific need today, which I think the protocol in this
> document would solve.  Having said that, I'm listening.
>
> My concern is centered around the use of human-readable profile
> descriptions in
> acme-profile, and in this document.  It was barely acceptable (tolerable)
> for
> acme-profile.   I can see a web interface that lets someone pick a profil=
e
> from available ones, with the description visible. But, I can't see this
> being at all easy for a profile-set.
>
> I wonder if profile sets wouldn't be easier to do by just turning the
> right-hand side of the acme-profile profiles{} map into an array, or even=
 a
> map without the need for profileSets at all.
>

Ah, good question. The JSON encoding is a little wonky. I wrote this
assuming we weren't to change the profiles{} map because that was already
shipped, but plenty of room to tweak this if the WG wants to take on this
work. If the two had been designed at the same time, I think we would have
had two notions of things (insert better names here):

1. A config profile, which is the thing the human chooses, with the
human-readable description
2. An order profile, which is the thing that an individual order
programmatically asks the ACME server for

And then the relationship between them is that a config profile is made up
of one or more order profiles. Something like:

"configProfiles": {
   "profile1": {
    "description": "Use this to support RPs X, Y, and Z with a TLS server
ECDSA key ",
    "orderProfiles": ["profile1a", "profile1b"]
   },
   "profile2": {
    "description": "Use this to support RPs W, X, and Y with a TLS server
RSA key",
    "orderProfiles": ["profile2"]
   },
}

Under this model, acme-profile is specifying single-order-profile config
profiles, and profile-sets lets you express the more general thing. The
observation is that, even after the human has made all of their decisions,
the best response may be a couple of different orders combined, if the
target RPs span a wide range of time, etc.


> (BTW: The example in section 3 would appear to be missing the profileExt,
> profile2a, and 2b profiles)
>

Ah, that's intentional and comes out of having to construct this separation
after the fact. That's covered by this sentence:
https://davidben.github.io/acme-profile-sets/draft-davidben-acme-profile-se=
ts.html#section-3-7

The thinking was that the top-level entries, either in profiles{} or
profileSets{} are the distinct human choices that the CA has assembled for
you. Those are what would appear in a web interface with the description
visible. The strings inside profileSets[<name>].profiles[] are the
individual order profiles, which may or may not be a distinct human-level
choice standalone. If they are, they might also appear in profiles{} (or
equivalently a singleton in profileSet{}). If they aren't, they'll just be
random names. Since a human will never be picking the individual order
profiles, they don't actually need to appear in the directory.

It's very gross and I'm sure there are better ways to spell this in JSON.
(Thoughts?) I just picked something and clearly didn't do a great job of
explaining it. :-)


> SC says:
>
>    Profile sets allow an ACME Server to help ACME Clients configure
>    themselves appropriately during PKI security transitions, such as a
>    change in algorithm, a change in trusted CAs, or CA key rotation.
>    Most PKIs have far fewer ACME Servers than ACME Clients, with ACME
>    Server operators well-connected to relying party requirements.  This
>    can help transitions complete more quickly, and thus allow the PKI to
>    realize the security benefits sooner.
>
> (I don't think this belongs in Security Considerations, but rather the
> Introduction)
>
> I don't know how the client would know what algorithms to use for each
> member
> of the profile set.   If the idea is that I might need an EcDSA-only
> certificate
> and a quantum-safe one (whether it's hybrid or pure), then I'm not sure h=
ow
> the client figures this out.  If it already knows the details , then I'm
> not
> sure what the directory does to help.
>
> Given that the client has to know about profile sets, and has to pick one=
,
> and has to then iterate on each profile, requesting a certificate, I am n=
ot
> convinced that this even needs to be announced by the server.
>
> So the idea of this document seems useful, but I don't think this documen=
t
> delivers on what it says it wants to do.
>
> (I'd rather the document use the term "quantum-safe", rather than
> "Post-Quantum", even if NIST's competition is called Post-Quantum, becaus=
e
> that might not be the end of quantum-safety.  ETSI uses quantum-safe.)
>

Ah, I touched on this a bit in the email here, replying to Mike's comment
on the PQ migration use case.
https://mailarchive.ietf.org/arch/msg/acme/m9Smynn9AHeHrenhARCNBSJfOsk/#:~:=
text=3D%3E%20for%20example%2C%20in%20the%20PQ%20Migration%20usecase%20it%27=
s%20not%20just%20that%20the%20Client%0Awill%20fire%20the%20same%20CSR%20at%=
20both%20the%20%22RSA%22%20and%20%22ML%2DDSA%22%20cert%20profiles%3B%20it%0=
Aactually%20needs%20to%20create%20separate%20RSA%20and%20ML%2DDSA%20keys%20=
/%20CSRs

This isn't meant to help the ACME client decide which keys it needs.
Automating that seems difficult because what key you have isn't really a
property of the ACME server. It's a property of the ACME client, taking
into account...
- What are the capabilities of the protocol it's using the cert in?
- What are the capabilities of the software it will install the cert into?
- How and where does it provision private keys? Maybe it's already
pre-provisioned all its keys into some HSM and making new keys would be a
whole ceremony.
- What kinds of *end-entity* keys will the desired relying parties support?

Since that is ultimately a client-side decision, I don't see a clear space
for the ACME server to help. I think we're going to have to do O(num ACME
clients) work to perform that part of the transition regardless.

However, that can be made orthogonal to the parts that come from the ACME
server and general state of the PKI:
- What specific CA keys does each relying party trust?
- What CA signature algorithms does each relying party accept?

*That* can be automated by the ACME server, and is a place where multiple
certificates can be helpful. For specifically the case of the PQ transition
and things like it (not the only use case, but one of them), it's true that
we eventually need to do both halves. But there's a compelling downgrade
protection reason to automate the PKI half and do it separately, mentioned
in that email.

Does that make the thinking a bit clearer?

David

--000000000000f3f58d0647e4325a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jan 8, 2026 at 12:03=E2=80=AFPM M=
ichael Richardson &lt;<a href=3D"mailto:mcr%2Bietf@sandelman.ca">mcr+ietf@s=
andelman.ca</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_conta=
iner"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I have read acme-profile-sets, (and quickly re-read acme-profile).<br>
I don&#39;t have a specific need today, which I think the protocol in this<=
br>
document would solve.=C2=A0 Having said that, I&#39;m listening.<br>
<br>
My concern is centered around the use of human-readable profile description=
s in<br>
acme-profile, and in this document.=C2=A0 It was barely acceptable (tolerab=
le) for<br>
acme-profile.=C2=A0 =C2=A0I can see a web interface that lets someone pick =
a profile<br>
from available ones, with the description visible. But, I can&#39;t see thi=
s<br>
being at all easy for a profile-set.<br>
<br>
I wonder if profile sets wouldn&#39;t be easier to do by just turning the<b=
r>
right-hand side of the acme-profile profiles{} map into an array, or even a=
<br>
map without the need for profileSets at all.<br></blockquote><div><br></div=
><div>Ah, good question. The JSON encoding is a little wonky. I wrote this =
assuming we weren&#39;t to change the profiles{} map because that was alrea=
dy shipped, but plenty of room to tweak this if the WG wants to take on thi=
s work. If the two had been designed at the same time, I think we would hav=
e had two notions of things (insert better names here):</div><div><br></div=
><div>1. A config profile, which is the thing the human chooses, with the h=
uman-readable description</div><div>2. An order profile, which is the thing=
 that an individual order programmatically asks the ACME server for</div><d=
iv><br></div><div>And then the relationship between them is that a config p=
rofile is made up of one or more order profiles. Something like:</div><div>=
<br></div><div>&quot;configProfiles&quot;: {</div><div>=C2=A0 =C2=A0&quot;p=
rofile1&quot;: {</div><div>=C2=A0 =C2=A0 &quot;description&quot;: &quot;Use=
 this to support RPs X, Y, and Z with a TLS server ECDSA key &quot;,</div><=
div>=C2=A0 =C2=A0 &quot;orderProfiles&quot;:=C2=A0[&quot;profile1a&quot;, &=
quot;profile1b&quot;]</div><div>=C2=A0 =C2=A0},</div><div><div>=C2=A0 =C2=
=A0&quot;profile2&quot;: {</div><div>=C2=A0 =C2=A0 &quot;description&quot;:=
 &quot;Use this to support RPs W, X, and Y with a TLS server RSA key&quot;,=
</div><div>=C2=A0 =C2=A0 &quot;orderProfiles&quot;:=C2=A0[&quot;profile2&qu=
ot;]</div><div>=C2=A0 =C2=A0},</div><div></div></div><div>}</div><div><br><=
/div><div>Under this model, acme-profile is specifying single-order-profile=
 config profiles, and profile-sets lets you express the more general thing.=
 The observation is that, even after the human has made all of their decisi=
ons, the best response may be a couple of different orders combined, if the=
 target RPs span a wide range of time, etc.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
(BTW: The example in section 3 would appear to be missing the profileExt,<b=
r>
profile2a, and 2b profiles)<br></blockquote><div><br></div><div>Ah, that=
9;s intentional and comes out of having to construct this separation after =
the fact. That&#39;s covered by this sentence:</div><div><a href=3D"https:/=
/davidben.github.io/acme-profile-sets/draft-davidben-acme-profile-sets.html=
#section-3-7">https://davidben.github.io/acme-profile-sets/draft-davidben-a=
cme-profile-sets.html#section-3-7</a></div><div><br></div><div>The thinking=
 was that the top-level entries, either in profiles{} or profileSets{} are =
the distinct human choices that the CA has assembled for you. Those are wha=
t would appear in a web interface with the description visible. The strings=
 inside profileSets[&lt;name&gt;].profiles[] are the individual order profi=
les, which may or may not be a distinct human-level choice standalone. If t=
hey are, they might also appear in profiles{} (or equivalently a singleton =
in profileSet{}). If they aren&#39;t, they&#39;ll just be random names. Sin=
ce a human will never be picking the individual order profiles, they don=
9;t actually need to appear in the directory.</div><div><br></div><div>It&#=
39;s very gross and I&#39;m sure there are better ways to spell this in JSO=
N. (Thoughts?) I just picked something and clearly didn&#39;t do a great jo=
b of explaining it. :-)</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
SC says:<br>
<br>
=C2=A0 =C2=A0Profile sets allow an ACME Server to help ACME Clients configu=
re<br>
=C2=A0 =C2=A0themselves appropriately during PKI security transitions, such=
 as a<br>
=C2=A0 =C2=A0change in algorithm, a change in trusted CAs, or CA key rotati=
on.<br>
=C2=A0 =C2=A0Most PKIs have far fewer ACME Servers than ACME Clients, with =
ACME<br>
=C2=A0 =C2=A0Server operators well-connected to relying party requirements.=
=C2=A0 This<br>
=C2=A0 =C2=A0can help transitions complete more quickly, and thus allow the=
 PKI to<br>
=C2=A0 =C2=A0realize the security benefits sooner.<br>
<br>
(I don&#39;t think this belongs in Security Considerations, but rather the =
Introduction)<br>
<br>
I don&#39;t know how the client would know what algorithms to use for each =
member<br>
of the profile set.=C2=A0 =C2=A0If the idea is that I might need an EcDSA-o=
nly certificate<br>
and a quantum-safe one (whether it&#39;s hybrid or pure), then I&#39;m not =
sure how<br>
the client figures this out.=C2=A0 If it already knows the details , then I=
&#39;m not<br>
sure what the directory does to help.<br>
<br>
Given that the client has to know about profile sets, and has to pick one,<=
br>
and has to then iterate on each profile, requesting a certificate, I am not=
<br>
convinced that this even needs to be announced by the server.<br>
<br>
So the idea of this document seems useful, but I don&#39;t think this docum=
ent<br>
delivers on what it says it wants to do.<br>
<br>
(I&#39;d rather the document use the term &quot;quantum-safe&quot;, rather =
than<br>
&quot;Post-Quantum&quot;, even if NIST&#39;s competition is called Post-Qua=
ntum, because<br>
that might not be the end of quantum-safety.=C2=A0 ETSI uses quantum-safe.)=
<br></blockquote><div><br></div><div>Ah, I touched on this a bit in the ema=
il here, replying to Mike&#39;s comment on the PQ migration use case.</div>=
<div><a href=3D"https://mailarchive.ietf.org/arch/msg/acme/m9Smynn9AHeHrenh=
ARCNBSJfOsk/#:~:text=3D%3E%20for%20example%2C%20in%20the%20PQ%20Migration%2=
0usecase%20it%27s%20not%20just%20that%20the%20Client%0Awill%20fire%20the%20=
same%20CSR%20at%20both%20the%20%22RSA%22%20and%20%22ML%2DDSA%22%20cert%20pr=
ofiles%3B%20it%0Aactually%20needs%20to%20create%20separate%20RSA%20and%20ML=
%2DDSA%20keys%20/%20CSRs">https://mailarchive.ietf.org/arch/msg/acme/m9Smyn=
n9AHeHrenhARCNBSJfOsk/#:~:text=3D%3E%20for%20example%2C%20in%20the%20PQ%20M=
igration%20usecase%20it%27s%20not%20just%20that%20the%20Client%0Awill%20fir=
e%20the%20same%20CSR%20at%20both%20the%20%22RSA%22%20and%20%22ML%2DDSA%22%2=
0cert%20profiles%3B%20it%0Aactually%20needs%20to%20create%20separate%20RSA%=
20and%20ML%2DDSA%20keys%20/%20CSRs</a></div><div><br></div><div>This isn=
9;t meant to help the ACME client decide which keys it needs. Automating th=
at seems difficult because what key you have isn&#39;t really a property of=
 the ACME server. It&#39;s a property of the ACME client, taking into accou=
nt...</div><div>- What are the capabilities of the protocol it&#39;s using =
the cert in?</div><div>- What are the capabilities of the software it will =
install the cert into?</div><div>- How and where does it provision private =
keys? Maybe it&#39;s already pre-provisioned all its keys into some HSM and=
 making new keys would be a whole ceremony.</div><div>- What kinds of <i>en=
d-entity</i>=C2=A0keys will the desired relying parties support?</div><div>=
<br></div><div>Since that is ultimately a client-side decision, I don&#39;t=
 see a clear space for the ACME server to help. I think we&#39;re going to =
have to do O(num ACME clients) work to perform that part of the transition =
regardless.</div><div><br></div><div>However, that can be made orthogonal t=
o the parts that come from the ACME server and general state of the PKI:</d=
iv><div>- What=C2=A0specific CA keys does each relying party trust?</div><d=
iv>- What CA signature algorithms does each relying party accept?</div><div=
><br></div><div><i>That</i>=C2=A0can be automated by the ACME server, and i=
s a place where multiple certificates can be helpful. For specifically the =
case of the PQ transition and things like it (not the only use case, but on=
e of them), it&#39;s true that we eventually need to do both halves. But th=
ere&#39;s a compelling downgrade protection reason to automate the PKI half=
 and do it separately, mentioned in that email.</div><div><br></div><div>Do=
es that make the thinking a bit clearer?</div><div><br></div><div>David</di=
v></div></div>

--000000000000f3f58d0647e4325a--