Csdrhrt

There is a specification, in Informational(!) RFC 6091, for using PGP keys in TLS authentication, although I don’t think it has ever been implemented outside of GnuTLS (it’s certainly not in OpenSSL).

Yet the TLS 1.3 RFC 8446 §4.4.2 goes as far as to specifically prohibit this obscure extension with a must not. Normally an IETF document would use a should not to recommend against something that’s not fundamentally broken, but still a bad idea in most cases; and RFC 6091 doesn’t seem broken—it just provokes pointless bloat (given the current state of client support and PGP deployment).

What’s the point of such strong language?

It seems that PGP certificates have the problem that they can be changed by the user. Furthermore, there were extensions for 1.2 that are incompatible for 1.3 (if they were secure in the first place):

I found this on the TLS mailing list from Ilari Liusvaara:

Ugh, the situation is way worse than what I thought.

Basically, all three assume they have full control of certificate
message, worst of all being OpenPGP, which modifies it in more complex
ways (it isn't a pure element or list anymore).

And even with RPK, which appiles least severe modifications, still
modifies the structure in ways that are not obvious in implications
w.r.t. TLS 1.3.

Oh, and turns out I had implemented RPK in TLS 1.2 wrong by assuming
that it doesn't actually modify the certificate message format. Which
turned out to be wrong assumption (I fixed this after discovering the
format changes).

And then certificate types don't currently work sanely for client
certs, even if you knew how those map to Certificate message.

Client_certificate_type and server_certificate type aren't the only
problematic extensions w.r.t. TLS 1.3. The table of extensions has the
following too (all marked as allowed, I added short reason I think
those are problematic):

• client_certificate_url: Replaces certificate message. Hardcodes SHA-1 (which is now provably broken).


• user_mapping: Has extra handshake message.


• cert_type: All the problems of CCertT and SCertT, combined with fixing both to be the same.

With user_mapping, applying similar trick as in status_request is not
completely trivial because extensions that are answered in client
Certificate are offered in CertificateRequest. Okay, except that
extension is not an answer to ClientHello extensions, and the
extension assumes offer-answer relationship between client and server
extensions. Might need some special-casing.

...

Source: https://www.ietf.org/mail-archive/web/tls/current/msg22576.html

In other messages in the thread they talk about disabling OpenPGP until somebody comes up with an extension in a separate RFC. So it doesn't seem to be malice, just a whole bunch of compatibility reasons. In other words: as it is now it looks very broken - until somebody manages to fix it.

As well as the purely mechanical elements Maarten's excellent answer talks about (how should we send these certificates in the new data structures) there's also a change in TLS 1.3 that is relevant to OpenPGP too.

In prior TLS versions it was possible (and common) to negotiate a key exchange method in which the "master secret" used to create session keys is sent, encrypted, from client to server. This looks a lot like PGP's encrypted mail messages, a simple hybrid system in which bulk data is symmetrically encrypted and then only the symmetric key is encrypted using public key cryptography. This means that server authentication happens implicitly because only the authentic server could decrypt the message.

In TLS 1.3 only DH key exchange is permitted. Ephemeral symmetric keys will be chosen by the participants at random and used to encrypt a connection immediately. Authentication always happens explicitly, over this encrypted channel. After showing a certificate (now over an encrypted channel unlike TLS 1.2 and earlier) the peer signs a transcript of the steps so far, thus proving that they have the private key corresponding to the certificate AND they witnessed the exact same setup as you.

So this changes the key usage from encryption to signature which is pretty significant. Certainly worthy of completely fresh consideration from anyone who wants (for some reason) to do TLS with OpenPGP keys and certificates.