Update table.csv

[vanderbr]

Add ML-DSA public key multicodecs (FIPS 204)

[vmx]

Why the gap and not directly after the ML-KEM keys starting with 0x120e?

[vanderbr]

Because ML-KEM and ML-DSA are different post-quantum algorithms. ML-KEM (Kyber) is for key-establishment, while ML-DSA (Dilithium) is for digital signatures. NIST assigns them separate key types, so ML-DSA keys are not the same as ML-KEM key types. See https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.204.pdf vs https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf. They are separate and multicodec should support both . NIST has finalized ML-DSA as the standard signature scheme for post-quantum use, so any multicodec ecosystem that intends to support standardized PQ keys will eventually need an ML-DSA code point. ML-KEM and ML-DSA keys are not interchangeable, and tooling that already supports ML-KEM will not be able to represent ML-DSA keys without a separate identifier. This mirrors how multicodec already distinguishes classical algorithms (RSA, Ed25519, ECDSA, etc.).

[vanderbr]

Sorry, I didn't answer you question directly about why the gap .... since ML-DSA is a different primitive than ML-KEM (signatures vs. key-establishment), giving it its own small block avoids collisions with future ML-KEM variants and keeps room for additional ML-DSA key types if NIST expands the line. Leaving the gap preserves forward-compatibility and follows existing multicodec practice where unrelated primitives are not forced to be sequential.

[rvagg]

fine by me, but @vanderbr note that we have mlkem-*-priv entries too, you might want to consider whether we should also have mldsa-*-priv block as well, happy to entertain that in a follow-up PR if you want it