Re: [Acme] Proposal: ACME Profiles

Aaron Gable <> Thu, 31 August 2023 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3027BC13AE52 for <>; Thu, 31 Aug 2023 08:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6YP8vHYzj-3p for <>; Thu, 31 Aug 2023 08:22:39 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 1EACFC151700 for <>; Thu, 31 Aug 2023 08:22:39 -0700 (PDT)
Received: by with SMTP id d75a77b69052e-4122129390eso5762811cf.0 for <>; Thu, 31 Aug 2023 08:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1693495358; x=1694100158;; 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;; 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: <> <ZPBYqyhNXPm/eBmX@LK-Perkele-VII2.locald>
In-Reply-To: <ZPBYqyhNXPm/eBmX@LK-Perkele-VII2.locald>
From: Aaron Gable <>
Date: Thu, 31 Aug 2023 08:22:27 -0700
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary="0000000000003f3c5b0604399d51"
Archived-At: <>
Subject: Re: [Acme] Proposal: ACME Profiles
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Aug 2023 15:22:43 -0000

On Thu, Aug 31, 2023 at 2:09 AM Ilari Liusvaara <>

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