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

Aaron Gable <aaron@letsencrypt.org> Tue, 27 February 2024 04:56 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 C98A5C14F6F7 for <acme@ietfa.amsl.com>; Mon, 26 Feb 2024 20:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_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
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 SqMHZV3fp-KN for <acme@ietfa.amsl.com>; Mon, 26 Feb 2024 20:56:34 -0800 (PST)
Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) (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 8BC9DC14F6BB for <acme@ietf.org>; Mon, 26 Feb 2024 20:56:34 -0800 (PST)
Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-21f70f72fb5so2633209fac.1 for <acme@ietf.org>; Mon, 26 Feb 2024 20:56:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; t=1709009793; x=1709614593; 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=aCq4QxG1ewI8IPtV161zL+o9k9X7kqSsKTVyhqwJG2U=; b=EB/8aMyNWe3G1K6T7ccOpJaqki743FpOkBox5p49pk/RMZw4mrw46l4eOXjbq6HvaT vFG3jZ4VTGRx7cRTfhT4CXFmsTcAOWCFe3Tae7OSMWoSDcot84QRkNtc1znFi0Z4pv7m 1PNQ0Q5eyoEe9v/u6LUhwtvWtRPHleapX866I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709009793; x=1709614593; 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=aCq4QxG1ewI8IPtV161zL+o9k9X7kqSsKTVyhqwJG2U=; b=WQPz4Ub8OCVVTp6SXugKzebJNQ4JRBWCvuawOOBqzAavMukkKqOL0cZhXoc2MFS7pZ F1BBKS0YRtMYEgqlCzCpHOL7yGaZD3swygwtu8F822lT8lBIoIFyclPkzVTtBL5ur/7b 7Yve/eA1YaO8uUtVf+FygAh+4UoMqUjIF0krBklJUaW7ZRgD7k5F0N2K93pEonJdtX7P 8ioEpmY+xn2wCuoQ+8/Q4L34S6Rgli17IQLau85nY3/e6O/MfRoqt+eG3n8/OnyOPKCF 7KeXHW+W2gmLyfuUI/pId/fRppzNUSl796CPRoT9gkhx+p61vXQWs04dmB36QfjtZPZd XWHQ==
X-Gm-Message-State: AOJu0YyXOhcXlbXMZkPUDsz1Db9KJpzel/SDZD6P9gQ2H+ssFD/lsEJJ BUif5rrto8jwYhDG2G+u5A+mVFeTP4TOEKfZEp+NcDMk8fROZFXx2tzJeHnda1OQ3F4XsQKHiY2 E8G7dhSCSNl/NbbL1On2GRyJwq8TRjo84G1+o/Q==
X-Google-Smtp-Source: AGHT+IHxSoHtvdnj7sSIAJXtkvR1sZJR9pgfO8I5HJUySqrB+JRy/2nxxDg6/8l59LJObbwCgazSXHzikIb7ULyE33E=
X-Received: by 2002:a05:6870:20a:b0:21f:14cd:c5a7 with SMTP id j10-20020a056870020a00b0021f14cdc5a7mr10995112oad.19.1709009793422; Mon, 26 Feb 2024 20:56:33 -0800 (PST)
MIME-Version: 1.0
References: <CABLzjm_rBtV0StWh-Ax_=cWNVdbCMGFGJSzxeuq6meAhx7QLmA@mail.gmail.com>
In-Reply-To: <CABLzjm_rBtV0StWh-Ax_=cWNVdbCMGFGJSzxeuq6meAhx7QLmA@mail.gmail.com>
From: Aaron Gable <aaron@letsencrypt.org>
Date: Mon, 26 Feb 2024 20:56:22 -0800
Message-ID: <CAEmnEreMzrRC_vYWZORFJ0TBCoWZ_v=nQ+Lmd5LFkbZnuK5vfA@mail.gmail.com>
To: Alexandre Augusto <alexandre.a.giron@gmail.com>
Cc: acme@ietf.org, Ricardo Custódio <ricardo.custodio@ufsc.br>, Lucas Pandolfo Perin <lucas.perin@tii.ae>, Alexandre Giron <alexandregiron@utfpr.edu.br>
Content-Type: multipart/alternative; boundary="000000000000a7aa47061255d91e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/RYrc3ga8SLtTMk-t42aBFsJ5eDM>
Subject: Re: [Acme] Internet-Draft acme-pqcnegotiation-03
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: Tue, 27 Feb 2024 04:56:38 -0000

I have two main pieces of feedback on this draft, which unfortunately are
rather large / sweeping and would require rethinking the whole document to
address.

1) The algorithm negotiation mechanism is too specific. Why should ACME
add new API endpoints dedicated solely to listing the public key algorithms
that the server supports when we know that there are many other aspects of
certificates (validity periods and extended key usages to name two simple
examples) that clients also might want to discriminate on. ACME doesn't
need a key negotiation mechanism, it needs a profile advertisement
mechanism, a concept which has been discussed multiple times before
<https://mailarchive.ietf.org/arch/msg/acme/BLVAayrTrUCegT4s2twci3Q2BY8/>.

