Re: [Acme] Proposal: ACME Profiles

Matt Palmer <> Thu, 07 September 2023 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9CE2C151074 for <>; Thu, 7 Sep 2023 15:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ABQLU40_xV9h for <>; Thu, 7 Sep 2023 15:58:10 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D433AC14CF1A for <>; Thu, 7 Sep 2023 15:58:08 -0700 (PDT)
Received: from ( [IPv6:2001:44b8:510e:8600:a7da:55a4:3142:396b]) by (Postfix) with ESMTPSA id 2A9DC1F6039 for <>; Thu, 7 Sep 2023 22:58:05 +0000 (UTC)
Received: by (Postfix, from userid 1000) id CFF0E9FFC1; Fri, 8 Sep 2023 08:57:48 +1000 (AEST)
Date: Fri, 08 Sep 2023 08:57:48 +1000
From: Matt Palmer <>
Message-ID: <>
References: <> <AS8PR10MB59259C016DA74A0FD05EF3089EE4A@AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Acme] Proposal: ACME Profiles
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Sep 2023 22:58:11 -0000

On Thu, Sep 07, 2023 at 05:12:57PM +0100, Q Misell wrote:
> I agree with what Aaron says about the difficulty in validating that a
> complex request from the client meets whatever requirements the CA is
> adhering to. I do however think that a simple list of profiles isn't the
> most suitable.

Can you expand on why you feel that a set of profiles isn't sufficient? 
While the issue of combinatorial explosion has been raised as a theoretical
problem, I haven't seen anyone involved in operating a CA say "we have
mapped out the set of profiles we would need to support, and it is
unworkably large".

> Instead I propose that there is a list of profiles, and each
> profile has a small number of optional boolean flags (the name, and
> definition of these left to the CA).

While I agree this seems to nicely split the difference, I worry that it's
actually the worst of both worlds: CAs will still need to support a
potentially-unbounded set of profiles (for any variation that can't be
expressed reasonably as a set of boolean values) while also having the
"validating a complex request" issues.  It also makes it difficult to
delineate what should be a "flag", and what should be a separate profile, as
your example can be made to show:

> For example a CA could have an "rsa_intermediate" and "ecdsa_intermediate"
> profile, both with an "oscp_must_staple" flag. This would reduce the number
> of profiles enumerated, whilst also restricting how complex the request
> from the client can be.

I can totally imagine a CA starting off with a single profile, with no
options.  Then they start offering a ECDSA intermediate, and "for
compatibility reasons" decide to stick with the single profile and make
"ecdsa_intermediate" a default-false boolean flag (with false indicating
"use an RSA intermediate").  Then, some years down the road, PQC rolls out,
and "for compatibility reasons", the CA adds a new flag, "pqc_intermediate",
which is now mutually-exclusive with the "ecdsa_intermediate" flag, and
we're back into having to validate a whole set of flags.

One can partially mitigate this scenario by saying that all flags defined to
be associated with a profile must be specified in a request (ie "no default
values"), but that will most likely end up with profile proliferation, as
whenever a CA needs to add a flag to their profiles, they have to define new
profiles (and keep the old ones around, for compatibility).

For example, consider a CA that has "rsa_intermediate" and "ecdsa_intermediate"
profiles, but *doesn't* support OCSP must-staple.  These profiles have no
options.  Then, due to customer demand, they implement OCSP must-staple, and
want to make it optional.  However, they can't add an option flag to the
existing profiles (because that would break usage for all their existing
clients who don't specify a value for that flag), so they need to make
"rsa_intermediate_ocsp_must_staple" and
"ecdsa_intermediate_ocsp_must_staple" profiles, where ocsp_must_stable is a
flag, and migrate all users to that profile (and teach them to set the flag
if they want it).

Lather, rinse, repeat for all other optional features the CA introduces over

- Matt