> > Yeah, sorry for the terminology there. I was still thinking of composites.
> > If the server supports just one composite for which it has a certificate,
> > say PQi+Tj, then this is every possible composite out of the one-element
> > set {PQi} and the one-element set {Tj}.
> > In general, I believe this to be the common case for servers (and the
> > worst case for interop), and expect a larger number of algorithms to be
> > supported at the client.
>
> Ah, ok, so this kinda works for the leafs, but goes wrong for the
> signatures up the chain—see my other mail 2 hours ago.I am assuming you mean [0]. You sent two mails in roughly that timeframe but this makes more sense :) -------------- 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). So again, composites would not make things worse up the chain, as far as interop of fully migrated endpoints is concerned. -------------- 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. -- TBB [0] https://mailarchive.ietf.org/arch/msg/tls/Rn7GHZGXnWv_TRxBpMkRXAYQ-wk/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