2) The proof-of-control mechanism for KEM pubkeys is too specific. ACME
already has an extensible mechanism for proving control over various
entities. Rather than adding a new /key-confirm endpoint that needs to be
POSTed to in the midst of finalization, simply define a new identifier type
for KEM keys and a new Challenge type that uses Encaps/Decaps to prove
control over the key. Then new-order requests can simply include the
desired key, the proof-of-control challenge can be completed
asynchronously, and at finalization time the server can simply confirm that
the CSR contains the same key as was included in the initial new-order
request (as it does for SAN identifiers today).

The matter of revocation for KEM certificates is interesting. But note that
ACME supports multiple methods of revocation: the revocation request
doesn't have to be signed by the certificate private key, it can instead be
signed by the original issuing account key (which still works with
certificate KEM keys), or it can be signed by an account which *controls
one or more identifiers in the certificate*. So with my suggestion from
(2), keyCompromise revocation can be accomplished by proving control over
the KEM key just like for a normal issuance, then requesting revocation
with the normal ACME account key.

Finally, the "1 RTT" mechanism for confirming control over the KEM private
key (i.e. encrypting the final certificate to the KEM key so that the
applicant cannot access the certificate unless they have the private key)
simply doesn't work in the WebPKI. The WebPKI requires that all issued
certificates be logged in Certificate Transparency logs, so the certificate
will be publicly available in plaintext for anyone (including the original
requester) to access.

I'm excited for ACME to adapt to the world of post-quantum cryptography,
and I look forward to future drafts of this document integrating better
with existing ACME mechanisms.

Aaron


On Fri, Feb 16, 2024 at 3:30 PM Alexandre Augusto <
alexandre.a.giron@gmail.com> wrote:

> Dear community,
> I have published a new version of draft-giron-acme-pqcnegotiation. Any
> feedback is appreciated.
>
> https://datatracker.ietf.org/doc/draft-giron-acme-pqcnegotiation/
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-giron-acme-pqcnegotiation-03
>
> 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).
>       - 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.
>
> Changes based on comments/suggestions:
> - The algorithm name representation (
> https://mailarchive.ietf.org/arch/msg/acme/OJk0_hmm7yp6sv_VJcJ_0qjL-YM/).
> I think it is better now.
> - Classical algorithms to the list (
> https://mailarchive.ietf.org/arch/msg/acme/DYBAH5327vdB1iVVIXLYgTSPjPA/):
> It is easy to add classical algorithms to the list now.
>
> 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.
>
> Obviously, if the community perceives an overlap or preference for other
> proposals, I am still happy and will make myself available to help if
> needed :-). Also, if the community prefers, we can focus on the KEM part,
> i.e., "acme-kem-certificate draft" instead of  "acme-pqcnegotiation draft".
>
> Best regards,
> --
> Alexandre Augusto Giron
> Federal University of Technology - Parana (UTFPR
> <https://coenc.td.utfpr.edu.br/%7Egiron/>)
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>