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 <https://community.letsencrypt.org/t/upcoming-changes-to-let-s-encrypt-certificates/243873/3?u=aarongable> our "tlsserver" and "shortlived" profiles to issue from a new set of intermediates <https://letsencrypt.org/certificates/#:~:text=YE1%20%E2%86%90%20Root%20YE-,Let%E2%80%99s%20Encrypt%20YE2,-Subject%3A%20O>, 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]
