It may sound better for us to have specifications that technically work for the server in such scenarios prefering either PQ cert chains or classical chains.
The QoS for the two choices will depend on the maturity of PQ transimission, and this can be changed gradually. So, such servers can change their preferece gradually as well. Guilin 发件人：Viktor Dukhovni <[email protected]<mailto:[email protected]>> 收件人：tls <[email protected]<mailto:[email protected]>> 时 间：2025-08-06 22:31:09 主 题：[TLS] Re: Server dual-chains in the period of PQ transition 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 -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
