For the use case of someone setting up a system on one CA, I can see it making sense. (Though there's no good standard for clients to alert their administrators when something changes, since it seems that there are many "zombie" clients out there trying every day to revalidate a domain that they no longer control, without anyone noticing or caring.)
But for @webprofusion's (and others') concern about configuring multiple CAs, it would be nice if all that was needed was a list of CA URLs rather than needing to also configure each CA with which features and profiles it supports. That is, I think you're worrying about one problem, while client authors designed for large integrations worry about a different problem, and they all probably need to get addressed eventually.
Yeah, I totally agree that it would be great for a client to just be configured with a list of potential directory URLs, and for it to handle everything from there. That would be glorious.
But I think the devil is in the details.
First we turn to the question of what features or capabilities the CA advertises. As discussed above, there are a lot of possible aspects of a profile that might need to be advertised. If we're letting clients pick values for those features, then there are combinations of values that are unacceptable, so we need a way to communicate that, too. Even if we're not letting clients pick, and just advertising the features of each profile so they can make an informed decision, then we need to have well-known names for every aspect of a profile. If we try to predict which aspects future CAs and clients will care about, we'll be wrong. If we try to build an extensible system that can flexibly describe every aspect of a certificate... that's just x509, ASN.1, and OIDs.
But let's assume that we figure out how a CA is going to advertise all of the details of its profiles. Then how does a client pick a profile based on that information?
It doesn't seem reasonable for the client to do all of the picking; the whole point is that different users might have different preferences. So the client needs to be configurable: every possible item that a CA might advertise, the client needs to have a configuration field that the user can fill out to indicate whether it wants that item. And of course many profile aspects are not just booleans (like "does it have OCSP Must-Staple") but may be enums (like "what set of RSA key sizes do they support") or numeric ranges (like "what validity periods do they offer"). And for each of those, it not only needs to be able to validate the input (did you put P-256 for an RSA key size you like?), but it may need to accept multiple acceptable inputs (you're fine with just TLSServerAuth, or ServerAuth+ClientAuth), and it may need to let you rank those options (you prefer 90-day certs over 365-day certs).
Honestly, I find it hard to believe that many (or any) client authors would implement such a complex configuration system. It's pretty unclear to me how to make such a system intuitive and usable.
But! Let's assume that you solve that, and your client has a robust system for letting the user configure their exact set of preferences and priorities. A user says that they prefer ECDSA-only over RSA, that they prefer TLSServerAuth-only over ServerAuth+ClientAuth, and that they prefer 10-day certs over 90-day certs. They configure three potential CAs. Each of those three CAs satisfies two of the three expressed preferences. How do you pick which one to use?
All of this, put together, is why I currently believe that complex capability advertisement, configuration, negotiation, ranking, and selection is not the best path forward. I think that CAs should advertise a few profiles with human-readable descriptions and sane defaults, and human site operators should generally trust the CA to make widely-compatible choices (as they do today!) and only select alternate profiles from the CA's carefully-curated set of options when they really want or need something specific.
Noted. I think our perspectives are different on this but that's OK. The main difficulty I see comes in trying to capture the capabilities in a standard spec and iterating on that as different capabilities are introduced, which RFCs really aren't designed for (they're very much a point in time).
Yes, CA fallback selection based on graceful degradation of features is complex, it also happens to be something my client already attempts to do, which is where my interest comes in. I accept it's not a priority for most.
I think it's fair to say that the concerns of one ACME client are not that same as another (Cerbot doesn't implement ARI, for example) but at the same time designing for the extreme case may not be broadly beneficial.
So, the goal of my request is to enable Clients to help Subscribers make the right decisions as easily as possible. It is entirely inspired by the last phrase above that I highlighted in bold - the client must parse the chains first.
This doesn't just mean the client must parse the chain(s), but the client must go through the entire certificate procurement process to get the chain(s).
I think this is a disconnect we are having. From my perspective, your idea of a Profile is a perfect mechanism in which the Server can advertise what the eventual chain selection options will be before going through the procurement process. The client would still handle Chain Selection according to it's own logic, and be able to construct the alternate chains. Advertising this before the Certificate is procured is preferred as it is easier to catch changes and incompatibilities.
100% in agreement with you on this.
Building off your real-world example, consider this scenario which will be a real-world concern:
Today: EE <-- E1 <-- X2 <-- X1 <-- DST [default] EE <-- E1 <-- X2
2024-02-08: EE <-- E1 <-- X2 [default] EE <-- E1 <-- X2 <-- X1 <-- DST
2024-06-06*: EE <-- E1 <-- X2 [default]
2024-09-30*: DST Expires
So in this situation which has the benefit of prior announcements and planning for all parties involved, we'll first see the default chains first switch, then one stops signing new Certificates before retirement. As a Subscriber - this advance notices gives me time to decide which options work or not -- and gives some guidance on how to ensure my preferred chain/root can be selected by the Client. (Sidenote: my original idea was for the server to advertise the full chains, so Clients would be influenced towards a standardized way to configure chain selection. i.e. serving names will influence against thumbprints, etc.] This situation is easy to work with – but what happens when there is an unplanned change?
Depending on your website, Roots (and Key Types) can influence audience reach and site performance quite a bit. I know some properties that have decided to go RSA/DST-X1 until the last possible minute, then they'll jump to ECDSA/X2 - which best maximizes both reach and performance over RSA/X1. I know many other properties that simply don't care, as the the differences are negligible – they'll be happy to server whatever LetsEncrypt currently offers.
Catching these changes in offered roots/chains requires two tasks that are not suitable for automation:
Diligently reading all Announcements and Documentation from CAs/Servers
Obtaining (a metered) Certificate and Chains, then analyzing them
I do not think the second option can be considered a candidate for automation because:
The certificates are metered. ISRG imposes limits on Certificates per Domain and Duplicate Certificates. Commercial CAs impose limits on overall certificates. I firmly believe that needing to consume a resource to determine if it is even usable is an anti-pattern.
The order must be completed and fully downloaded for the chain analysis to happen. This takes an increasingly larger amount of time depending on the amount of challenges that must be completed.
Many current clients are written in ways where procuring an unwanted certificate chain is likely deploy that chain and restart services under it. This can have negative effects.
To better inform clients of what to expect, the relevant information from chains can be stuffed into profile variants:
"default": "The profile that Let's Encrypt has been using for the last 6+ years."
A "default" profile is great, and works for the majority of users. Using this to onboard the "short" Certificates and stripped down features is also a brilliant idea. This works very well for Clients.
From the perspective of a Subscriber - we're seeing LetsEncrypt advertise certain capabilities - while still being silent on one of the bigger concerns that will primarily affect reach and usability. OCSP, lifetime, etc are not going to affect reach and experience; switching to an incompatible root can drop traffic by double digits or more.
If we were able to use "variants" however, we could advertise the most important bits of the Chain(s) which will be offered without needing to go through the procurement process or risk restarting services.
Consider how variants might look during the planned root retirement. I'm just naming the variants by the Root:
Today:
"variants": {
"DST": "X2->X1->DST",
"X2": "X2",
}
2024-02-08:
"variants": {
"DST": "X2->X1->DST",
"X2": "X2",
}
2024-06-06*:
"variants": {
"X2": "X2",
}
The Server would still offer all chains during finalization. The Clients would still be obligated to parse (and hopefully store) all chains during finalization. What changes though, is that clients would immediately see on the Directory there has been a material change to the expected chain offerings.
In practice, I imagine things would work like this:
Most Subscribers just go with the "default" option and allow ISRG to choose the best options.
The Subscribers who require a certain chain will specify a chain as they currently do, but it can be pinned to a variant marker.
Upon renewal, the Client will first notice if the variant marker is no longer offered. If the variant is no longer offered... SIRENS the Client immediately alerts the Subscriber. If the variant is offered, everything proceeds as normal.
"Variants" could even be called "Roots" here.
This doesn't enable full automation or the negotiation of Certificate specifics - it just allows Clients to immediately detect a materially significant change before committing to a metered process that can write files and relaunch services with unintended or incompatible roots.
Me too. This shouldn't require getting a Certificate to discover, and it would be wonderful if the specs (or servers) guided Clients into standardized ways to identify the chain so the selections would better persist across clients when subscribers have to switch.
I think eventually ACME will support, or be replaced by, a spect that allows for all this customization. I don't think now is the time for that.
What I do want to stress though, is the current behavior of ACME and Boulder is to make all of these sane choices and defaults - but fail to identify the material changes to these offerings as they happen. Most changes do not have substantial effects, but root offerings does. A Client should be able to query the server and determine if the preferred chain / root is no longer available (or not) before procuring a Certificate. Providing that ability would address the concerns that many of us developers have, and is not jumping into the waters of complex configuration or negotiation.
Apologies, I don't have time to write up a full reply at the moment, but I can do this little bit:
Heh, I think this is the disconnect we're having. It's not that I see profiles as a pre-issuance thing, and chain selection as a post-issuance thing. It's that I see profiles as a "impacts the actual contents of the certificate" thing, while chain-selection is a "post-hoc, can be changed even days or weeks after the certificate is issued" thing.