Enable ML-DSA verification by default

[jku]

ML-DSA is now supported in code but it is not enabled by default for verification.

The question is do we want to wait until TAP 21 moves on from "draft" status or do we accept that this might not happen until it is being used (and should just enable ML-DSA now instead)?

[aparcar]

Hi @jku thanks for your work on ML-DSA. I'm following this from the in-toto perspective and found that TAB-21 specififies a hard coded "tuf" as domain separator. This is now part of sslib while the library is also used by in-toto.

Do you have a recommendation on how to deal with this?

• It could be ignored and just be used by in-toto, however that would defeat the domain separator idea (right?)
• Modify sslib to accept custom domain separators here

[jku]

Good question. I'll mention that I'm not a cryptographer right at the start...

It could be ignored and just be used by in-toto, however that would defeat the domain separator idea (right?)

To an extent it goes against domain separation... but I would guess sharing the domain here is not a fatal issue: the idea IIUC is to make sure that most ML-DSA signatures are not in same "hash domain", tuf and in-toto sharing a domain seems to still fit that idea comfortably. If securesystemslib was a more generic signing system (used in many other areas), then this could indeed be an issue we had to solve.

Modify sslib to accept custom domain separators

Just to throw ideas out there, securesystemslib (or in-toto) could also define a completely new key scheme (that is actually exactly the same as the existing one but the domain prefix changes). However...

I would definitely start with the shared domain idea (and maybe verify with a friendly neighborhood cryptographer if this is reasonable). Getting different ecosystems to support even "ml-dsa-44/1" as it's defined is a project, getting them to support more complicated setups sounds challenging

[jku]

Current status:

• securesystemslib 1.5.0 contains ML-DSA support
• ML-DSA is not part of default verifier set, it needs to enabled manually:
  KEY_FOR_TYPE_AND_SCHEME[("ml-dsa", "ml-dsa-44/1")] = SSlibKey
• TAP 21 is in draft status but merged
• other implementations:
  • go-tuf is WIP: Add support for ML-DSA (TAP 21) theupdateframework/go-tuf#758
  • sigstore-rust already has ML-DSA support in sigstore-tuf crate

After we have multiple compatible implementations, I believe we can (in whatever order)

• Get TAP21 to some "non-draft" state
• Enable ML-DSA by default in securesystemslib