Re: [Acme] Proposal: ACME Profiles

Ben Burkert <benburkert@anchor.dev> Tue, 19 September 2023 23:17 UTC

Return-Path: <benburkert@anchor.dev>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81A3C1519AC for <acme@ietfa.amsl.com>; Tue, 19 Sep 2023 16:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.706
X-Spam-Level:
X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=anchor.dev
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X64EqOV6y3JK for <acme@ietfa.amsl.com>; Tue, 19 Sep 2023 16:17:08 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 6BA6DC1519AD for <acme@ietf.org>; Tue, 19 Sep 2023 16:17:08 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2c00a32cbb1so3773271fa.1 for <acme@ietf.org>; Tue, 19 Sep 2023 16:17:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anchor.dev; s=google; t=1695165426; x=1695770226; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bpSkXzMqtvBOV3KemfQh99myz16/LGozxsIH+K1gApQ=; b=uN7quRtfClSnpUffVwiwxqA9i37J9Peavc3j/qNaF+VmJhMHt3gCpq93+mINerTMpp aG3TrlktrTdtEujKL2Q4hnPhN4F/pYV/cU0DqX4e1mswCEQSbfYXUnfor6IAdTmOn2fh QKHiTGRitlwqxuOmuGmMA1c4VutzK7o7APhgmGPCE6j1rBcdeN5UxH6Mz2pjm0FzLWEB wWuyF7oa+tJmSZ/KR9pb6m+DG3gAv8Qa/ix2I9quIEvCCqqO2tBIJRvno3C5aaQC1M/O LoGgIeNqRfiYfjCMTuIH8S3MyKt12mRhzpRRMt927ePA8owpe5OUa87NalkHwxLIXQnn AY3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695165426; x=1695770226; h=content-transfer-encoding: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=bpSkXzMqtvBOV3KemfQh99myz16/LGozxsIH+K1gApQ=; b=m1mGBiwbYm1BYAE7i5JUvdeX8xgydhdhNlt2agLJ7ri3avdlqTnF91PhF4vd68DLeN SzS0+1deQkU4QXbjMIQ3SHnqUp6qMYc2GNU47VcrPV6KRJRm6kFfGcGxxked14xTHbU6 pTVYRhwVyCafACZ+Y1SNQpmXFhd5igvsW1yq7jPTS/kCC8jXu8SuqThmOVzQbXozAFgi yjPtifloj60VT684SXW119+168of048CC5r57Dg9vOWI07YCktl/axlyYOL4+4DWdq4F f4nwG4VNswylU4K2ToUvvT8kjDfmU6pyLiOUBy7q1sUtUSTpW1jmL1pcOAZVGuQ2/qa6 Lj9Q==
X-Gm-Message-State: AOJu0Yz6eUz9eLYrkQDkBfi7zzahTP3XnBl8gvDytW2hlOp04bAEmv6G 71KOJxVm9GzYyEeb+pBdZmTigBUpPjTw83MQuCPd/nDsnCIlriseTns69w==
X-Google-Smtp-Source: AGHT+IFbfMLWB7maWGOfGnwq7r0e+6YCAgj6LMNGC6mJtiNsI4E+vrKbqd6yDqzlwLG7tPfT27YnaogwE3u5G6g9t1U=
X-Received: by 2002:a2e:8018:0:b0:2bd:1804:29ee with SMTP id j24-20020a2e8018000000b002bd180429eemr358928ljg.18.1695165426186; Tue, 19 Sep 2023 16:17:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com>
In-Reply-To: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com>
From: Ben Burkert <benburkert@anchor.dev>
Date: Tue, 19 Sep 2023 19:16:54 -0400
Message-ID: <CAOJjKpytkFr9_G6rh4rGFGKTAP-Kh9_a-n8bcXMMjoB07Sj75A@mail.gmail.com>
To: Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org>
Cc: IETF ACME <acme@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/OFNhd1i6bUrRx85qwinvn8I-780>
Subject: Re: [Acme] Proposal: ACME Profiles
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Sep 2023 23:17:12 -0000

Hello,

Apologies for chiming in late here; I'm with a startup that is just
coming out of stealth mode so I have been quietly following these
discussions. I bring this up because we build & operate ACME powered CAs
on behalf of users, and we've already introduced our own concept similar
to profiles. We focus entirely on the private CA market, but we have an
interest in seeing this concept standardized in a way that works well
for both the public & private ACME CAs.

The way we solve this is at the intermediate CA level, which we refer to
as a SubCA. Each SubCA is an intermediate CA that issues end entity
certs, and a template that sets a common set of properties of the end
entity certs that it issues. For example, when creating a SubCA you can
specify the expiry time (as a duration), key usage and other extensions,
and allowed DNS/IP naming rules (which can turn into name constraints on
the intermediate).

This works for us because creating new intermediate CA is easy to do in
our model. Also, we require EAB tokens on all ACME requests, and we
scope those tokens to specific SubCAs. This means clients effectively
pick a profile by picking a SubCA when creating EAB tokens.

So we have something similar that works well for us today. But even so,
there are a whole bunch of business reasons I could go into about why we
would like to see a standardized profile concept. A lot of the reasons
probably aren't relevant to public CAs though, so I'll stick with my
thoughts related to public CAs.

The "combinatorial explosion" of profiles seems like a bigger issue for
client authors and end users than for the CAs. If i'm trying to setup
multi-CA resiliency, today I only have to add some fallback directory
URLs and duplicate the manual or automated work to fulfill challenges.
But with profiles, does that mean I have to go to each CA and figure out
the right set of profiles? I don't like the added friction of having to
manually perform this intersection of policies.

I think Rufus' idea about allowing profiles to point to other CAs could
address some of the "combinatorial explosion", but it could also
introduce centralization.  What happens when a CA hosting a popular
profile disappears? Or makes changes to the profile?

>From an end user's perspective, picking a profile is a lot like
requesting a set of capabilities. Maybe there is a way to encode these
capabilities in a logic programming language. Something along the lines
of Biscuits[1], which has the nice properties of immutability and
attenuation. Making the profile object both resource and content
addressable could avoid "combinatorial explosion" without
centralization. And using machine readable logic language programs as
the standard format for profile objects could allow for "flags" without
some of the drawbacks that Matt brought up.

[1] https://www.biscuitsec.org/

Cheers,
-Ben

On Wed, Aug 30, 2023 at 6:21 PM Aaron Gable
<aaron=40letsencrypt.org@dmarc.ietf.org> wrote:
>
> 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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme