Re: [Acme] Proposal: ACME Profiles

Q Misell <q@as207960.net> Thu, 07 September 2023 16:13 UTC

Return-Path: <q@as207960.net>
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 0B5DFC1522C4 for <acme@ietfa.amsl.com>; Thu, 7 Sep 2023 09:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=as207960.net
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 IYuf6v-g-p0Z for <acme@ietfa.amsl.com>; Thu, 7 Sep 2023 09:13:35 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [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 ietfa.amsl.com (Postfix) with ESMTPS id 5CCC0C1522C6 for <acme@ietf.org>; Thu, 7 Sep 2023 09:13:35 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-523100882f2so1529091a12.2 for <acme@ietf.org>; Thu, 07 Sep 2023 09:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=as207960.net; s=google; t=1694103213; x=1694708013; 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=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; d=1e100.net; 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: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com> <AS8PR10MB59259C016DA74A0FD05EF3089EE4A@AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <AS8PR10MB59259C016DA74A0FD05EF3089EE4A@AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM>
From: Q Misell <q@as207960.net>
Date: Thu, 07 Sep 2023 17:12:57 +0100
Message-ID: <CAMEWqGvK6T2v_1yco=-nmN603HjoZ5f+UPs-mdPw=g3YwDU8ug@mail.gmail.com>
To: "Buschart, Rufus" <rufus.buschart=40siemens.com@dmarc.ietf.org>
Cc: Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org>, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003d49ef0604c724fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/9eKAOd2UMmzBa0S5SjE5FLHvyNM>
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, 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.

Thoughts?
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
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/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,
respectively.


On Fri, 1 Sept 2023 at 07:41, Buschart, Rufus <rufus.buschart=
40siemens.com@dmarc.ietf.org> 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 <acme-bounces@ietf.org> im Auftrag von Aaron Gable <aaron=
> 40letsencrypt.org@dmarc.ietf.org>
> *Datum: *Donnerstag, 31. August 2023 um 00:21
> *An: *IETF ACME <acme@ietf.org>
> *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
> <https://mailarchive.ietf.org/arch/msg/acme/FEZYTUfhSeur-wKQI6H2xytSkvY/>
> is largely an exercise in profile selection. There’s also been significant
> discussion
> <https://community.letsencrypt.org/t/offer-a-new-endpoint-and-acme-spec-update-to-list-available-chains/203329>
> 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
>