Re: [Acme] Proposal: ACME Profiles

"Buschart, Rufus" <rufus.buschart@siemens.com> Fri, 01 September 2023 06:41 UTC

Return-Path: <rufus.buschart@siemens.com>
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 E869FC13181B for <acme@ietfa.amsl.com>; Thu, 31 Aug 2023 23:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-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_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (2048-bit key) header.d=siemens.com
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 AGBc8w2ZK34C for <acme@ietfa.amsl.com>; Thu, 31 Aug 2023 23:41:51 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2056.outbound.protection.outlook.com [40.107.22.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8268C0DC7D9 for <acme@ietf.org>; Thu, 31 Aug 2023 23:41:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=idK9aG5ItCSMReNUNTHqBdM4Mrj8dPQXOwtlRxtHtVHLBgxcp/6G8XuME9s9dXilS0UZew/+wQUB4zn1abiy1dEAz/LkrSpJjkepov3qr3hSYzGX+s6fnfo3LEqPDv8U4zqkTt9Ap0Yosz1dI/G3bCAl7xEXrEqfgR5HlvxIzJSEdBCM8kNTWkNb1rmfPeoR1XeLKO9QsGyhLVvbhBY1hk5UHyEIBbhPW1f5F6GdAEN6y40tnUXdSIVluzkux2qVnChlmxpbGhcuTyKb6OPEc4hdhFyjI3705sHbu+7fIulkIYI32lGuwfNxpYPEsnyk84A8BVNNOr8+QCmTOoD4ug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YayL9ED0vxmUg6Cb6+FmAAFO/4Ogh0kOzq432J15+Ss=; b=Ye7jThs9hha31jEdbCTRMP5cZJw2ylNSwkE7DE67uSgfIRU3jUcItMdfbgXaef7w4G7FulOh6YCAkDuRxDfrddCct17CWrnr0aP43pJSHdh/mPa2uRkM3dP7F3yKQ4K7zoYs5C6PTZsqjNhgkZ3rmuIIr8dCaI2qE0/jdlNENl3IILo1V9sns9CMMjKVfNTniPUgjA8uk526s4/FYVqrv0EvuFA51z1g8EY8iNS6JoYsgGKF8qUywvgGzIDNdltCrMRZbQHZ7e1LxJN6ZTedIF/UWVVvj2rG2BvHV3ci47JWdPVksH7kgWmxNdNCJpdJpOr7Ct5MiNX+3Pa/71Xxew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YayL9ED0vxmUg6Cb6+FmAAFO/4Ogh0kOzq432J15+Ss=; b=CGuunlQlPsf77e1dLWN9Jjo+4GtrKLOcX3fgnV9WcT1apU4lkwwpgJvBdYUTkK+KfuUcA0WKuObDoI2RzqqfnO05+L9yFSqCxdM6nQeiItClpxb/FkigIBcGPLZPdRTIEApU6qWEDm8Mp5GhGXDBA9OdTWaC43U23+QJgjytIKAOenqEd1j7ig+aGDeeuDgaJaHw4z0XvyuvbexrylIP1v23PMBgw7oc7g2PTu6jP+prTPNYcwH17ynz9RTIiBbwEZqSJ+FaW74ygBuFK03rEtUWbAOxFGyPDSfjw3hIJ3mH3skGlSvfHe+R2K7LyBC7iRtAKwAE5PjC1iw6FG3ezg==
Received: from AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:52c::17) by DU0PR10MB5334.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:34d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6745.20; Fri, 1 Sep 2023 06:41:47 +0000
Received: from AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM ([fe80::29d4:fe68:bfe0:2567]) by AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM ([fe80::29d4:fe68:bfe0:2567%7]) with mapi id 15.20.6745.021; Fri, 1 Sep 2023 06:41:47 +0000
From: "Buschart, Rufus" <rufus.buschart@siemens.com>
To: Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org>, IETF ACME <acme@ietf.org>
Thread-Topic: [Acme] Proposal: ACME Profiles
Thread-Index: AQHZ25BkuTiAr0dTQEKj/fRDzVKMk7AFhHB9
Date: Fri, 01 Sep 2023 06:41:47 +0000
Message-ID: <AS8PR10MB59259C016DA74A0FD05EF3089EE4A@AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM>
References: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com>
In-Reply-To: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com>
Accept-Language: de-DE, en-US, en-GB
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=True; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2023-09-01T06:30:21.8705220Z; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=0; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR10MB5925:EE_|DU0PR10MB5334:EE_
x-ms-office365-filtering-correlation-id: 1cfce0d0-ef4b-443c-7a72-08dbaab683f3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vaQzhOYlm0C2RQLgInuea5txjl/QkcfXVtRWAdESgYiDMjlrANExZlDd+1VJ98fzlymmOYyISmsUYV0DD5ZLe6QYYWQyjDimPQh0JPNoXAJb9HeAJvNI+i2znUN9oFa8oFeNB8dBDUcXQ4AiLigKcrGl5XUGnGSJv3wFup3lJGX69eWLKKwdRJA+NPFPSr1rzxtzr6E+DRKHrCd22yBYjkGSiydEuvBsnGqzJt/DWgAp5NUuzIbuqkw6LGBCM0T38rU2o5WktuAqJgehEOy6uDv2IAws9/42868NTHZNTG9C0VwGRfDF4XEjE6O6EApmfj7+dJccP+bGNo2ZlHhbIp53tUvhx5sLLk9kfaOvV4oBspwBVb4UFouQ1v2jP+WGINYxXoUq3iE++impEi1ZEzJLiqrnNS7KWkPos8UEYXFKc2H4wA+IaTblyFfAtnwr+gEuO62OAsELy31flhW0chArQyR+JIOPqwsgL6dSdC0WJrNEXL63bba9a5nxh84Q6nHjPP9XD9qJ/b3e/DeUJYej7n4MhrZ0q/4eTqEmhlU7Jq3PgOORm1QYeao9HemmSAHJITBza6i9pw0mEyGXLzjUq8KvXqTO2JA9w+qBskA=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(376002)(136003)(396003)(366004)(346002)(451199024)(186009)(1800799009)(8936002)(41300700001)(83380400001)(55016003)(8676002)(66476007)(478600001)(71200400001)(66446008)(76116006)(66946007)(64756008)(110136005)(66556008)(316002)(7696005)(6506007)(26005)(9686003)(2906002)(38070700005)(38100700002)(52536014)(82960400001)(122000001)(86362001)(166002)(5660300002)(33656002)(66899024); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ddYvuTBkKRh3AU8ZCx6Q8buwCz9FFreYFy1IHcCNNiyhU/FGfKn2r+gd1uEoEQIMWEaQWuoT/hJ2gC3aLQeQzU7N8hm12XMFojC+d+fmoNqFswgMedgP/5SousdOJtJuQUlM5pfYn+dTG3Rz1OtmqphOgiq4qO3H6nAyDuCvdtVGpBq/I/0nVIXMvvD6B1dx4JKQhZ608Z2ePZplJNlwXl+OMYGkZk0ckxHDVNfy5VT/QTxy+YIFXZPwCMuPD/L2ZhF6dxlhsmewnu0bDQ9xDmcbwULWZkbFlQVullP1GCvj+GI+20YTqd4VWomvsQHIei8V8/cJass2b46x+Vo/oMmJ3m/0Yy9gTeCcjel2ZtvOx7MGQSCRCMK6dAxNI01H2hb+Hie6OMb7+ij0J1qtVwnql9sv1hA7g5WCdk0tuNYuQ1QlJ+hnOXBdW4rFryl1LuwXKnmdSduNrKt6a0IVfsdxud5W5eq17ZMizRQnobczYMckUPUKvlGxC7U0pyRay3oFKoHIM9pbYxt6jUGwKE06t4oKhTZNr+A9gEsdlbbgp9vQaNi4cHYnPh+6i59LqFt7wf4J3rtvFds1z5CYZb6PBp6752c7QKQ5EivKoMn3agOad1abmVfIKej/FGvAANB7c6n/pU3N5slRGjwLqryKcHkxhxCGCzxPPVm4GZcb1yPCDU/CeiL1udgWDCVtUwjCeWCSuPz927mabIXuEBP7Q9adI5KOfj4p095ifCqzTkxgtMm3v1kv2/lJjx3eooKR3hecehDc5XsaM1FlGlb6F/oFm0nbZVchXVUa2+GYaGZi3iS5OSyL/mA4CltjyaoT5d+bwiPVXAqNCghHA30UV4jJ3ds/939EN/SyL0dLy86wNEGjIq1NPyjfu6LWJRk3Z1x6Gomoo/CpXGegKzhz9jOHr63S59FvulLRwP91yBD0XD3sq98Tev2dMM2PKnq/caPM7Gys3rKCuZHRyRtxdXfXRNPernDLxjUPxQQSgVxbvDU0Rqkp8BsccOax2/ScsP6lXLVOQFcDZ7mdvkdyojC9j1O7aPM5Lv3aruUa9IQiL8dcg2M+/AsxmuDCpY/r+9Pc29ujJiSUL0GXvx45q2EvvY/X78P4qs4LHiSu+1L4Zxo828poYc5jYXvU1hg+J5Ic+Ockzg4QeGljgYIbn/Z+sRo5z8OIA3/SGrMwzDKW7PYN1g0pIjfHcBXaBSRY7QgFitXkqC4liMfp38AxSi2yuT+FAj84RssnCH0t301CmWDJWLDrLITVHG04eW37jZ+LK/jp2kY5/DCpHBqlHEcK1GDwno/I4rMbNMMqHojAUoDbFQk/kCp9JUWMhi9RnbA2dV+A8bImA6GtZ5Y3PP25yVq/76xAtV5V40PCD20rd8R9Jt/chem1itWjxEA2hMZNdku8f/nF+X8ZCMJUVdxRbK8NzwrFGCMwVdXSPcoDao148gEjr8g8t56XRVZSX5IWGGy2pWtmPwfrqvC9CGwMa6ilyLYdOHn5rBtgkTWYsj4qrIMGi8RprfseUHm5cvDiRyVLX9VrmAbsW5QTTfqw5IxToexuf2K8C+y4+JPBoWIMHNLYwqmPy4WPOysHD2Md5N7wH2vIeZMVCJRRQIHV6B21w/scIfhEhng=
Content-Type: multipart/alternative; boundary="_000_AS8PR10MB59259C016DA74A0FD05EF3089EE4AAS8PR10MB5925EURP_"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 1cfce0d0-ef4b-443c-7a72-08dbaab683f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2023 06:41:47.7586 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: alu5Wbj4dhG5F2WuS2AyX12QcYBjklbgPx04AV8LvkLFs1bfEf4B+Z6h0HAzWI9TL/PJhzueS+BdOA9fUh96h97/3N3bDMrJyU3zdRkqmRA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR10MB5334
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/MgCZSjt2icXTCdNdi8xwCJFe9Ck>
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: Fri, 01 Sep 2023 06:41:55 -0000

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