On Thu, Jan 8, 2026 at 2:25 PM Ilari Liusvaara <[email protected]> wrote:
> On Thu, Jan 08, 2026 at 12:30:34PM -0500, David Benjamin wrote: > > On Thu, Jan 8, 2026 at 12:12 PM Michael Richardson < > [email protected]> > > wrote: > > > > > I don't think ACME Profile Sets completely solves the problem > described in > > > the slides. We need more. Maybe a connection to RFC9908 (just > issued, > > > but > > > not announced yet.. weird)... a CSR/CSR-attributes redo in > JSON/JOSE/COSE > > > could be part of an RFC7030bis. Worth further discussion, I hope. > > > > > > > The aim is to specifically solve the case where the subject information > in > > all the variants is the same, as that seems to be where this kind of > > automation most naturally fits. It's true there are a bunch of other, > more > > complex, cases where folks might need multiple certificates. Those seem > > hard to automate because they require the ACME client to have knowledge > of > > the variations, but happy to be proven wrong. :-) > > > > Not to say those aren't also interesting problems, but this subset seems > > both useful, fairly easily achievable, and fit within a clear "subject > > decisions vs PKI decisions" model, so that seemed a good place to draw a > > box. > > I do not think profile sets would be helpful with key algorithm > transitions (e.g. ECDSA, post-quantum) or with CAs getting distrusted. > > Profiles do not specify key algorithms (so client has no guidance on > key algorithms) I talked a bit about end-entity algorithms here: 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 Profiles don't, and can't determine the end-entity key algorithm because the TLS server operator (or someone even further up the stack) is the one that generates it, based on the capabilities of their server software (or whatever). I'm not trying to use ACME to help here. ACME consumes the EE key, not producing it. But I think ACME can help with the *CA key and CA signature*, and separating the two is valuable. For security-motivated transitions, it lets us get to a place of downgrade protection sooner. (See that link.) For size-motivated transitions (RSA -> ECDSA), it gives us perf wins immediately. > and ACME servers are usually specific to CA (so distrust > requires switching servers). > ACME servers *aren't* specific to a CA. CA *operators* often operate multiple CA instances and the same ACME server may issue from any of them. (They may even use profiles to select between them!) Those kinds of transitions can fit this mold already. Now, it's true that an ACME server usually only gives certs from one CA *operator*, presumably the operator of the ACME server. But there's no protocol constraint here. If the PKI changes, it is an ACME server operator may well decide they want to add a new profile alongside the existing one. That can provide value for their clients, since their sites can now keep working without manual intervention. I think it is quite plausible that service providers would look for ways to continue to serve their clients when situations change and, when they wish to do that, this draft offers a tool they can consider. > Then effectively using multiple certificates at once requires webserver > support. And in many of the usecases, supporting TLS extension that > has not been defined yet. > > Furthermore, having variable number of certificates would require major > changes to configuration models of various webservers (most webservers > do not do full mix-and-match with keys, certificates and virtual > hosts). Yup! As with anything in ACME, it is only useful if the rest of your system can consume the output. Profile sets doesn't directly solve that part because this is ACME and using the resulting certificate(s) is not part of ACME's scope. The draft says a little about this, but mostly just points to some TLS mechanisms. https://davidben.github.io/acme-profile-sets/draft-davidben-acme-profile-sets.html#section-4-6 As a TLS server operator, when you use an ACME URL or ACME profile, you look at what that ACME server provides and decide if it's what you want. (Is it S/MIME but you want a TLS server?) In the same vein, if a profile set gives back a certificate set that is meant to be dispatched by the TLS signature_algorithms(_cert) extension, or the certificate_authorities extension, or the trust_anchors extension, your server software has to be able to deal with it. That's part of the decision around whether this config choice is what you want. The draft just follows existing practice with acme-profiles and ACME itself: rather than trying to encode all those properties programmatically, use a human description that can be evaluated at configuration time. (I think one of my takeaways here is that both this document and perhaps acme-profiles should make it clearer what this means. I can noodle on improvements across the two drafts.) I think you're also alluding to the fact that many TLS server stacks aren't very good at certificate selection right now. Big operators can always write custom code, but built-in mechanisms aren't as common. For my own TLS stack, I tried to change this with some built-in credential selection machinery a bit ago, and I see other stacks moving this way too. I hope that will change more as PQ migration, or the work in PLANTS, make the need for this kind of capability clearer. Like most IETF things, this is forward-looking. We can define the protocols, but different parts of a larger system will take time to build everything out. > Furhermore, ACME clients might not be permitted to generate > keys (and webservers might react rather badly to unsupported keys). Yup, to repeat from elsewhere in the thread, I am *not* proposing to do anything about the EE key. This is indeed one of those reasons. ACME is not a place where we can automate EE key transitions, and that is fine. Rather, I'm saying that solving this *other* problem separately, is still valuable, and that there is a lot to be gained by separating them. David
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
