Re: [Acme] Proposal: ACME Profiles

Q Misell <> Thu, 07 September 2023 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B5DFC1522C4 for <>; Thu, 7 Sep 2023 09:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IYuf6v-g-p0Z for <>; Thu, 7 Sep 2023 09:13:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 5CCC0C1522C6 for <>; Thu, 7 Sep 2023 09:13:35 -0700 (PDT)
Received: by with SMTP id 4fb4d7f45d1cf-523100882f2so1529091a12.2 for <>; Thu, 07 Sep 2023 09:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1694103213; x=1694708013;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yyEZCcjJbMG0XdFp38QD1eFzNSjdI8fBYSuueboRroc=; b=RthawlRbBZ6PlfscHnJuHR68xrht/mNIa4O/hO2nm9lL7W9p00lBNR9lsVgcL8mSEx nBHe6J1CseVi4YSK7yruZ/qDRSuukJbr5e/XZSsn6Dxl5QodXlnRCPPuETDRY7FPCEjj tYeYkM0uMVgel1B/mB7I4wjzTxWcQeYjMXuJsediJrE83Y4n9D56l34esncNBcBiDInY nWTVzhnJL+4Ku+vwBfYgc4geg11pCppDpA2KmJhjNiXbr3wlgmXZGTTaAJMFbfpnCUOp Dh/cJP05zS1O+06RzOiyp6cDG8A2q4M3JzMMQLQXlG4Lk8BgIqJBfuVwFwJtFbWyRMB7 oa+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1694103213; x=1694708013; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yyEZCcjJbMG0XdFp38QD1eFzNSjdI8fBYSuueboRroc=; b=RmVq0bcsiVBvN6j2nruN2X+4cgjk7en/3LmgXypwp5rHXTiNdwh0mA3J5auxEqZ0Ki L71FtFfOTfN3Fjg8JS1k+tktlhQjDDhvw6JLXmqb3Rmh+Swl9zggCTKY1Yy52aoGDzAi oQQ8nTo3TEi2rCUcy6RUiZPsjKQIgHtuev1asSgX/apKPDOg1/Uva/5XvDJHKOTqF018 YNE7dWhBPwlB6mgbB9RqNtyoHTfv4nT4xaKsgzscyT09Kq9gc+F0L9EWNMKAadSu8r9w /UUT0lHQi+wWmv2aFM51RHBZVKy4vyTdiTU8GDdDd4YyrOHVsz+uo+OxFQ6k9D4Up0wM +xEg==
X-Gm-Message-State: AOJu0YyU+xUXHSTCr/RMZQZRpPL+y+C5PJeZ8lq/i0S+EZVy+mxkVtbR ZW8I+BY1d/MHEuI5fA7E4G2wM1E4fiiTZxvM7lmXvzBd0SHmoNWfhrc=
X-Google-Smtp-Source: AGHT+IGYg5RWWQLCn13uYVNfMoiZ/kQrjVqL5HF0hU83M/HlInME5/y8nVtty+y3rmrR6mMucEs3olnWZJN27huCngA=
X-Received: by 2002:a05:6402:1844:b0:522:2711:863 with SMTP id v4-20020a056402184400b0052227110863mr5236565edy.1.1694103213255; Thu, 07 Sep 2023 09:13:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <AS8PR10MB59259C016DA74A0FD05EF3089EE4A@AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <AS8PR10MB59259C016DA74A0FD05EF3089EE4A@AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM>
From: Q Misell <>
Date: Thu, 07 Sep 2023 17:12:57 +0100
Message-ID: <>
To: "Buschart, Rufus" <>
Cc: Aaron Gable <>, IETF ACME <>
Content-Type: multipart/alternative; boundary="0000000000003d49ef0604c724fe"
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 16:13:40 -0000

Hi all,

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

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.

A CA would, of course, be free to list profiles and define no flags if it
thinks that's the best approach for it.

Q Misell

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,

On Fri, 1 Sept 2023 at 07:41, Buschart, Rufus <rufus.buschart=> wrote:

> Hi all!
> I’d like to add two ideas:
>    1. The profile entries in the new Profiles object should be capable to
>    link to ACME servers on a different URL. By this, one could maintain a
>    central list of ACME servers operated by various CAs within the ACME
>    protocol standards.
>    2. We should enforce, that every profile object must contain a URL to
>    the CP/CPS of the respective CA (or to the CCADB entry).
> Thank you very much for this proposal to extend ACME!
> /Rufus
> *Von: *Acme <> im Auftrag von Aaron Gable <aaron=
> *Datum: *Donnerstag, 31. August 2023 um 00:21
> *An: *IETF ACME <>
> *Betreff: *[Acme] Proposal: ACME Profiles
> Hi ACME community,
> 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.
> Historically, profile selection within ACME has been somewhat ad-hoc:
> ·         The NewOrder request contains “notBefore” and “notAfter” fields
> which allow clients to request certain validity periods, but other aspects
> of the certificate cannot be customized and support for these fields is
> minimal. Let’s Encrypt rejects requests which contain these fields, and
> Google Trust Services recommends that they be omitted, because clients are
> likely to request values which the server cannot respect (e.g. notBefore
> dates unacceptably far in the past, violating BRs requirements regarding
> backdating).
> ·         The CSR contained in the Finalize request message can carry
> additional information, but copying values directly from CSRs to final
> certificates has been the root cause of many CA incidents, so great care
> must be taken. Let’s Encrypt does use the presence of the “ocspMustStaple”
> extension in the CSR to cause the inclusion of the same extension in the
> final certificate, but this is the only attribute we extract from the CSR
> and frankly we’d rather not even do that much.
> ·         I’m aware of one CA which uses url query parameters to control
> aspects of the certificate profile. The client specifies query parameters
> in its configured directory URL, the directory object reflects those same
> parameters back in its newOrder URL, and then the newOrder endpoint
> processes those query parameters to affect the certificate profile.
> Recently there has been an uptick in interest in profile selection in
> ACME. For example, the recent PQC negotiation thread
> <>
> is largely an exercise in profile selection. There’s also been significant
> discussion
> <>
> on the Let’s Encrypt community forum, largely prompted by the desire for
> more control in intermediate selection. Let’s Encrypt itself is interested
> in formalizing profile selection so that we can make backwards-incompatible
> changes to our current issuance profile without breaking clients. And of
> course I’ve spoken with other CAs who are interested in the same.
> 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).
> 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.
> 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.
> 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.
> Therefore I believe that this simple approach is best. It will be easy for
> both clients and servers to adopt. It will allow CAs to offer well-vetted
> profiles for clients who need specific attributes. And it will allow CAs to
> preview upcoming profile changes to clients that want to opt in and to
> gracefully evolve profiles over time.
> We are already working on a draft which formalizes the proposal above, and
> hope to implement a version of this in the near future to facilitate the
> evolution of our own issuance profile. We’d love to hear all of your
> thoughts before we embark down this path!
> Thanks,
> Aaron
> _______________________________________________
> Acme mailing list