Re: [Acme] Proposal: ACME Profiles

Ilari Liusvaara <> Thu, 31 August 2023 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 594CEC136147 for <>; Thu, 31 Aug 2023 09:06:21 -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 IYp4rVIsq1hF for <>; Thu, 31 Aug 2023 09:06:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05C83C136133 for <>; Thu, 31 Aug 2023 09:06:15 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEB4143D2B for <>; Thu, 31 Aug 2023 19:06:12 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id uwMX3ErsKcoW for <>; Thu, 31 Aug 2023 19:06:12 +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 A0F3F7A for <>; Thu, 31 Aug 2023 19:06:11 +0300 (EEST)
Date: Thu, 31 Aug 2023 19:06:11 +0300
From: Ilari Liusvaara <>
Message-ID: <ZPC6c8tfJLOBlZLO@LK-Perkele-VII2.locald>
References: <> <ZPBYqyhNXPm/eBmX@LK-Perkele-VII2.locald> <>
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 16:06:21 -0000

On Thu, Aug 31, 2023 at 08:22:27AM -0700, Aaron Gable wrote:
> On Thu, Aug 31, 2023 at 2:09 AM Ilari Liusvaara <>
> wrote:
> > 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).
> >
> I'm not super concerned with combinatorial explosions of profiles. A CA
> could offer many profiles that differ in small ways, but
> a) It would be their responsibility to ensure that all profiles abide by
> their PKI's requirements; and
> b) It would be their responsibility to clearly communicate what each of
> those profiles means to their subscribers.
> Honestly, doing both of those is difficult. 

I don't think it is difficult to end up with more profiles than one
wants to explicitly list, even if one is very careful that all the
profiles meet the PKI requirements and that everything is clearly

> > 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.
> >
> I considered this, because as you say it certainly makes sense to simply
> reject orders which request a non-existent profile. However, I think that
> it breaks down in practice: we know that there will be clients which are
> set up once, configured with a profile name once, and then never updated
> ever again. The CA needs the ability to evolve and deprecate profiles
> without causing those clients to permanently fail. Therefore I think it is
> best that the ACME server SHOULD reject such requests but MAY ignore the
> unrecognized profile and select a default instead, or something like that.

Or guess something that is close. E.g., If profile specifies no-longer-
allowed issuer, revert that to default, but still honor the rest.

Then this also interacts with having list of profiles in directory (as
oppsoed to just linking to documentation). What will the ACME client do
if profile it is configured to use disappears from the directory? To me
it seems like there are only two choices:

- Proceed anyway, rendering having any sort of programmatic list moot.
- Fail, halting renewals until configuration is fixed.