[Acme] Internet-Draft acme-pqcnegotiation-03

Alexandre Augusto <alexandre.a.giron@gmail.com> Fri, 16 February 2024 23:30 UTC

Return-Path: <alexandre.a.giron@gmail.com>
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 DA9B2C14F6A6 for <acme@ietfa.amsl.com>; Fri, 16 Feb 2024 15:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com
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 G6V4L3Ib6H2R for <acme@ietfa.amsl.com>; Fri, 16 Feb 2024 15:30:23 -0800 (PST)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 BE58BC14F704 for <acme@ietf.org>; Fri, 16 Feb 2024 15:30:23 -0800 (PST)
Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-5dbd519bde6so2171767a12.1 for <acme@ietf.org>; Fri, 16 Feb 2024 15:30:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708126223; x=1708731023; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=fbIWelq8deC/RowPyDLkZU4LphpiFlosc+pe7GZY1m4=; b=Vif0HlWUJBK+pZ3OsYlEsuFX86Z6pOgYf6lwnKm4M2gDyq9OrCl/a74Y8r3Isak1+X 81LtslYzmOeBq4DmjNiCjcOKi2rX9pryTifcXuClB0DeLylKGM19AozwiV6OQ9NWWVrh Pj5V2y4ttuP7r5MOrl+zK3QzRxZJCcLaUGA26DxZ/SuptlJvZ6l38M3cLYL/eqB5el+L w3uNP1l3SYwkDPSgA3UTsgQeQL5X/MYlHz3+nicEBlQU6b38OVy1F1G6Ce7Cy3TNC3VR Qi/pOSAMnXrc0LKEPIYlZ5SCCYkDwtuVVQInuMDAhfdsgeYT7wiN/mT0XrTmOVeYYIQY 9fqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708126223; x=1708731023; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fbIWelq8deC/RowPyDLkZU4LphpiFlosc+pe7GZY1m4=; b=fcYY53suK3qHs8AkOr7JshAMwdyc166m6CqzOTwE4EYcDddsM6LpQxvkg2DXYL0yAW JB6zd9QsLuuknVDbh/ue/SLW0HcQ1VpahBOHj91bIcvGAMUQExQYfdFXEFMFfpyZiII4 KWEGTWUI+l+52iN74Ncs7cutubrnbYOXiSrwJgNlgwUAY6/2DeNtTucq25mDbpfe2Rc9 YwuXPLMUwZhjpUSsmeAH6EPdjR8jdLH+qbgJdhgWaRvwH0cFDwkUTegYKoZf1yCCxpeH chT85UN9ln4G0zxlvDEEXkS+BaECRq/+ZmSd1M6jSXGne2KA4LtGxIHenu2ar60Oz5qu p7pA==
X-Gm-Message-State: AOJu0YxxHf0ad//PbXFdJmDMMBxz9jNmQmiR/iOYvWy7nuamZGi8fgxm 4q1QDNOy+aCI60U3U94T8fDXh/JpNJYWShjYGX1tZ6rQqs55raiwGc18o7ephHmsMd5Ny/yrlL+ 6sf3MZIMU2JGby1+2E+K+da8BdJo7pVdl
X-Google-Smtp-Source: AGHT+IGIouDhnZWT0tDusKHsOEJHmGNXW4va0glNcB/zrk7KWLvcW49tTdUGNLbQZu37ik4TvCGMTy0o4o4PCRyzoXE=
X-Received: by 2002:a05:6a20:9f0a:b0:19c:6297:13b1 with SMTP id mk10-20020a056a209f0a00b0019c629713b1mr3896745pzb.58.1708126222110; Fri, 16 Feb 2024 15:30:22 -0800 (PST)
MIME-Version: 1.0
From: Alexandre Augusto <alexandre.a.giron@gmail.com>
Date: Fri, 16 Feb 2024 20:29:00 -0300
Message-ID: <CABLzjm_rBtV0StWh-Ax_=cWNVdbCMGFGJSzxeuq6meAhx7QLmA@mail.gmail.com>
To: acme@ietf.org
Cc: 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="000000000000b355c70611882083"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Om216R4rft0l83nzUXp7F69EQwM>
Subject: [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: Fri, 16 Feb 2024 23:30:28 -0000

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