On Thu, Jun 19, 2025 at 6:03 AM Scott Fluhrer (sfluhrer) <[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]>
> *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]>
> 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]
