> > I am assuming you mean [0].
Yes. > Let's start with two fully migrated endpoints: > > Assume each CA, CAi, is today using a traditional algorithm Ti and is now > planning to use a post-quantum algorithm PQi. Thealgorithms may obviously > overlap for different CAs. Call this plan 1. > > Now plan 2: Instead, CAi switches to the composite PQi+Ti (made up of the > same algorithms it would have used, it just keeps using the old algorithm > it has experience with in the composite). > > Assume we use plan 2 and a client implementing the cross product of its > chosen algorithms, while connecting to some server, fails to validate a > certificate issued by (say) CAi. By deduction, it cannot validate PQi+Ti, > so it either cannot validate PQi (meaning this connection would have also > failed, had we followed plan 1) or it cannot validate Ti (meaning this > connection would have failed now). > This sounds like you suggest combining the classical chain for a legacy client with the post-quantum chain. How do you address the problem I pointed out that you don't want upgraded clients to accept the classical chain for the legacy client? So that leaves us with the somewhat orthogonal problem we are facing every > time we add a new signature algorithm: Legacy software (whether at the > client or server) doesn't know it and will break. Note that this applies to > both ML-DSA as well as all ML-DSA composites, so I had disregarded it as a > separate challenge outside the discussion of PQ-only vs. PQ+T-hybrids. > In other words, we will be tackling this problem either way in our > PQ-migration efforts. > To wit: the classical certificate for a legacy server obviously has a classical leaf, but a post-quantum chain. That could be composite. The present proposal does not recover composites there as that would require a server upgrade. If there isn't a way to do that, then the present proposal has no value, as clients are only as secure as the weakest thing they accept. Best, Bas
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
