Return-Path: X-Original-To: tls@mail2.ietf.org Delivered-To: tls@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 811FD1CBF17B for ; Tue, 15 Apr 2025 20:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMoP7kz70n2o for ; Tue, 15 Apr 2025 20:29:08 -0700 (PDT) Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 095991CBF15E for ; Tue, 15 Apr 2025 20:29:07 -0700 (PDT) Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-5259327a937so2527307e0c.0 for ; Tue, 15 Apr 2025 20:29:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744774147; x=1745378947; h=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=xBV7wGDcjR+eL4Wh+5qVx78XZkkUleSxNInsKVbF4iU=; b=ER1iL2I0n3IW3xFFj6uWtD+u0Lqh1zHCHUb1YQVZf0PKXlm2nxAImUjOWfNnxbMnon DnCk5Y+6YgeQw/jvJQGFwSjJzIDgjjEcYILWTYMKCC8VvjHBrlCds/Bs6Qh3A9/8nsRT 4Xv95U1+unUK7MYAHQbaOBfuU7dz6nbAVt/iyh0X5XsgQ3imsRSkhMSGCkV7Xk2rtqzX pHTrw4qlEAEkpKuChykgsjJBvbUQgnCkK6AoMyoagYCGxZTgmfjruQ9uAkkxXNH/Ba8j SN0jF5nPZ51/PjCoccyHriLBAPhQ4PTulvzrZFHvt8IRaIBniQZ+UqlfpK0U22yCu9ZJ 0FIA== X-Gm-Message-State: AOJu0YyM/wz/dikfYqOLVf28HRb25R54vVNso+RIN8lfqFsJTjuNYzYI kChFzMeQkDb+VmepiL9RkL7ayOWShpuCnMD2+QCkFcOkgjl9bYdjQAVWGw== X-Gm-Gg: ASbGncvfCD+aBRNP/5kIdNfDfogV55Xp+1N8cpzM6cSooLFP8383S9he4kNQPOttMRc 5jMUFcHY01J4TsW/exK5HLL75pAaPKnpN2Lg/b6uKI8q/Ja/vxCLs2uN2Ny7WQJlxbnHC776itM 3qwzPs3lZvKp0gnsWj0EtUf/PMDGQUXjRP1He0f6SvsI3gmxXiz19eluE2Qs+AJUEqBSks2TQiJ 2iBN7MZJkwDehsv8LM3d00l106DpTT2i4PS99hn+J4MJnEPBa+PojJzy4xRq4LbDvgnuJv4oI/D 5dRWlrDdf+lPws+8chIfyyMnR8eNYM91ppW55IB+HO1y1s42mMM08awAGDHsIkwCJcbGbO3NCmV y5w== X-Google-Smtp-Source: AGHT+IGeEhkILs/iL69CnpbWhZWvoiEDfk7YFEcC11iB5zSP3ktfXX08I2R9MfxQx/7bDLpUJzpSnQ== X-Received: by 2002:a05:6122:8d2:b0:528:4f4b:f0c0 with SMTP id 71dfb90a1353d-5290dfe51a1mr81633e0c.5.1744774147249; Tue, 15 Apr 2025 20:29:07 -0700 (PDT) Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com. [209.85.222.47]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-8755727ff7bsm3057786241.24.2025.04.15.20.29.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Apr 2025 20:29:06 -0700 (PDT) Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-86d42f08135so2243751241.0 for ; Tue, 15 Apr 2025 20:29:06 -0700 (PDT) X-Received: by 2002:a05:6102:5e7:b0:4b2:adfb:4f91 with SMTP id ada2fe7eead31-4cb5930c9afmr37167137.21.1744774146775; Tue, 15 Apr 2025 20:29:06 -0700 (PDT) MIME-Version: 1.0 References: <07CB46EC-758E-4204-901A-CC8812B33A5F@sn3rd.com> In-Reply-To: From: Andrey Jivsov Date: Tue, 15 Apr 2025 20:28:55 -0700 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUEozeEBkkPMK7vum3RK4G3g7gw4Nn2NkWsWsSzBHuXMmRASO20Zv7oCPkU Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000003b67c40632dce37d" Message-ID-Hash: 23VYSILJ3QVWZQEA67HDIAIVPFSFJVTQ X-Message-ID-Hash: 23VYSILJ3QVWZQEA67HDIAIVPFSFJVTQ X-MailFrom: brainhubr@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Adoption_Call_for_Use_of_ML-DSA_in_TLS_1=2E3?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003b67c40632dce37d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Using EdDSA as an example, we know that CA's don't just blindly sign EE certificates. They are in control of what public keys are allowed in a PQ cert, including for EE certs, and if they choose that it is standalone ML-DSA, this will have profound implications on TLS and other protocols, in a way that that's what will become a dominant way to configure certificate chain. Protocols that copy design and deployment experience from TLS will standardize on standalone ML-DSA because this is what "industry" supports and "time to market". On Tue, Apr 15, 2025 at 8:19=E2=80=AFPM Eric Rescorla wrote: > > > On Tue, Apr 15, 2025 at 7:58=E2=80=AFPM Viktor Dukhovni > wrote: > >> On Tue, Apr 15, 2025 at 07:30:25PM -0700, Eric Rescorla wrote: >> > On Tue, Apr 15, 2025 at 7:02=E2=80=AFPM Viktor Dukhovni > > >> > wrote: >> > >> > > On Tue, Apr 15, 2025 at 01:55:35PM -0700, Andrey Jivsov wrote: >> > > >> > > > I don't think that standalone ML-DSA should be adopted. >> > > > >> > > > There is time to move to a non-hybrid X.509 and digital signatures >> in the >> > > > future. >> > > > >> > > > This topic has implications to availability of X.509 certificates, >> as >> > > > there is a real risk that CAs will prefer standalone ML-DSA to the >> > > > exclusion of hybrids, and also that other protocols will be limite= d >> to >> > > > standalone ML-DSA. >> > > >> > > But CAs do not choose EE keys, the key in the CSR is chosen by users= . >> > > >> > >> > Well, yes and no. CAs, at least in the WebPKI, will only sign keys tha= t >> > are allowed by the CABF Baseline Requirements (which, AFAICT, do >> > not allow any PQ algorithms at present). >> >> Yes, of course, CAs will only sign those user-requested keys that they >> support, but it is still the user (be it a bot the user deployed in some >> cases) that chooses the key algorithm, from the set of key algorithms >> supported by the CA. > > > Yes, but the CAs are historically quite conservative about this. You'll > note that CAs still don't support EdDSA, for instance. So I don't think > it's > actually a safe assumption that CAs will support both ML-DSA and > ML-DSA hybrids. > > > >> Market demand and stable specifications will >> determine whether/when CAs will support hybrid keys, and users will >> then be able to request hybrid certificates. I don't see this adoption >> call as a plausible barrier. > > > I agree that this adoption call is largely irrelevant to what CAs support= . > > -Ekr > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org > --0000000000003b67c40632dce37d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Using EdDSA as an example, we know that CA's don&= #39;t just blindly sign EE certificates. They are in control of what public= keys are allowed in a PQ cert, including for EE certs, and if they choose = that it is standalone ML-DSA, this will have profound implications on TLS a= nd other protocols, in a way that that's what will become a dominant wa= y to configure certificate chain. Protocols that copy design and deployment= experience from TLS will standardize on standalone ML-DSA because this is = what "industry" supports and "time to market".

