Support "External Mu" ML-DSA

[WillChilds-Klein]

Issue #, if available: i/ACCP-128

Description of changes:

Overview

This PR adds support for the External Mu variant of ML-DSA described in AWS-LC PR 2113. To facilitate calculation of mu in testing and for consumers, we expose a computeMLDSAMu helper function in a new PublicUtils class. Notably, External Mu ML-DSA is interoperable with Pure ML-DSA across signing and verification, as shown in tests.

Interoperability

We expose External Mu as a distinct Signature service to preserve forwards-compatibility with other providers' potential future implementations. Conventionally, this "prehash" mode would be configured with a call to setParameter, passing an AlgorithmParameterSpec implementation as in EdDSA. Because no other providers have yet created an AlgorithmParameterSpec implementation that is aware of External Mu, this approach would have required us to expose an ACCP-specific AlgorithmParameterSpec that callers would need to use, hampering interoperability.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[WillChilds-Klein]

There's currently no JCA-standard name for this (yet?), so we have some latitude in choosing the algorithm name. I'm not sold on ML-DSA-Ext-Mu, open to suggestions from reviewers.

[jakemas]

In draft-ietf-lamps-dilithium-certificates we use ExternalMu-ML-DSA. In ACVP ML-DSA JSON Specification it is just referred to as externalmu.

Notably, theres no hyphen between external and mu in both.

We chose ExternalMu-ML-DSA in the IETF to hint at consistency with NISTs notion of prefixing the mode name distinction: i.e.,HashML-DSA.

As such ML-DSA-ExtMu, ML-DSA-ExternalMu are good options. If you like ML-DSA-Ext-Mu, ML-DSA-External-Mu with the extra hyphen, that's also fine!

[geedo0]

Is the intent here to begin developing/exposing ACCP exclusive utility classes? The only use is within test code. Is there an intended customer for this interface (let's continue this convo off of Github)? I am a little concerned about how specific this is to ML-DSA and how we might pigeon-hole ourselves with this class/package hierarchy if we decide to add a lot more utility functions in the future. The potential for a 1000+ line monster class is here.

[WillChilds-Klein]

There has been some interest from internal teams to use this in testing, but we can hold off on exposing it until there's a clearly articulated need. I've moved the mu helper function to TestUtil.