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 <e...@rtfm.com> Sent: Thursday, June 19, 2025 11:35 AM To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> Cc: Yaroslav Rosomakho <yrosoma...@zscaler.com>; TLS List <tls@ietf.org> 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) <sfluh...@cisco.com<mailto:sfluh...@cisco.com>> 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 <e...@rtfm.com<mailto:e...@rtfm.com>> Sent: Thursday, June 19, 2025 8:45 AM To: Yaroslav Rosomakho <yrosoma...@zscaler.com<mailto:yrosoma...@zscaler.com>> Cc: TLS List <tls@ietf.org<mailto:tls@ietf.org>> 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 <yrosoma...@zscaler.com<mailto:yrosoma...@zscaler.com>> 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 -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
