BTW If this is for a private PKI, then you can use the certificate_authorities extension today.
On Wed, Aug 6, 2025 at 11:34 AM Dmitry Belyavsky <beld...@gmail.com> wrote: > Hi Thom, > > Thank you, it offers better perspective than the scenarios we considered > > On Wed, Aug 6, 2025 at 10:09 AM Thom Wiggers <t...@thomwiggers.nl> wrote: > > > > Hi Dmitry, > > > > You may be interested to review the extensive discussions on the issue > of negotiation of which trust anchors are usable in the TLS working group. > > > > The relevant draft is > https://datatracker.ietf.org/doc/draft-ietf-tls-trust-anchor-ids/ but if > you go through presentations at prior IETFs and TLS WG interims you should > find a bunch of presentations. Additionally, there have been dozens or > maybe even hundreds of emails on this subject (and the associated risks to > trust anchor negotiation). > > > > Hope this helps, > > > > Cheers, > > > > Thom > > > > Op 6 aug 2025, om 09:28 heeft Dmitry Belyavsky <beld...@gmail.com> het > volgende geschreven: > > > > Dear colleagues, > > > > We came across the following scenario: > > Server has 2 cert chains, PQ and classical, and prefers PQ. > > > > A client doesn't have any PQ CAs configured, but at the handshake > > sends PQ sigalgs among others. The server replies with the PQ chain, > > the client can't verify it, and the connection can't be established. > > > > We've discussed it and see the following scenarios: > > > > 1. Consider it to be a client misconfiguration. To prevent this from > > happening, the client is better not to send PQ algos in sigalgs. To > > not send PQ algos, clients should scan CAs and stop sending PQ algos > > if no PQ CAs are available. > > > > 2. "Smart" clients (e.g. web browsers) should implement fallback from > > PQ to classical algorithms if PQ connection can't be established. I > > vaguely recollect that there were browsers downgrading the protocol > > from TLS 1.3 to TLS 1.2 (and may be lower) at least several years ago > > but couldn't find the description of this behavior. > > > > 3. Cross-signing PQ certs with classic crypto algorithms, as it > > happened before. It ensures the best client experience. The downside > > of this behavior is that we have to sign a stronger cert with a weaker > > CA, and personally I suspect some browsers forbid such chains. > > > > Are there any other scenarios we are missing? Is this topic relevant > > for TLS, PQUIP, or some other community (e.g. CA/Browser forum)? > > > > -- > > SY, Dmitry Belyavsky > > > > -- > > Pqc mailing list -- p...@ietf.org > > To unsubscribe send an email to pqc-le...@ietf.org > > > > > > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > 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
