docs: pkix

[dozyio]

Thinking we should probably have libp2p defined algorithms for interop, but also allow PKIX for experimentation

[dennis-tra]

Thanks @dozyio, I think this is a thoughtful PKIX direction.

Following up on the concern I raised over in #711 that with a PKIX key type the same RSA key could be encoded two ways, once under the existing RSA type and once under PKIX, and end up with two different PeerIDs. The "MUST use the existing libp2p-specific encoding" language addresses exactly that, so that one's resolved for me. Thanks!

There's a related thing I've been turning over that I want to bring up, even if it might be a bit orthogonal. With a generic container, PeerID determinism leans on the DER encoding coming out identical across implementations. DER is canonical for a given ASN.1 value, but the algorithm profiles underneath can still leave room. RFC 5480, for instance, permits both compressed and uncompressed EC points for the same key, so "follow the RFC" alone doesn't necessarily pin a single encoding. We've actually navigated this already because ECDSA and RSA has been hashing DER PKIX into PeerIDs for years without trouble. And for ML-DSA specifically, RFC 9881 leaves essentially no ambiguity, so I don't think we'd run into issues there. Where it could bite is the open-ended part of a generic container where some future algorithm whose SPKI profile isn't as tight has two conformant encoders producing different bytes for the same key.

This makes me wonder about the overall shape. We could go with the generic container and accept that every algorithm needs a profile pinning its encoding plus test vectors which is this PR's direction, and it pays off most I think if we expect to add several algorithms without touching the protobuf each time (but we'd still need to pin profiles and I would question that there will be extraordinarily many new keys we want to support). The permissionless extension angle is also weakened if we still need to pin profiles.

Alternatively we could give the algorithm we actually want to support at the moment (ML-DSA) its own key type with Data spec'd as the RFC 9881 SPKI. Since we need a profile and test vectors either way, a dedicated type doesn't cost much beyond an enum value.

There's also Marco's earlier idea of keeping PKIX out of the protobuf and deriving the PeerID from a separate pkix-hash multicodec. I also inherits the "future algorithm whose SPKI profile isn't as tight" concern but could be accompanied with a similar profile pinning as in this PR.

Anyways, just my thoughts above. Curious to hear others. Generally, I'm much more comfortable with the direction overall. Mostly I'd like us to choose deliberately between the generic container and a dedicated type. The IETF Standards reuse is the part I'd care most about, and I think all preserve that.