On Fri, Aug 8, 2025 at 9:32 PM Wang Guilin <Wang.Guilin= [email protected]> wrote:
> 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. > Those specifications already exist. This is how TLS works today. It's true there is some ambiguity about the deployment of trust anchors, but that has always been true even with more widely deployed algorithms hence the discussion around methods of signaling trust anchors. Note that as Dennis Jackson points out, you can supply a chain that terminates in a PQ trust anchor but is *also* cross-signed. -Ekr > > 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]> > *收件人：*tls <[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] > To unsubscribe send an email to [email protected] > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
