Why did TLS 1.3 prohibit PGP authentication? 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.