Re: [Acme] Proposal: ACME Profiles

Ilari Liusvaara <> Thu, 31 August 2023 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60415C1519A5 for <>; Thu, 31 Aug 2023 02:09:05 -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 Un5dG1m_3Upj for <>; Thu, 31 Aug 2023 02:09:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C657C14CF12 for <>; Thu, 31 Aug 2023 02:09:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1E4E67A9D for <>; Thu, 31 Aug 2023 12:09:00 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 93ayLuKBLxgV for <>; Thu, 31 Aug 2023 12:09:00 +0300 (EEST)
Received: from LK-Perkele-VII2 ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A006C2309 for <>; Thu, 31 Aug 2023 12:08:59 +0300 (EEST)
Date: Thu, 31 Aug 2023 12:08:59 +0300
From: Ilari Liusvaara <>
Message-ID: <ZPBYqyhNXPm/eBmX@LK-Perkele-VII2.locald>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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, 31 Aug 2023 09:09:05 -0000

On Wed, Aug 30, 2023 at 03:21:30PM -0700, Aaron Gable wrote:
> I believe it is time for us to seriously consider the topic of “profiles”.
> For the purposes of this discussion, a profile is a collection of
> characteristics which affect the contents of the final certificate issued
> by an ACME CA. For example, two different profiles might cause certificates
> to have different validity periods (e.g. 10 days vs 90 days), or different
> EKUs (e.g. ServerAuth and ClientAuth vs ServerAuth only), or even be issued
> from different intermediates.
> Therefore I believe it is time for ACME to grow support for some form of
> profile selection. As argued above, I don’t think that the Finalize CSR is
> a good format for this, so something will need to be added to the ACME
> protocol itself. I propose the following very simple change:
> 1. The directory’s meta object gains a new “profiles” sub-object, whose
> keys are short profile name strings (such as “default” or “rsa 2023”) and
> whose values are human-readable descriptions of those profiles (such as
> “our standard profile, but with a validity period of only 10 days” or a URL
> pointing at more verbose documentation).

I think there are cases, where the list of profiles in directory can
not be exhaustive.

1) There may be a number of orthogonal properties, causing the total
   number of possible profiles be very large (the CA-side code is
   NOT complex).
2) There may be profiles that are either not allowed (e.g., EV only),
   or do not make sense (e.g., compatibility hacks) for most

What is needed to support these cases is for ACME client to allow
configuring profile without any client-side checks.

Or more extreme way would be to just have the "profiles" be a string
pointing to CA documentation. That would preclude ACME clients doing
any validity checks.

> 2. The Order object gains a new “profile” field, which can be set in
> NewOrder requests, or will be set automatically by the Server according to
> its own server policy if no recognized profile is requested.
I think the server should reject the order creation if "profile" field
is present, but contains some unknown or disallowed value. The default
only appiles if there is no "profile" specified.

Then there is edge case of where key types are restricted by profile
and client tries to do something disallowed (e.g., DC certificate with
RSA key). However, bad key errors already happen at finalize time
(and autofinalize is a separate topic).

> In some of the discussions mentioned above, much more complex systems have
> been proposed. These systems would establish a format for a CA to advertise
> every individual adjustable field and all values each field can take.
> Clients would then have the ability to both tightly customize the
> certificate they request, and to compare the offerings of multiple CAs to
> select the one that most closely matches their operator’s preferences.
> However, I believe that such a complex system would ultimately be largely a
> failure, as most operators would not have complex desires to express, most
> clients would not implement complex configuration mechanisms to allow
> operators to do so, most CAs would not advertise directly-comparable sets
> of attributes, and if we attempted to standardize the set of advertisable
> attributes we would inevitably fail to anticipate actual needs.

Yeah, such thing would be a bad idea, as the complexity is at best
extreme, and likely unsurmountable.

Best to have admin manually configure the profile (since CAs already
need manual configuration).

> Additionally, we’ve seen from TLS algorithm negotiation itself that it is
> better to offer a few well-studied options than to allow (poorly configured
> or misinformed) clients to pick-and-choose from a wide variety of options.

I think it is the exact opposite.

The reason why TLS 1.3 changed the algorithm negotiation to be more
pick-and-choose is because the TLS 1.2 way would have been completely

And having implemented both (with very little confidence on correctness
of TLS 1.2 one), the TLS 1.3 one is much simpler to implement.