On Thu, Jan 8, 2026 at 12:03 PM Michael Richardson <[email protected]>
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 profile
> 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-sets.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 how
> 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 not
> 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 document
> 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, because
> 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=%3E%20for%20example%2C%20in%20the%20PQ%20Migration%20usecase%20it%27s%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%0Aactually%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
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
