On Wed, Aug 06, 2025 at 09:28:07AM +0200, Dmitry Belyavsky wrote:
> We came across the following scenario: Server has 2 cert chains, PQ
> and classical, and prefers PQ.
If this is for a public HTTPS server, my take is that it is premature
for the server to offer PQ certificates signed by non-WebPKI CAs. Since
there are no PQ roots in the WebPKI trust bundle, PQ HTTP server server
certificates are best avoided for now.
ML-DSA works for my SMTP server, because SMTP default to unauthenticated
opportunistic TLS, and DANE TLSA "3 1 1" records don't rely on a CA
signature. In application protcols where TLS is by default authenticated,
PQ certs are not yet ready for prime-time.
So basically, the onus to do the interoperable thing is primarily on the
server: don't deploy certs the expected client community can't verify,
be they PQ or "classical".
Perhaps TA negotiation will help some time, till then take appropriate
care.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
