Re: [Acme] Proposal: ACME Profiles

Aaron Gable <aaron@letsencrypt.org> Thu, 12 October 2023 21:11 UTC

Return-Path: <aaron@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 E5F9AC14CE42 for <acme@ietfa.amsl.com>; Thu, 12 Oct 2023 14:11:12 -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_DNSWL_NONE=-0.0001, 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=ham 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 0T_bDbtwZaDJ for <acme@ietfa.amsl.com>; Thu, 12 Oct 2023 14:11:08 -0700 (PDT)
Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (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 56EC4C14CE30 for <acme@ietf.org>; Thu, 12 Oct 2023 14:11:08 -0700 (PDT)
Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1e993765c1bso818416fac.3 for <acme@ietf.org>; Thu, 12 Oct 2023 14:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; t=1697145067; x=1697749867; 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=mI1aqrqEsbSYxQzf2TaFnR3q8hAnEyhn08N6rCZaADk=; b=YWT+rqQxAdbjGt3bm4fM/DyYs8bypvsilHWx94A3/Oslyg0n8WwoLjpWRK3azrZpKs A9gRKFe1AuDPVF8Sdeyx917OAn2S7p+609RRE0+tBMRHQqSAQbgyshZFA364G+r6wOwR YeJNxQup14hx/xnQJ5QoN3qSnnU5Pq+7IkpVM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697145067; x=1697749867; 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=mI1aqrqEsbSYxQzf2TaFnR3q8hAnEyhn08N6rCZaADk=; b=ZD4PYG5v2A0kGGQT54HTPdWN3HRqbeTYUC1EcbbsO54JTmKYBVU5J5K7USGq0bQ3Xs jzR0p9fERS6jVVjECKe9pP8SNqOT4/yT7GbDLXfvxLsFlIF4vljOHyL/b+5FFPYXJ4BU dX5maPyQDU9ltM2/wU1HIO1KDUH7i6KqMnK+lihRoDebiXJt+BrkFtqu68So/7mmNPrs kkJ6X6I2YLz7ODEKL1IcspCsmCO1GLBbqJpUYN35TMEgLTtKHF3pHSEUiITPY90UtlvU F7AyPK1PcwqSTw3rZDuJQtn0GBxgM0/W28W4usRm+UKy9ERmfkuKdmDygIO8TTw+hWAw 69sg==
X-Gm-Message-State: AOJu0YzyxoBCT4TGjM60OHhFdMgXE32wG+61CzqkBzb1DPN93QUFHq6y z4eKwz2qlc8yYO71tBTjW/Xqdf/ux8oKkeWcsYTK/dNzjaOpJpoYVXq5rg==
X-Google-Smtp-Source: AGHT+IG7EFQRGNUQbMDlpk4HuapstYNYxIY+HW2HrT7FCEsVqpOjMgdmcQIugxF/ZHjK/0Jxis/tE98ehAl52+GeG4Q=
X-Received: by 2002:a05:6870:64a7:b0:1d1:40a6:e82d with SMTP id cz39-20020a05687064a700b001d140a6e82dmr28591002oab.59.1697145067433; Thu, 12 Oct 2023 14:11:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com> <CAOJjKpytkFr9_G6rh4rGFGKTAP-Kh9_a-n8bcXMMjoB07Sj75A@mail.gmail.com> <CAKh5S0Y67MUDLvpPiBbg4Yuf-BSqug3BJjNaiPVbW=2riCwDpA@mail.gmail.com> <CAGgd1OfROHe89h9tF7aOXZz7=ifmmEWZsQeAtk+xeU0JW58hXQ@mail.gmail.com>
In-Reply-To: <CAGgd1OfROHe89h9tF7aOXZz7=ifmmEWZsQeAtk+xeU0JW58hXQ@mail.gmail.com>
From: Aaron Gable <aaron@letsencrypt.org>
Date: Thu, 12 Oct 2023 14:10:56 -0700
Message-ID: <CAEmnErdN2Ha7U1fbWc=UP_TX70BhqZsERL-FNnqbcf0ygG664A@mail.gmail.com>
To: Deb Cooley <debcooley1@gmail.com>, Ben Burkert <benburkert@anchor.dev>
Cc: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e08ca906078b6047"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/BkR34MkTgbN72hFjUOM6-mtPu0M>
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: Thu, 12 Oct 2023 21:11:13 -0000

Thanks for the continued discussion, all! Replies to multiple emails inline.

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

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


 Tying profiles to intermediates is interesting, but difficult in the
public WebPKI context, where generating new intermediates means accessing
the offline Root HSM. That would make creating new profiles significantly
more difficult.

Also, relying on EAB for profile selection is suboptimal for CAs that have
never needed EAB, like Let's Encrypt.

On Mon, Oct 9, 2023 at 3:10 AM Deb Cooley <debcooley1@gmail.com> wrote:

> When a request is made, as long as the CSR matches the options we have
> given them in the profile, the cert is issued. I think this old school
> method should scale to ACME without too much trouble.
>

>From what Let's Encrypt saw when launching, relying on CSRs to determine
profiles was deeply fraught and error prone. This is why LE ignores
everything in the CSR except for 1) the names (as mandated by RFC 8555), 2)
the public key, and 3) the ocspMustStaple extension. As a simple example,
it's a very common mistake for an ACME client to produce a CSR with a
validity period 1 second greater than intended (because the validity period
is inclusive of the notAfter timestamp), which would then not match the
profile and be rejected. Personally, I'd rather move in the direction of
removing CSRs from the ACME protocol altogether, than enshrining even more
profile selection within them.

But even more to the point, this doesn't describe how the client selects a
profile from amongst those advertised. Are you suggesting a combination of
the approach I described (a profile name in the newOrder request) and CSRs
to fine-tune options within that profile?

On Tue, Sep 19, 2023 at 5:33 PM Matthew McPherrin <mattm=
40letsencrypt.org@dmarc.ietf.org> wrote:

> 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.
>
> I believe that adding parameters to directory URLs requires no additional
> standardization work, and Let's Encrypt can add a profile parameter
> immediately.
>

Let's Encrypt is now considering going in this direction. Given that it
requires zero client development, no standardization, and has been
effectively used by at least one other CA, the "directory URL query
parameters" approach seems very tempting. I personally would still like to
include some sort of profile selection in ACME itself, but maybe this work
will be rolled into my larger thoughts for an ACME-bis that takes into
account some of the things we've learned over the last eight years.

Aaron