On Thu, May 30, 2024 at 10:35:05AM -0700, Watson Ladd wrote: > On Tue, May 28, 2024 at 2:11 AM Dennis Jackson > <ietf=40dennis-jackson...@dmarc.ietf.org> wrote: > > > > Hi Ryan, > > > > On 27/05/2024 19:23, Ryan Hurst wrote: > > > > I don't understand your position on the verifier, the faith one can put in > > the chain of signatures is only the faith appropriate for the weakest > > signature. As such if a classical key is used to sign a PQ chain, an > > attacker would go after the classical signature ignoring the others. > > > > That's not quite right. > > > > Let's imagine we have a leaf public key L1, a PQ Public Key M1 and a > > Classical Public Key N1 and use <- to indicate 'signed by'. Consider the > > certificate chains: > > > > (1) L1 <- M1 > > > > (2) N1 -> L1 <- M1 (N1 and M1 are both intermediates signing the same > > leaf) > > > > (3) L1 <- M1 <- N1 (N1 cross-signs M1). > > Wait, I don't think the example's quite right (or maybe I'm just > confused). How can two intermediates sign the "same" leaf? Or is the > idea that we have L1' and L1 X509 Certificates with the same public > key presented in the chain but signed by different intermediates, and > the verifier figures out which one to use for the key exchange. (Yes, > this is really nitpicky, but there is a distinction between keys and > certs here that matters when counting bytes). Also the intermediates > aren't the roots, and I don't think we're relaxing that rule for > purposes of this discussion.
The idea is to send three certificates in the message: 1) The end-entity certificate signed by the intermediate. - TLS 1.3 requires this to be the first. 2) The intermediate signed by post-quantum root. 3) The intermediate signed by classical root. While TLS 1.3 says this SHOULD be supported, in practice there are TLS 1.3 clients that blow up upon seeing this (including even when PQ root is a trust anchor). And of course it also makes certificate message larger, which has negative impact on performance. -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
