Re: [Acme] Proposal: ACME Profiles

Matt Palmer <mpalmer@hezmatt.org> Thu, 07 September 2023 22:58 UTC

Return-Path: <mpalmer@hezmatt.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 D9CE2C151074 for <acme@ietfa.amsl.com>; Thu, 7 Sep 2023 15:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 ABQLU40_xV9h for <acme@ietfa.amsl.com>; Thu, 7 Sep 2023 15:58:10 -0700 (PDT)
Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D433AC14CF1A for <acme@ietf.org>; Thu, 7 Sep 2023 15:58:08 -0700 (PDT)
Received: from mistress.home.hezmatt.org (2001-44b8-510e-8600-a7da-55a4-3142-396b.static.ipv6.internode.on.net [IPv6:2001:44b8:510e:8600:a7da:55a4:3142:396b]) by mail.hezmatt.org (Postfix) with ESMTPSA id 2A9DC1F6039 for <acme@ietf.org>; Thu, 7 Sep 2023 22:58:05 +0000 (UTC)
Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id CFF0E9FFC1; Fri, 8 Sep 2023 08:57:48 +1000 (AEST)
Date: Fri, 08 Sep 2023 08:57:48 +1000
From: Matt Palmer <mpalmer@hezmatt.org>
To: acme@ietf.org
Message-ID: <ZPpVbCcup8lfWHKA@hezmatt.org>
References: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com> <AS8PR10MB59259C016DA74A0FD05EF3089EE4A@AS8PR10MB5925.EURPRD10.PROD.OUTLOOK.COM> <CAMEWqGvK6T2v_1yco=-nmN603HjoZ5f+UPs-mdPw=g3YwDU8ug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMEWqGvK6T2v_1yco=-nmN603HjoZ5f+UPs-mdPw=g3YwDU8ug@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/JsJg0CHdR3nz_iM9avSCX2ZD0S8>
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 22:58:11 -0000

On Thu, Sep 07, 2023 at 05:12:57PM +0100, Q Misell wrote:
> 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.

Can you expand on why you feel that a set of profiles isn't sufficient? 
While the issue of combinatorial explosion has been raised as a theoretical
problem, I haven't seen anyone involved in operating a CA say "we have
mapped out the set of profiles we would need to support, and it is
unworkably large".

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

While I agree this seems to nicely split the difference, I worry that it's
actually the worst of both worlds: CAs will still need to support a
potentially-unbounded set of profiles (for any variation that can't be
expressed reasonably as a set of boolean values) while also having the
"validating a complex request" issues.  It also makes it difficult to
delineate what should be a "flag", and what should be a separate profile, as
your example can be made to show:

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

I can totally imagine a CA starting off with a single profile, with no
options.  Then they start offering a ECDSA intermediate, and "for
compatibility reasons" decide to stick with the single profile and make
"ecdsa_intermediate" a default-false boolean flag (with false indicating
"use an RSA intermediate").  Then, some years down the road, PQC rolls out,
and "for compatibility reasons", the CA adds a new flag, "pqc_intermediate",
which is now mutually-exclusive with the "ecdsa_intermediate" flag, and
we're back into having to validate a whole set of flags.

One can partially mitigate this scenario by saying that all flags defined to
be associated with a profile must be specified in a request (ie "no default
values"), but that will most likely end up with profile proliferation, as
whenever a CA needs to add a flag to their profiles, they have to define new
profiles (and keep the old ones around, for compatibility).

For example, consider a CA that has "rsa_intermediate" and "ecdsa_intermediate"
profiles, but *doesn't* support OCSP must-staple.  These profiles have no
options.  Then, due to customer demand, they implement OCSP must-staple, and
want to make it optional.  However, they can't add an option flag to the
existing profiles (because that would break usage for all their existing
clients who don't specify a value for that flag), so they need to make
"rsa_intermediate_ocsp_must_staple" and
"ecdsa_intermediate_ocsp_must_staple" profiles, where ocsp_must_stable is a
flag, and migrate all users to that profile (and teach them to set the flag
if they want it).

Lather, rinse, repeat for all other optional features the CA introduces over
time.

- Matt