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 PM Eric Rescorla <e...@rtfm.com> wrote: > > > On Tue, Apr 15, 2025 at 7:58 PM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > >> On Tue, Apr 15, 2025 at 07:30:25PM -0700, Eric Rescorla wrote: >> > On Tue, Apr 15, 2025 at 7:02 PM Viktor Dukhovni <ietf-d...@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. >> > > > >> > > > 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 limited >> 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 that >> > 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-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
