MIME-Version: 1.0
References: 
 <CAKZgXHqkK--vPiC35O5dA7W9x_dBzss4Me0ymLoyURUE8Uq6zA@mail.gmail.com>
 <CAEmnErcw-2JunoUZs6jXj1GienP9EHa9F7yuHM8rb5xxXy3+Nw@mail.gmail.com>
In-Reply-To: 
 <CAEmnErcw-2JunoUZs6jXj1GienP9EHa9F7yuHM8rb5xxXy3+Nw@mail.gmail.com>
From: Mike Ounsworth <ounsworth+ietf@gmail.com>
Date: Sun, 11 Jan 2026 18:29:27 -0600
Message-ID: 
 <CAKZgXHpjsjoa19pxTqQwWj1Amqd+h0T4j3+OXaQgto96_ZhWWg@mail.gmail.com>
To: Aaron Gable <aaron@letsencrypt.org>
Content-Type: multipart/alternative; boundary="00000000000060ddcb064825f8d1"
Message-ID-Hash: APNGSGI24AHHLR6TKXQ4YZ5IELIJENAP
CC: draft-ietf-acme-profiles@ietf.org, IETF ACME <acme@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BAcme=5D_Re=3A_Comment_on_draft-ietf-acme-profiles_about_change_?=
	=?utf-8?q?management?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/acme/2cwTnSX7GnUqMFDdyl2R0pZzE18>

--00000000000060ddcb064825f8d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 <aaron@letsencrypt.org> wrote:

> Hi Mike,
>
> Responding to pull-quotes inline below:
>
> On Thu, Jan 8, 2026 at 4:36=E2=80=AFPM Mike Ounsworth <ounsworth+ietf@gma=
il.com>
> 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 u=
p
> 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 a=
ll
> ACME clients have gotten along just fine with only a single default profi=
le
> 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 th=
e
> 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=3Dalternate headers on the certificate download.
>

--00000000000060ddcb064825f8d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hmm. ok.</div><div><br></div><div>PS I didn&#39;t &qu=
ot;length of the validation chain&quot; as in &quot;whether or not the CA s=
ervers the intermediate&quot;, I meant, like, the CA actually physically ad=
ds or removes a layer of CA. I think I&#39;m thinking that the PQ era will =
involve changes larger than the changes we&#39;ve seen over the past decade=
, but I&#39;m also ok to leave it.</div></div><br><div class=3D"gmail_quote=
 gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 9 Jan=
 2026 at 17:03, Aaron Gable &lt;<a href=3D"mailto:aaron@letsencrypt.org">aa=
ron@letsencrypt.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Hi Mike,</div><div dir=
=3D"ltr"><br></div><div dir=3D"ltr">Responding to pull-quotes inline below:=
<br><div><br></div><div>On Thu, Jan 8, 2026 at 4:36=E2=80=AFPM Mike Ounswor=
th &lt;<a href=3D"mailto:ounsworth%2Bietf@gmail.com" target=3D"_blank">ouns=
worth+ietf@gmail.com</a>&gt; wrote:</div></div><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I th=
ink there&#39;s an assumption here that the CA is free to evolve their offe=
red profiles over time;</div></div></blockquote><div><br></div><div>Yes, th=
ey are, and they always have been: every ACME CA for the last decade has be=
en evolving their single default profile over time to keep up with changing=
 requirements and best practices.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>But then, how much c=
hange is too much change that the CA really ought to declare a new profile =
and deprecate the old one?</div></div></blockquote><div><br></div><div>That=
&#39;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 dep=
recating a profile breaks all clients which are explicitly requesting that =
profile, until their operators notice and update their profile configuratio=
n.</div><div><br></div><div>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 on=
ly a single default profile for the last decade). It would be surprising fo=
r a client to request profile `foo` and instead get an order with profile `=
bar` because the CA has deprecated `foo`.</div><div><br></div><div>But this=
 also means that CAs should generally not design profiles with the intent t=
o deprecate them. In turn, &quot;versioning&quot; profiles will cause site =
operators to have to update their requested profile configuration frequentl=
y, and/or require the CA to support many ancient version numbers lest=C2=A0=
they risk breaking anyone requesting that specific version.</div><div><br><=
/div><div>I think that any mention of versioning (whether normative or mere=
ly a suggestion) within this draft will lead both CAs and clients to believ=
e that profiles are meant to be immutable, and that way lies sadness. If th=
ere is to be any discussion of versioning within this document, I would wan=
t it to be an exhortation against versioning, as it breaks the longstanding=
 contract of &quot;trust the CA to make the best decision possible given th=
e current regulatory environment&quot;.</div><div><br></div><div>Thanks,</d=
iv><div>Aaron</div><div><br></div><div>P.S.:</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>if you chan=
ged the length of the CA cert path, </div></div></blockquote><div><br></div=
><div>Note that, in ACME, the length of the validation chain shouldn&#39;t =
be influenced by the profile; that&#39;s instead controlled post hoc via li=
nk rel=3Dalternate headers on the certificate download.</div></div></div>
</blockquote></div>

--00000000000060ddcb064825f8d1--