I believe we are addressing two different (valid) questions:
* You are talking about "what does the draft say"? * I am addressing "what should the draft say"? The draft is, after all, just a draft, and obviously the WG can make changes to it. I am suggestion a potential change (not that I did anything like propose actual text or anything, but still). If the WG agrees with the suggestion, that's fine. If the WG doesn't agree (and yes, I do see some foot-cannon potential there), that's fine too. ________________________________ From: Eric Rescorla <[email protected]> Sent: Thursday, June 19, 2025 11:35 AM To: Scott Fluhrer (sfluhrer) <[email protected]> Cc: Yaroslav Rosomakho <[email protected]>; TLS List <[email protected]> Subject: Re: [TLS] Re: [External⚠️] Re: [EXT] Re: [EXTERNAL] Re: Dual certificates in TLS proposal On Thu, Jun 19, 2025 at 6:03 AM Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>> wrote: 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). I don't think this proposal says that according to this draft, because you have to provide two signatures and they can't be the same algorithm As I understand that, the way you spell that in this proposal is to list: signature_algorithms = [SLH-DSA] dual_signature_algorithms =. { first_signature_algorithm = [ECDSA-P256], second_signature_algorithm = [SLH-DSA, ML-DSA], } -Ekr 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]<mailto:[email protected]>> Sent: Thursday, June 19, 2025 8:45 AM To: Yaroslav Rosomakho <[email protected]<mailto:[email protected]>> Cc: TLS List <[email protected]<mailto:[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]
