Add ML-DSA-44, SHAKE256 algorithm identifiers

[Hayden-IO]

From discussions with cryptographers, the general consensus is ML-DSA-44 is sufficient for PQC signing, with smaller keys and signatures. ML-DSA-65 and ML-DSA-87 will be primarily for specialized use cases, e.g. gov't requirements.
Additionally, the witness network is likely to use ML-DSA-44.

Added the SHAKE256 hash algorithm identifier, though I'm not certain it's actually needed because we'll only support the pure variant of ML-DSA.

Updated the comment for LMS/LMS-OTS to state it should not be used at all, as there are no clients that will support this.

Summary

Release Note

Documentation

[kommendorkapten]

This looks good, would you also update https://github.com/sigstore/architecture-docs/blob/main/algorithm-registry.md

Re: SHAKE-256, How do you feel about not adding that now. Reading FIPS 204 $5.4, hash algorithms specified by FIPS 180-4 with sufficient output size (e.g. SHA2-256) is allowed, so maybe punt on adding SHAKE-256 until we need it? We already have a lot of algorithms listed (for ML-DSA lambda is 128 bits).

From FIPS 204 $5.4:

In order to maintain the same level of security strength when the content is hashed at the application level
or using HashML-DSA , the digest that is signed needs to be generated using an approved hash function
or XOF (e.g., from FIPS 180 [8] or FIPS 202 [7])

But also, if we can work towards always hashing on the application layer (e.g. use in-toto) there is no need for the pre-hash version, and we can stick with pure only. E.g. newer cosign only signs an in-toto statement for OCI images. We could do the same for blobs and so only sign the in-toto statement referencing the blob.

[Hayden-IO]

Thanks for the feedback! I'm happy to remove SHAKE256 - I didn't have a clear use case in mind, and to be honest we'll probably have to rethink the message digest field assuming we eventually migrate entirely over to ML-DSA since hashing is internal to the algorithm.

[Hayden-IO]

sigstore/architecture-docs#61 for the registry update

[kommendorkapten]

Thanks!

[steiza]

I think we're doing a good job balancing experiments with forward progress here.