feat: add self-describing key container codecs (pkix,pkcs8,cose-key)

[lidel]

Summary

Adds a family of self-describing key container codecs in one motion. Each wraps an IETF-standard container whose payload carries its own algorithm identifier, so one codec covers every algorithm the container
can carry.

name	code	format	spec
pkix-pub	0x40	DER-encoded ASN.1 SubjectPublicKeyInfo (SPKI)	RFC 5280 §4.1.2.7
pkcs8-priv	0x41	DER-encoded ASN.1 OneAsymmetricKey (PKCS#8)	RFC 5958 §2
cose-key	0x42	CBOR-encoded COSE_Key map (application/cose-key)	RFC 9052 §7
cose-key-set	0x43	CBOR-encoded COSE_KeySet array (application/cose-key-set)	RFC 9052 §7

The algorithm is self-identified by the payload: AlgorithmIdentifier OID for the DER containers, kty/alg/crv for COSE.

Motivation

The main goal is to make these codecs usable for libp2p peer IDs and IPNS records, so the set of supported key types in those systems stops being gated by multicodec assignments.

Today, adopting a new key type in libp2p or IPNS requires minting a per-algorithm multicodec entry first. That turns the multicodec table into a bottleneck: every new algorithm (ML-DSA, SLH-DSA, any future PQ
scheme, niche curves) has to land a bespoke entry before applications can use it, and everyone has to agree on that entry before implementations can ship.

These four containers break that coupling. Because the algorithm identifier lives inside the payload, a single codec covers every algorithm the container can carry. The moment an IETF/RFC encoding exists for a
new key type (for example RFC 9881 for ML-DSA in SPKI/PKCS#8, or a COSE_Key kty/alg registration), it is immediately usable as a libp2p or IPNS key without
waiting on a multicodec update.

Concretely:

• Less vendor lock-in for libp2p and IPNS. Peer IDs and IPNS names are no longer limited to the algorithms that happen to have per-algorithm multicodec entries. Any SPKI-encodable public key can be supported by willing implementations through
  pkix-pub; any PKCS#8-encodable private key may be supported through pkcs8-priv; CBOR-native stacks get the same path via cose-key/cose-key-set.
• Faster new-algorithm rollout. The ecosystem can adopt new key types as soon as an RFC/IETF standard exists for them, no new multicodec entry required.
• Library reuse. SPKI and PKCS#8 are parsed natively by OpenSSL, BoringSSL, Go crypto/x509, rustls, Java JCE, WebCrypto, and every other mainstream crypto stack. COSE_Key is already the key format
  used by WebAuthn/passkeys, CWT, EAT, and constrained-device stacks.

Related:

• Add support for PKIX and PKCS#8 keys libp2p/specs#711 proposes using PKIX as PeerID key formats, which motivated this registration.
• Post-quantum key support in Kubo ipfs/kubo#11281 tracks long term needs

Code placement

All four codes are single-byte varints (< 0x80). Existing users of libp2p-key (at 0x72, one byte on the wire) encode the codec prefix into every peer ID and IPNS name. Placing the replacements at two-byte codes would mean every migrated identifier pays an extra byte forever.

Specifically, 0x40-0x43 sit in the unclustered 0x39-0x4f free block, avoiding the ipld/CID-codec neighborhood at 0x70-0x7f where a key-tagged entry would not fit the surrounding tags.

Why cose-key and cose-key-set are separate codecs

COSE_Key is a CBOR map; COSE_KeySet is a CBOR array. IETF registers them as separate IANA media types (application/cose-key vs application/cose-key-set) and separate CoAP Content-Format IDs (101 vs 102) in RFC 9052 §11.3.

[vmx]

Before having a closer look: do they need to be in the 1 byte range, or can then be > 0x80? Getting them into the 2 bytes range is much easier as it needs a less thorough review.

[MarcoPolo]

1 byte range would be ideal, as that lowers the overhead to bridging to other standards. 2 bytes wouldn't be a blocker of course, but if this isn't worth a 1 byte codepoint, I'm not sure what would is.