This feels like a good thing - tying keys up in X.509 certificates feels like it makes them more complicated to deal with than they should be. On the other hand, now we're back to needing to have some kind of context around the key to indicate what it is. Are we to the point yet that a group with clout can just go write "the standard" representation for the common sets of these things that we can all use, and then deprecate the mess of other options? And can it be done without having to pull a dependency on an ASN.1 parser, or protocol buffers, or some other heavy library? Maybe just a set of algorithm names (text for text representation, an enumeration for binary), and a key use tag? Then each algorithm standard specifies it's own format for a blob of bytes that developers not doing serialization don't have to worry about? Like:
Then as a developer passing blobs around, I don't need to care that es256 is encoded X962 uncompressed point, but I do care that I see an x25519 secret/private key sitting around. Or I can throw a shoe if someone passes a signature key to a module trying to do a key exchange. As it is, SSH has its way, JWT/JWS does its thing, COSE has it's own special flavors, Tink does its own (rather nice) things but wants to me know how protocol buffers look...
And while they're at it, setting a single, standard, simple way to throw a hash around that for consistent key identifiers would be amazing. Also I'd like a pony.
Except the parent post explicitly only cares about the type of key, which you don't need to parse the ASN.1 to know.
> a key use tag? Then each algorithm standard specifies it's own format for a blob of bytes that developers not doing serialization don't have to worry about?
As a developer passing blobs around, you already don't need to care that they're ASN.1, but you can care that you see a private key sitting around.
PS: and more than just X.509 uses those style of headers, too...
> As the adoption of Raw Public Keys continues to grow, it’s essential for
> developers, network administrators, and security experts to understand and
> implement them effectively, keeping in mind the security and privacy implications.
Totally agree. That would be a great document to link right here.
I don't know a lot about this, but have recently being using PGP in an application. I asked GPT4 to compare
> Raw Public Keys, as specified in RFC 7250, allow for the exchange of public keys directly within the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols, bypassing the need for certificates 1 . In contrast, in a PGP (Pretty Good Privacy) architecture, public keys are often hosted on key servers or distributed through other means. The hosting of public keys facilitates their discovery and distribution to other users, which is essential for the operation of the PGP system. This hosted approach in PGP contrasts with the direct exchange of raw public keys in TLS/DTLS as outlined in RFC 7250.
> Raw Public Keys, trust is often established through out-of-band mechanisms or prior arrangements, since there's no certificate to provide a chain of trust. In PGP, trust is commonly established through a "Web of Trust" where users validate each other's keys based on personal trust relationships, or through certificate authorities in a more centralized trust model. Both systems require a way to ensure the authenticity and integrity of the public keys to prevent man-in-the-middle attacks or other forms of security compromises.
And while they're at it, setting a single, standard, simple way to throw a hash around that for consistent key identifiers would be amazing. Also I'd like a pony.