Return-Path: X-Original-To: acme@mail2.ietf.org Delivered-To: acme@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6EF6AAAFB580 for ; Wed, 21 Jan 2026 08:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfoKiyES9zgi for ; Wed, 21 Jan 2026 08:02:24 -0800 (PST) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0461CAAFB576 for ; Wed, 21 Jan 2026 08:02:24 -0800 (PST) Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-65f65538a90so717175eaf.1 for ; Wed, 21 Jan 2026 08:02:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769011337; cv=none; d=google.com; s=arc-20240605; b=BQkRCiychQvZZfvotTDPPDvK5F8h1j7nG31g9Sju0Fh6BMf460Yp02MJiIuELH/OWR U2y6tqHBq1Ztnl4eyvhHkvM9hANxqyEgFG5QRVIGCFSMeh5ThKMUaPBbYIAiJFMNzd5V HNKGqRgsCp1JnV/lgsTUHDt1ob/C9yD+drNz4AcOkMHKkwUrKiVWtXHpHSRBM0oBthZS AN/DeXTLaYp9FZdaMEbA3DQPQIYdaAC8S+vhDVR093MJPup9WcZXbA1MHepDgI9ytEvy g62AkZmpXkXr8OjWx/06pRBDCIzcY9Un/P3Q3Vqyu9AzkHi7J3rVD5+mV5V1rK2Wc5qQ ng2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=u2CAvhEurTo8FDyNl0GpiAcU6RU4b0kP3U2ivzfmf4w=; fh=aGMaY330p82usxTGBLFjRWfc3oIrfp3YmZU/dYERwI0=; b=i45VenDTCY4bbphdo+gqcyXSNuslLYeupWpOwu983aYE3bp0FVvRAPQbqa/EiTWfyW zkL/WYx4MTkKSreYn3F+XBowB+6sjFwLG1r6Ay6os7E8KUjlBlOx1NJyXNveQG0j/ntj 7rkC0tpX6CFw7JDNlt57rNU6tCAomPz0VsivTebdpCDGMUG402dnFn3u9lsQHes34OKc Z/VqAc74SXE1iFXsv4Rp4PLIXmMgdC3Zbjb0RJ6CjphuQmtms/zgf20M5nEP4XbVV4Eg vPoanC44oa6dLq5uurL3ZW/0ILWczMH0ogsieiQ9m74TRpeSRbZ11Kff/qVAU40LntzQ 88uA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769011337; x=1769616137; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u2CAvhEurTo8FDyNl0GpiAcU6RU4b0kP3U2ivzfmf4w=; b=Zy20Xo1Po+aip9SsCRVA2170oxkB8rpGKiGkiSdEo/XaRvubbn/FmRhkv/h8eW/a/s Xp6cI+S0AztuOxdJv7rDSjxfTrbSc4ZnkavWIVNo6mN6nk2LS6xiva641goL66vpnyVo JuGhT0eAJKB4h81UutwKnLGn00AGVm3gHZtE1l/FVlbdsoC7QsMCIubvZ/RdTVwnn03m qf3lg9/OSU4HiBD328fi+1bzSxe8LgWLAZT79yOXJPGNtO/b+KXT2ENrqBwGtagTOtn7 Sb7b3gvoA0Kvo/a712Bia5i5I26wKY2XiCT21aKwociahb4ZV5ws4zCN3tXcdkCCrQfP wGww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769011337; x=1769616137; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=u2CAvhEurTo8FDyNl0GpiAcU6RU4b0kP3U2ivzfmf4w=; b=d1ijdPtxn8qGg0iRPYVmBzVlV57AsypkclPX3TkYUIZQ5I5A2jxUJD5DaiGVFzNqy/ mgH0P8CyUXF4sKlLnTAXZouYsdwOsmuLjbRcLn2DRuOD/bc7keVDemx8/hh+Tq2HEYAE hxvwl8CwJJ0K1gypzOKpoKBqNHtAn5yWskv4qopGt82GpEVbdGtG7VPYH/IlPgZYWpBa 4iFW/H7zDh3cQfTWEwLIHkdRaRLlT6Bb2eNCPlSXmm9EWPSJqqgZy/CGsf9MyGNqEI8r 6bzSA2CBd3JuKaPd9LHPn9Am4ByxYEzorWE0FHlOwY2kUZyB2uqq5tS7/0kn+kVt8CYq 9+1g== X-Forwarded-Encrypted: i=1; AJvYcCUfHgwzJWcft5s0Q1ft4yrASWMLGKhC2YNWi+yRpJJG0jZ/KFhj6xUkF2VZ2wH4ogBiEckf@ietf.org X-Gm-Message-State: AOJu0YxX7EmbiDvcKiq6KpytpnLZn1R1lg0OLU5oc37eruSnFbeUjJT+ YepyGkUsSBAEnyrrhb7YAC53fPotzmZt3s3fFs1mUV5Ie2NGNWoDhyLBoDL4c+Ja+H6UjmK2RjW uB6ieyhZo11uKrMEUFsMLYgDrflia8MU= X-Gm-Gg: AZuq6aIL01ZuIDmvKq1GXHA+55sFYuB4hkqWmR6ArzSx5MW1xatLxLZhiYaAFa7ZKTX mMiftzL3OtRq7dB7j0YBwuCKyaDkFQ/NGrboepgV22LcTUn+H7Kp0k6CjJj2AbhGDjh14KNsX2F aMr3UAu32lP/lxd1Ir2sKHsF0ci+9D5JYSnbkcHIZS02AI/l9ck2P+UMMXdNW4TAMIgaz9cAkRo vcdw6tIjw1HFs55fFeu49bdJxu7JbuhihikFOLGQKRlOPyCxJ1jHdn3y6e4bC34fR9rmI7gdQ== X-Received: by 2002:a4a:d9d3:0:b0:65f:547d:7e76 with SMTP id 006d021491bc7-6610e59a1c6mr7040036eaf.4.1769011332206; Wed, 21 Jan 2026 08:02:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mike Ounsworth Date: Wed, 21 Jan 2026 10:02:00 -0600 X-Gm-Features: AZwV_QiN7oKw-0leQehS-b6anAQPiKU9PS0ioOar0K5UA6A5OBsKRkVb5JUNQZA Message-ID: To: Aaron Gable Content-Type: multipart/alternative; boundary="0000000000000f55300648e80c83" Message-ID-Hash: RJMFURZE4IHBGWQNUKNV4GYQO57KBWWF X-Message-ID-Hash: RJMFURZE4IHBGWQNUKNV4GYQO57KBWWF X-MailFrom: ounsworth@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-acme.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-ietf-acme-profiles@ietf.org, IETF ACME X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BAcme=5D_Re=3A_Comment_on_draft-ietf-acme-profiles_about_change_?= =?utf-8?q?management?= List-Id: Automated Certificate Management Environment Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000000f55300648e80c83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 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 use= d > 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=E2=80=AFPM Mike Ounsworth > wrote: > >> Hmm. ok. >> >> PS I didn't "length of the validation chain" as in "whether or not the C= A >> servers the intermediate", I meant, like, the CA actually physically add= s >> or removes a layer of CA. I think I'm thinking that the PQ era will invo= lve >> 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 wrote: >> >>> Hi Mike, >>> >>> Responding to pull-quotes inline below: >>> >>> On Thu, Jan 8, 2026 at 4:36=E2=80=AFPM Mike Ounsworth >>> 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 fo= r >>> an unrecognized profile MUST be rejected by the CA. This means that ful= ly >>> deprecating a profile breaks all clients which are explicitly requestin= g >>> that profile, until their operators notice and update their profile >>> configuration. >>> >>> This is on purpose. We believe that if a client is requesting a specifi= c >>> 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 pro= file >>> 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 C= A >>> 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 numbe= rs >>> 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 wou= ld >>> want it to be an exhortation against versioning, as it breaks the >>> longstanding contract of "trust the CA to make the best decision possib= le >>> 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. >>> >> --0000000000000f55300648e80c83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0We did this [adding an extra layer to the L= et's Encrypt CA chain] without making any changes to our advertised pro= files or=20 their documentation, and without any targeted outreach to subscribers.=20 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 applic= ations actually handle edge-cases reasonably well (like cert chains with le= ngths other than 3)? I'm shocked.

