[Acme] Re: Comment on draft-ietf-acme-profiles about change management

[Mike Ounsworth <[e-mail]>]

> 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.

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 <[e-mail]> 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
> <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 <[e-mail]>
> 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 <[e-mail]> wrote:
>>
>>> Hi Mike,
>>>
>>> Responding to pull-quotes inline below:
>>>
>>> On Thu, Jan 8, 2026 at 4:36 PM Mike Ounsworth <[e-mail]>
>>> 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.
>>>
>>