On Thu, Jan 8, 2026 at 2:25 PM Mike Ounsworth <[email protected]> wrote:
> (this thread is getting a bit lengthy, I skimmed and may have missed > something, sorry). > > David Benjamin <[email protected]> wrote: > > 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 > > Here's the thing that gives me pause about this framing: > You're framing this as the CA (ACME Server) telling the web server > operator what set of certificates it should host. That's the CA > pushing cryptographic policy to the web hosting provider. While I > personally believe that CAs are experts in this and are in a good > position to make crypto policy recommendations, I have in the past > (when I represented a public CA) been literally yelled at during IETF > sessions by browser people (one of your at-the-time esteemed > colleagues in fact) and web hosting providers along the lines of "Stay > In Your Lane CA! Ain't No CA Gonna Tell Me How To Set Crypto Policy". > So I'm not sure that this framing is well motivated by political > precedent. > (yes, this is my past IETF trauma rearing its head again). > Whelp. Being yelled at is certainly unpleasant. I have had my share of unconstructive IETF conduct aimed at me, and quite a few scars as a result, so I can certainly sympathize. I'm sorry you went through that. :-( I don't know what the specific context was there (doesn't sound like I was in that conversation?), so I'm not really sure how to apply it here. "Crypto policy" is a pretty broad and ill-defined thing, so it's not really meaningful to speak about it in general. But, no, I'm not proposing to shift any Policy(TM) responsibilities anywhere they aren't already. It's already, and somewhat fundamentally, the case that each PKI role is responsible for making decisions and/or imposing requirements in different places here (CA signature, EE key type, CA key, which CA, validation procedures, certificate details, TLS settings, etc.), all of which fits in "crypto policy". Did you have a specific thing to examine here? > Just thinking-out-loud here: If the deployment problem that you're > trying to solve with the profile-sets draft is actually better > described as "CA-recommended-crypto-policy", then maybe we should do a > draft that specifically does that well? > > I'm thinking something of this shape: > > A new directory object: > > recommendedCryptoPolicies: { > "tlsCryptoPolicy": "https://example.com/acme/tlsCryptoPolicy";, > "smimeCryptoPolicy": "https://example.com/acme/smimeCryptoPolicy"; > } > > where fetching that gives you this: > > GET https://example.com/acme/tlsCryptoPolicy > ... > { > "MldsaRootEccEE": { > "CaAlg": "ML-DSA-65", > "EeAlg": "ECDSA-P256", > "profile": "profile1" > }, > "Mldsa": { > "CaAlg": "ML-DSA-65", > "EeAlg": "ML-DSA-65", > "profile": "profile2" > } > } > > where the algs map to some registered alg strings, maybe in the JOSE > registry, and the profile IDs map to those published by the CA in > their ACME directory as per Aaron's draft. > > I'm not sure this is a good idea ... I'm just brainstorming out loud. > This seems rather more complicated, and I think is over-fixating on the algorithms component. I don't think the extra machinery is *necessary* here for the same reason it wasn't *necessary* for acme-profiles. Think back to acme-profile's decision to use human descriptions and human choices. Even ignoring profile sets, it is *already* the case that some profiles may be only appropriate for S/MIME, some for TLS client certificates, some for servers, some for ECDSA, some for RSA, some for older web browsers, some for newer web browsers, some for only IoT devices. acme-profiles (very reasonably), gives the CA broad latitude here. Ilari alludes to another set of properties, which is whether the thing consuming the certificate is capable of dispatching certificates on this criteria, that criteria, etc. Now, we *could* have encoded all of that programmatically, as you suggest here. That would have allowed an ACME client to, say, filter the list of choices before presenting them to the human configuring things. But that's much, much more complex, acme-profiles picked a simpler design, where we just leave that to the human picking which profile to put in their config file. I think this is a good place to draw a box because it is simple and broadly works. Maybe we could do more, but it's a clear starting point. acme-profile-sets simply follows that existing pattern. Yes, we could encode all that in some structure. Or we could just say this is a human matter between the people documenting the profile sets at the ACME server, and the people configuring the appropriate set when configuring the ACME client. Yes, to do that, they will need to use documentation and words to agree "this is for S/MIME" or "this one will give me a bunch of certs assuming you support TLS signature_algorithms and TLS trust_anchors, or whatever else", but that's no different from acme-profiles itself, or the choice of ACME URL altogether. (At the least it sounds like I definitely need to put more words into the draft to elaborate on the model! I was originally assuming it was implicit from acme-profiles, but good to be clear on it.) On Thu, 8 Jan 2026 at 12:02, David Benjamin <[email protected]> wrote: > > > > 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] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
