Added missing codecs for the private key counterparts to a number of public key codecs.

[vdods]

In particular, added:

• ed448-priv
• x448-priv
• mlkem-512-priv
• mlkem-768-priv
• mlkem-1024-priv
• jwk_jcs-priv

This is meant to address #389

[vmx]

What is your use case for the private keys?

Background: we try to add to the table only things that people actually use, so that we don't bloat it too much. There is also a discussion about private keys at e.g. #194. Making it harder for private keys to be shared, maybe makes it less likely that they accidentally leak. I think that's one of the reasons, why most of the keys currently don't have the -priv equivalent.

[vdods]

The case for adding, from my perspective, is:

• I want a compact and interoperable format for identifying private key types, ideally using the same code that provides that functionality for hashes, public key types, etc.
• The readme of this repository states that one of the tag categories is "key: Cryptographic key types, including public and private keys for various cryptographic algorithms."
• It seems quite incomplete to leave out codecs for the private half of a keypair, especially given there are already private key codecs in the table.

Regarding the discussion in #194, multicodec really only posits an agreed-upon tagging of data types. The concerns in #194 regarding potential danger were only expressed by Manu (see #194 (comment)), who is an editor and author of the Controlled Identifiers W3C recommendation, which gives specifics for encoding private keys using multicodec (see https://www.w3.org/TR/cid-1.0/#Multikey), which IMO is a pretty clear endorsement of the idea.

[rvagg]

It seems quite incomplete

Back to the original point @vmx is making - we don't just add things in here for completeness or else it'll be an unmaintainable, massive index of things. For instance, we've had requests to add basically all known mime types to the table, just for the sake of completeness. So we like to at least have some plausibility that there's a use-case connected to the additions and that they're not just to satisfy someone's desire for it to feel more complete than what it is.

tbh this still sounds to me like you'd like to satisfy a feeling of symmetry in the table rather than having a concrete proposal for use. But you're welcome to outline more of a case for utility.

[vdods]

Agreed that adding things indiscriminately, or even without a well-scoped definition of "completeness" would bloat things unacceptably. The request to add all known mime types is indeed unreasonable, especially because mime types are themselves a standardized representation :-D

What I meant by "incomplete" was only intended to address the public key codecs that didn't have a corresponding private key codec, which in this case is 6 codecs.

My use case is a DID method implementation (see github.com/LedgerDomain/did-webplus) that needs to support various key types in "verification methods", including in "publicKeyMultibase" format (see CID link above), and have a compact, consistent, and well-known format for representing the private keys in the user's wallet (in the parlance of CIDs linked above, "secretKeyMultibase"). I could certainly just make up a format, but I'd rather not.

In particular, I most care about ed448-priv existing, and medium-care about the mlkem codecs (post-quantum cryptography), and I don't care about jwk_jcs-priv, but I added it to the PR for completeness.

[vmx]

@vdods thanks for explaining your use case. As we already have codec codes for secret keys, I see the point of adding those, so that folks like you don't have to make up something.

I don't have a strong opinion on whether jwk_jcs-priv should be added.

I approve this PR, but I want to wait for @rvagg opinions before merging.

[vdods]

Thanks, I appreciate it!

[rvagg]

no objection from me