Re: [Acme] Proposal: ACME Profiles

Matthew McPherrin <mattm@letsencrypt.org> Wed, 20 September 2023 00:33 UTC

Return-Path: <mattm@letsencrypt.org>
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 36266C14F748 for <acme@ietfa.amsl.com>; Tue, 19 Sep 2023 17:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
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 bhpB4da8GCiw for <acme@ietfa.amsl.com>; Tue, 19 Sep 2023 17:33:35 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 CFC8FC15106B for <acme@ietf.org>; Tue, 19 Sep 2023 17:33:35 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-401d80f4ef8so68716205e9.1 for <acme@ietf.org>; Tue, 19 Sep 2023 17:33:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; t=1695170014; x=1695774814; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2xexsQlNNCUzZt0zR8ACht5mvdGD/MvCfs40Dcp5QIg=; b=DieO6DQK/vP6BorA8LeScZ2gpx89JL4IQ/AMGSWB8WjBbytj+qgisERht4nwbClCZf rK8N8KksDEgSoDBhDEUYNk2x2UGYRg8X53667ys0ZEzvHAi077qt30Wbb3jo2CSFTrlA sX9jGGj8F6b4m7kCjlJgnDGjxPL8ElKKgdBDY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695170014; x=1695774814; 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=2xexsQlNNCUzZt0zR8ACht5mvdGD/MvCfs40Dcp5QIg=; b=NIqq5pLlBMVZodf6ej/pqXWTC+WIjk2E3McKAP2YJv6GHEt7DvFfYqQ0BQo40OPEmG pT6MpamcVU0wBw8N2Q2wA+uI8epyD4swV3JkHSQWhF5Jvg6SGh/IBArwHK6yoZ98U7mk axKKu9KCTAOT5EnLcxNRJUClzo2IUGGlkeWJWCZ/cXrxSGUaLN85lD7SS8B0N5c3rNVl WwZvBw4gCcPyScrQau+ARNnzT736dKxWZFfhQERbc57zXQP2FfM5h82M6MONPQglbJz6 JBQTD4TjQXBihPFxKRQwSRUWEUroJ2IFOtIooSx+/GDY+Dv0afR8ESH3l1RLg0G0WCw8 9WLA==
X-Gm-Message-State: AOJu0YyuBjy+ACLFJPDVyAEb5d1afASSsNo2l13vciofVepr6STYVdy6 IfTiRhPLDVTGzkFw+53vOYW0wKbaHVqwULJEXkpCwA==
X-Google-Smtp-Source: AGHT+IGmyOqbGv5O9Xg2lZbSxXr3pjRWUo83g6AePWvZX0HxzKlcNxLbHgAxNhE7l/5O6kxH7HnZSiWQFWrZbDd/1QM=
X-Received: by 2002:a5d:4209:0:b0:319:755c:3c1e with SMTP id n9-20020a5d4209000000b00319755c3c1emr916301wrq.11.1695170013614; Tue, 19 Sep 2023 17:33:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com> <CAOJjKpytkFr9_G6rh4rGFGKTAP-Kh9_a-n8bcXMMjoB07Sj75A@mail.gmail.com>
In-Reply-To: <CAOJjKpytkFr9_G6rh4rGFGKTAP-Kh9_a-n8bcXMMjoB07Sj75A@mail.gmail.com>
From: Matthew McPherrin <mattm@letsencrypt.org>
Date: Tue, 19 Sep 2023 20:32:57 -0400
Message-ID: <CAKh5S0Y67MUDLvpPiBbg4Yuf-BSqug3BJjNaiPVbW=2riCwDpA@mail.gmail.com>
To: Ben Burkert <benburkert@anchor.dev>
Cc: Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org>, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007eec8d0605bf86cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/o2XpMZDYhra71NJncxIF6hfkGWE>
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: Wed, 20 Sep 2023 00:33:40 -0000

My personal opinion here is that adding a profile field to the Order object
is likely to hamper client adoption, and as Ben just said, makes
configuration more difficult if CAs don't have matching profiles.

An alternative approach that I believe has been used is adding URL
parameters to the directory URL, as Aaron mentioned in his initial email.

The returned URLs in the directory can reflect those parameters, eg, on the
newOrder endpoint, as required.

The directory endpoint should only do so if the parameters are known.

The directory url can contain metadata to advertise what parameters are
available.

So potentially an interactive client can display a UI of options to a user.

Automated use-cases or older ACME clients would simply configure the
directory URL as desired, with the query parameters included.

I believe that adding parameters to directory URLs requires no additional
standardization work, and Let's Encrypt can add a profile parameter
immediately.

What we may want to standardize is a method for advertising what query
parameters are available, as well as a mechanism for returning warnings or
errors about invalid or deprecated flags in the directory.

Thanks, Matthew

On Tue, Sep 19, 2023 at 7:17 PM Ben Burkert <benburkert@anchor.dev> wrote:

> 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
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>