Ok, maybe pr= ofiles aren't as brittle as I'm afraid, and therefore there's n= o good reason to version them. Thanks for entertaining my idea!
=
On Mon, 12 Jan 2026 at 11:29, Aaron Gable <aaron@letsencrypt.org> wrote:
<= 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">
Ah, I und= erstand. Yeah, that's something that CAs have historically changed with= out any particular need to notify subscribers or update profiles, and I hop= e 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 on= e certificate longer than they used to be. We did this without making any c= hanges to our advertised profiles or their documentation, and without any t= argeted outreach to subscribers. So far we have not observed or heard repor= ts of any breakage.

I definitely don't want the exis= tence of profiles to mean that such changes in the future would be expected= to be more complex.

Aaron

On Sun, Jan 11, 20= 26 at 4:29=E2=80=AFPM Mike Ounsworth <ounsworth+ietf@gmail.com> wrote:
Hmm. ok.

PS I didn't "length of the vali= dation chain" as in "whether or not the CA servers the intermedia= te", 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 large= r 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&g= t; wrote:
Hi Mike,

Responding to pull-quotes inline below:

O= n Thu, Jan 8, 2026 at 4:36=E2=80=AFPM Mike Ounsworth <ounsworth+ietf@gmail.com&= gt; wrote:
I think there's an assump= tion here that the CA is free to evolve their offered profiles over time;

Yes, they are, and they always h= ave 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 pr= actices.
=C2=A0
But then, how much change is too much change th= at the CA really ought to declare a new profile and deprecate the old one?<= /div>

That's a very, very high ba= r. 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 a= ll clients which are explicitly requesting that profile, until their operat= ors notice and update their profile configuration.

This is on purpose. We believe that if a client is requesting a specific p= rofile, 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 profi= le `foo` and instead get an order with profile `bar` because the CA has dep= recated `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=C2=A0they risk breaking anyone r= equesting that specific version.

I think that any = mention of versioning (whether normative or merely a suggestion) within thi= s draft will lead both CAs and clients to believe that profiles are meant t= o 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 a= gainst versioning, as it breaks the longstanding contract of "trust th= e CA to make the best decision possible given the current regulatory enviro= nment".

Thanks,
Aaron
P.S.:
=C2=A0
if you changed the length of the CA ce= rt path,

Note that, in ACME, t= he length of the validation chain shouldn't be influenced by the profil= e; that's instead controlled post hoc via link rel=3Dalternate headers = on the certificate download.
--0000000000000f55300648e80c83--