On Tue, Apr 15, 2025 at 8:19=E2=80=AFPM Eric Rescor= la <ekr@rtfm.com> wrote:


On Tue, Apr 15, 2025 at 7:58=E2=80=AFPM Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Tue, Apr 15, 2025 at 07:30:25PM -0700, Eric Rescorla wrote:
> On Tue, Apr 15, 2025 at 7:02=E2=80=AFPM Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
>
> > On Tue, Apr 15, 2025 at 01:55:35PM -0700, Andrey Jivsov wrote: > >
> > > I don't think that standalone ML-DSA should be adopted.<= br> > > >
> > > There is time to move to a non-hybrid X.509 and digital sign= atures in the
> > > future.
> > >
> > > This topic has implications to availability of X.509 certifi= cates, as
> > > there is a real risk that CAs will prefer standalone ML-DSA = to the
> > > exclusion of hybrids, and also that other protocols will be = limited to
> > > standalone ML-DSA.
> >
> > But CAs do not choose EE keys, the key in the CSR is chosen by us= ers.
> >
>
> Well, yes and no. CAs, at least in the WebPKI, will only sign keys tha= t
> are allowed by the CABF Baseline Requirements (which, AFAICT, do
> not allow any PQ algorithms at present).

Yes, of course, CAs will only sign those user-requested keys that they
support, but it is still the user (be it a bot the user deployed in some cases) that chooses the key algorithm, from the set of key algorithms
supported by the CA.


Market demand and stable specific= ations will
determine whether/when CAs will support hybrid keys, and users will
then be able to request hybrid certificates.=C2=A0 I don't see this ado= ption
call as a plausible barrier.

_______________________________________________
TLS mailing list -- tls@i= etf.org
To unsubscribe send an email to tls-leave@ietf.org
--0000000000003b67c40632dce37d--