Re: [Acme] Internet-Draft acme-pqcnegotiation-03

Ilari Liusvaara <> Sat, 17 February 2024 15:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6B03C14F68A for <>; Sat, 17 Feb 2024 07:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y1MTi9AVFb9E for <>; Sat, 17 Feb 2024 07:50:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6AB7C14F68E for <>; Sat, 17 Feb 2024 07:50:06 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82A311EA38 for <>; Sat, 17 Feb 2024 17:50:03 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id uJBPW7IH9iD3 for <>; Sat, 17 Feb 2024 17:50:03 +0200 (EET)
Received: from LK-Perkele-VII2 ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 33A4A7A for <>; Sat, 17 Feb 2024 17:50:02 +0200 (EET)
Date: Sat, 17 Feb 2024 17:50:01 +0200
From: Ilari Liusvaara <>
Message-ID: <ZdDVqVI8-nCfD5iM@LK-Perkele-VII2.locald>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Acme] Internet-Draft acme-pqcnegotiation-03
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: Sat, 17 Feb 2024 15:50:10 -0000

On Fri, Feb 16, 2024 at 08:29:00PM -0300, Alexandre Augusto wrote:
> Dear community,
> I have published a new version of draft-giron-acme-pqcnegotiation. Any
> feedback is appreciated.
> Diff:
> Pros:
>      - RFC 8555 offers a 'try-and-error' negotiation: doing account
> creation + identifier validation + finalize request to see that the desired
> signature/algorithm might not be supported (e.g., badKey error). This draft
> includes support for algorithm negotiation in a flexible way: clients check
> support in advance and they are able to select a suitable algorithm for
> each "piece" of the certificate. Therefore, this draft can save resources
> on both sides (client and server).

Account signatures always use JWS, so those should use JWS mechanisms
for specifying the algorithms, not OIDs. However, There is an issue with
using JWS alg values: "EdDSA" is not an algorithm. However, JOSE WG is
working to replace that by "Ed25519" and "Ed448", both of which are

How is client supposed to use the certificate signature algorithm
information? I do not think there is any facility in ACME that would
let client affect signature algorithm selection. The proposed profiles
can affect signature algorithm, but do so in indirect way.

For public key, a single OID is not enough, because all generic ECC
keys have the same OID, and the curve used is a parameter. It would be
possible to give base64url encoding of the AlgorithmIdentifier for the

>       - RFC 8555 does not clearly support issuing/revoking KEM
> certificates. This draft includes support for KEM certificate issuance and
> (now) revocation. It's simple, but it does not break compatibility with old
> clients. The procedures have optimizations available, depending on your use
> case.

I don't think the proposed revocation mechanism can work. The problem is
how ACME represents revocation by private key. That mechanism can only
work for signature keys. And furthermore, there must be at least one JWS
algorithm usable with the private key.

I think making revoking KEM certificates using private key would take
a whole new revocation endpoint. One could also use this to solve the
algorithm issues caused by using JWS signatures instead of TLS
signatures. Every key type usable in TLS is guaranteed to have TLS
signature scheme, but is not guaranteed to have JWS algorithm.

And instead of screwing with CSRs, I think it would be better to get rid
of CSRs altogether and transmit the information in NewOrder request. The
ACME server could then use challenge mechanisms on the certificate key,
depending on its policies. This would solve many annoying issues in

> Some notes:
> I think that we could envision a more inclusive ACME by considering
> different types of clients. This way, TLS is better adopted in the
> different computing environments available. I think that our thoughts are
> somewhat focused on the "most clients ...." but this does not consider the
> "few", thus not being inclusive enough (or generic). Maybe a few clients
> require (or will benefit from) an ACME with better performance and/or
> support for different algorithms (e.g., KEMs), etc. But this does not mean
> that they should be neglected. For example, maybe KEMTLS is better in some
> scenarios, but if ACME is not "his friend", KEMTLS adoption will be
> difficult.

I don't think performance of ACME matters very much, as long at is not
very bad. E.g., I think 5 seconds and 20 seconds is not a major
difference, but 10 seconds and 10 minutes might very much be.

Most ACME clients are effectively single-threaded, working on one order
at a time. There are multiple annoying race conditions in ACME that a
multi-threaded client would have to deal with. And synchronization
mechanisms for solving those are not trivial.

20 seconds per cert with average 60 day replacement period still works
with 250K certs. I think that anybody that comes even close to that is
going to use highly custom stuff.