Re: [Acme] Proposal: ACME Profiles

Aaron Gable <aaron@letsencrypt.org> Thu, 31 August 2023 15:22 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 3027BC13AE52 for <acme@ietfa.amsl.com>; Thu, 31 Aug 2023 08:22:43 -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=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 6YP8vHYzj-3p for <acme@ietfa.amsl.com>; Thu, 31 Aug 2023 08:22:39 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 1EACFC151700 for <acme@ietf.org>; Thu, 31 Aug 2023 08:22:39 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-4122129390eso5762811cf.0 for <acme@ietf.org>; Thu, 31 Aug 2023 08:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; t=1693495358; x=1694100158; 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=WlhiIyP1CNsOrTDn3cxn4u8tvpAGxjZcKtmWxhECovA=; b=f6xwag3Lq6FQ5b9nUsTnhqur28AjGwrNm8/xPid5cYNwQwyH//M/s9HK92nxmC0XZ+ WCw/hDuw2c3eY0pdJlXDWYbqhPm61/Z9vMH/kI8J0vk8Z+aGeyHGm2jpIQ2SkZyHhXnf I8VKuIHyoBNmlmgcSpxgQKMFJ6eupsDr5k8ls=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693495358; x=1694100158; 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=WlhiIyP1CNsOrTDn3cxn4u8tvpAGxjZcKtmWxhECovA=; b=jlqJOUgqQIHMD1+PIMXAssgCwEfLdrRXow+0hitDyLfjpHvnUf5G43b0KWVGs0ZvKO R9sdLL+2bt8/oIcy0DWQXzsk3VXGoSr0V3E2w9yG5bjSha3MkgPKdN3LoM5Cp7Syz5dq Gmm6Td/XGtrV6U83A00UxO+Cwf2f5e1LH9AWDTDWEund9FpwsRTIm5Zbu3LZ4u/cA6mH 7SHY0m5zWKzTYDeI5k28akzKkStbMybyxbgkVDmIymAimerzGuP0TCijRSXBE06WpEp5 WuA4ca71aq1XLanxyQD2lgBfmRwMbjOtJrLvGxIEed+RbEAf9sq+5atDHBzWYP4SvLiH aYww==
X-Gm-Message-State: AOJu0Yy5y3OjmNxBw6esUibBaf2bFf9lmXKWT8CRZez5Ss8tDYqfkaw0 mRd2+aFV1RpEViRa3o/P3UzytUcHibsmznscw6/+JnSTCQHcm8Se
X-Google-Smtp-Source: AGHT+IFJBtRHE3N7gtdoz0oUMmaVPqvVZIv6g9023uFJZ8GZVN9CrR1qXPLux3Lw+/T+7kAn/ZQQxfaYI/XPjshemac=
X-Received: by 2002:ac8:5846:0:b0:412:13e4:fe27 with SMTP id h6-20020ac85846000000b0041213e4fe27mr3412208qth.37.1693495358072; Thu, 31 Aug 2023 08:22:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAEmnErfJvsxR15OL2BCWX5L0g-wrv5ur3xgsH7H5U5UpR7dWNg@mail.gmail.com> <ZPBYqyhNXPm/eBmX@LK-Perkele-VII2.locald>
In-Reply-To: <ZPBYqyhNXPm/eBmX@LK-Perkele-VII2.locald>
From: Aaron Gable <aaron@letsencrypt.org>
Date: Thu, 31 Aug 2023 08:22:27 -0700
Message-ID: <CAEmnErdepWptmPonLzJ5+K0GR6E2m+Jkt9sAt+jd6cOxkorA8Q@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003f3c5b0604399d51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/X60fw62xOSGGPXVb5_-pFOyjOh0>
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, 31 Aug 2023 15:22:43 -0000

On Thu, Aug 31, 2023 at 2:09 AM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> 1) There may be a number of orthogonal properties, causing the total
>    number of possible profiles be very large (the CA-side code is
>    NOT complex).
>

I'm not super concerned with combinatorial explosions of profiles. A CA
could offer many profiles that differ in small ways, but
a) It would be their responsibility to ensure that all profiles abide by
their PKI's requirements; and
b) It would be their responsibility to clearly communicate what each of
those profiles means to their subscribers.
Honestly, doing both of those is difficult. So I think CAs will be
incentivized to limit themselves to a small number of well-curated
profiles, just like they limit themselves to a single profile today.


> I think the server should reject the order creation if "profile" field
> is present, but contains some unknown or disallowed value. The default
> only appiles if there is no "profile" specified.
>

I considered this, because as you say it certainly makes sense to simply
reject orders which request a non-existent profile. However, I think that
it breaks down in practice: we know that there will be clients which are
set up once, configured with a profile name once, and then never updated
ever again. The CA needs the ability to evolve and deprecate profiles
without causing those clients to permanently fail. Therefore I think it is
best that the ACME server SHOULD reject such requests but MAY ignore the
unrecognized profile and select a default instead, or something like that.


> The reason why TLS 1.3 changed the algorithm negotiation to be more
> pick-and-choose is because the TLS 1.2 way would have been completely
> unworkable.
>

I was specifically referring to the combinatorial explosion of four-part
cipher suites available in TLS 1.2, versus the much smaller list of
two-part cipher suites available in TLS 1.3. Allowing clients to
mix-and-match key exchange algorithms with bulk cipher and hashing
algorithms led to significant problems.

Aaron