Viktor, I think we are talking about two different things. I was explicitly (see the term "cross product") refering to what I believe would be a typical verification implementation like the following (pseudocode only).
Verify(codepoint, sig, sigLen, pk, pkLen, msg): PQsig <- GetPQsigAlg(codepoint) Tsig <- GetTsigAlg(codepoint) assert(NULL != PQsig) assert(NULL != Tsig) assert(sigLen == Tsig.sigLen + PQsig.sigLen) assert(pkLen == Tsig.pkLen + PQsig.pkLen) msg' <- "Prefix || Label || len(ctx) || ctx || PH( M )" assert(PQsig.Verify(sig[0..PQsig.sigLen], pk[0..PQsig.pkLen], msg) assert(Tsig.Verify(sig[PQsig.sigLen..sigLen], pk[PQsig.pkLen..sigLen], msg) return true This blueprint implements a cross product of signature schemes (I am leaving out the details of parsing DER, etc), all at once. Just fill in GetPQsigAlg and GetTsigAlg with the algorithms you intend to support. Everything I said follows from there. If the above code cannot validate a valid composite, you are missing support for either the PQsig or the Tsig involved, which would have caused problems in either "Plan 1" or today, respectively. All an existing client needs to do is to implement the above with GetTsigAlg resolving all currently supported algorithms and GetPQsigAlg supporting the ML-DSA variants it would have supported in the non-composite case. -- TBB
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
