> On Jan 21, 2026, at 09:02, Mike Ounsworth <[email protected]> wrote: > > > We did this [adding an extra layer to the Let's Encrypt CA chain] without > > making any changes to our advertised profiles or their documentation, and > > without any targeted outreach to subscribers. So far we have not observed > > or heard reports of any breakage. > > That's actually a great datapoint! Could it be that decades of overly-complex > X.509 standards means that most client and server applications actually > handle edge-cases reasonably well (like cert chains with lengths other than > 3)? I'm shocked.
Since this is just adding an intermediate to an existing trust anchor, and doesn’t involve cross signs or possibly multiple paths that rely on path building logic to decide what you get to, I’m not shocked that it just worked. You should think of this rather that this is the one case the implementations do handle without issue, not that the situation of what’s deployed is really much better ;) > > Ok, maybe profiles aren't as brittle as I'm afraid, and therefore there's no > good reason to version them. Thanks for entertaining my idea! > > On Mon, 12 Jan 2026 at 11:29, Aaron Gable <[email protected]> wrote: > Ah, I understand. Yeah, that's something that CAs have historically changed > without any particular need to notify subscribers or update profiles, and I > hope that this remains true in the future. For example, Let's Encrypt just > shifted our "tlsserver" and "shortlived" profiles to issue from a new set of > intermediates, whose chains up to trusted roots are one certificate longer > than they used to be. We did this without making any changes to our > advertised profiles or their documentation, and without any targeted outreach > to subscribers. So far we have not observed or heard reports of any breakage. > > I definitely don't want the existence of profiles to mean that such changes > in the future would be expected to be more complex. > > Aaron > > On Sun, Jan 11, 2026 at 4:29 PM Mike Ounsworth <[email protected]> > wrote: > Hmm. ok. > > PS I didn't "length of the validation chain" as in "whether or not the CA > servers the intermediate", I meant, like, the CA actually physically adds or > removes a layer of CA. I think I'm thinking that the PQ era will involve > changes larger than the changes we've seen over the past decade, but I'm also > ok to leave it. > > On Fri, 9 Jan 2026 at 17:03, Aaron Gable <[email protected]> wrote: > Hi Mike, > > Responding to pull-quotes inline below: > > On Thu, Jan 8, 2026 at 4:36 PM Mike Ounsworth <[email protected]> > wrote: > I think there's an assumption here that the CA is free to evolve their > offered profiles over time; > > Yes, they are, and they always have been: every ACME CA for the last decade > has been evolving their single default profile over time to keep up with > changing requirements and best practices. > But then, how much change is too much change that the CA really ought to > declare a new profile and deprecate the old one? > > That's a very, very high bar. Note that the draft says that requests for an > unrecognized profile MUST be rejected by the CA. This means that fully > deprecating a profile breaks all clients which are explicitly requesting that > profile, until their operators notice and update their profile configuration. > > This is on purpose. We believe that if a client is requesting a specific > profile, it is probably doing so for good reason (especially given that all > ACME clients have gotten along just fine with only a single default profile > for the last decade). It would be surprising for a client to request profile > `foo` and instead get an order with profile `bar` because the CA has > deprecated `foo`. > > But this also means that CAs should generally not design profiles with the > intent to deprecate them. In turn, "versioning" profiles will cause site > operators to have to update their requested profile configuration frequently, > and/or require the CA to support many ancient version numbers lest they risk > breaking anyone requesting that specific version. > > I think that any mention of versioning (whether normative or merely a > suggestion) within this draft will lead both CAs and clients to believe that > profiles are meant to be immutable, and that way lies sadness. If there is to > be any discussion of versioning within this document, I would want it to be > an exhortation against versioning, as it breaks the longstanding contract of > "trust the CA to make the best decision possible given the current regulatory > environment". > > Thanks, > Aaron > > P.S.: > if you changed the length of the CA cert path, > > Note that, in ACME, the length of the validation chain shouldn't be > influenced by the profile; that's instead controlled post hoc via link > rel=alternate headers on the certificate download. > _______________________________________________ > 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]
