Hi David, Yeah, I wasn't sure that my ca-recommended-crypto-policy was a good idea, but brainstorming bad ideas aften helps cut to the core of the matter.
You said: > 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. So, this raises another question, pertaining to the "A" in "ACME", which is "Automated". The more we talk about humans needing to manually check the profile and set config on the ACME client, the more we stray from that "A". The WG is not necessarily chartered to only consider fully-automated mechanisms, but I think it is worth considering. Specifically, the question I want to consider here is what happens as the CA evolves their cert profiles over time? In the simple case of Aaron's profiles draft, I imagine that CAs will publish some default profiles like "tlsServerCAB" or "tlsServerQWAC" or "codesigning", which will be assumed to stay synced to the relevant regulatory policy. The way those regulatory policies evolve don't tend to make compatibility-breaking changes to the types of CSRs or SAN values that will be accepted under that profile. IE this seems like it's pushing is towards the "A" -- once you point your ACME Client to a given profile, it will require fewer human touches over time. I'm less convinced about profile-sets; with the number of times you talked about configs and human intervention, I feel like we're almost expecting that every time a CA changes a profile-set, we're expecting that every ACME Client will need to have a human re-read the CA's documentation on that profile set and maybe make changes to the config of their ACME Client, like the type of CSR key or list of SANs included in the request. Ilari also makes the excellent point that a profile-set may be making a recommendation that's incompatible with your webserver technology stack -- for example if a profile-set suddenly adds a 2-chain version of the existing 3-chain profile, or adds a no-ocsp version of the one that normally comes with ocsp-staple, your ACME client may blow up when you try to insert those into your webserver, or your webserver may blow up in handshake when your server stack isn't designed to switch those sorts of things on a per-SNI basis. My intuition tells me that dynamically abstracting this kind of thing will increase the number of runtime errors requiring human intervention, not decrease it. If your goal here is for the CA to publish guidance on what type and how many TLS certs your webserver should have for maximum interop and performance with known relying parties -- I like that goal and I think that CAs are in a good position to give that guidance, but I'm not sure that profile-sets is the right technical mechanism since it sits in a valley of being potentially highly dynamic and also not machine-readable. Anyway, I'm starting to repeat myself, so I'll let this thread lie for others to comment. On Thu, 8 Jan 2026 at 13:55, David Benjamin <[email protected]> wrote: > 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]
