Actually, allowing such combinations might actually be useful.  For example:

first_signature_algorithm = [ECDSA-P256, SLH-DSA]
second_signature_algorithm = [ML-DSA, SLH-DSA]

Which would effectively convey that the client would be happy with either a 
single SLH-DSA signature OR a combination of ECDSA and ML-DSA signatures 
(which, IMHO, is a quite reasonable policy).

The idea is that we would accept it if a signature from both lists are present, 
and we're ok with the same signature satisfying both lists.

Of course, whether we want to support this sort of thing, given the potential 
for it being misused by someone who doesn't understand, is another question 
entirely...


________________________________
From: Eric Rescorla <[email protected]>
Sent: Thursday, June 19, 2025 8:45 AM
To: Yaroslav Rosomakho <[email protected]>
Cc: TLS List <[email protected]>
Subject: [TLS] Re: [External⚠️] Re: [EXT] Re: [EXTERNAL] Re: Dual certificates 
in TLS proposal



On Thu, Jun 19, 2025 at 1:52 AM Yaroslav Rosomakho 
<[email protected]<mailto:[email protected]>> wrote:

S 5.1.1.
   When parsing DualSignatureSchemeList, implementations MUST NOT make
   assumptions about which sub-list a given algorithm will appear in.
   For example, an implementation MUST NOT assume that PQ algorithms
   will appear in the first list and PQ in the second.  As a test, if a
   TLS handshake containing a DualSignatureSchemeList succeeds, then an
   equivalent TLS handshake containing an equivalent
   DualSignatureSchemeList but with the first and second lists swapped
   MUST also succeed.  However, it is not required that these two test
   cases result in the same selected signature algorithm and
   certificate.  See Appendix C for a suggested configuration mechanism
   for selecting a preferred pair of algorithms.

Would it be legal to supply two lists that have the same
PQ-status? E.g.,

   first_signature_algorithms = [ECDSA-P256]
   second_signature_algorithms = [Ed25519]


Yes, the same PQ-status of elements in both lists is legal according to current 
design. Some may want to allow SLH-DSA or composites roots/intermediates in 
both chains.

Now I'm confused. Are you saying you can have the *same values* in both lists. 
E.g.,

first_signature_algorithms = [ML-DSA, SLH-DSA]
second_signature_algorithms = [ECDSA-P256, ML-DSA]

But then you can't sign with [ML-DSA, ML-DSA]?

-Ekr
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to