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

[Mike Ounsworth <[e-mail]>]

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