在Informational（！）RFC 6091中，有一个用于在TLS身份验证中使用PGP密钥的规范，尽管我认为它从未在GnuTLS之外实现（肯定不是在OpenSSL中实现）。

但是TLS 1.3 RFC 8446§4.4.2甚至明确地禁止使用no禁止这种晦涩的扩展。通常情况下，IETF文件会使用，不建议从根本上未破坏但在大多数情况下还是个坏主意的东西。和RFC 6091似乎没有被破坏—只是激起了毫无意义的膨胀（鉴于客户端支持和PGP部署的当前状态）。

如此强大的语言的意义何在？

#1 楼

PGP证书似乎存在可由用户更改的问题。此外，还有1.2的扩展名与1.3的扩展名不兼容（如果它们首先是安全的）：

我在Ilari Liusvaara的TLS邮件列表中找到了此扩展名：


糟糕，情况比我想象的要糟糕得多。

基本上，所有三个人都假定他们拥有对证书消息的完全控制权，最糟糕的是OpenPGP，它修改了它以更复杂的方式
（它不再是一个纯粹的元素或列表）。

即使使用RPK，它进行了最不严重的修改，仍然
修改了结构暗示中不明显的方式
wrt TLS 1.3。

哦，事实证明我在TLS 1.2中实现了RPK是错误的，假设
它实际上并没有修改证书消息格式。哪个
证明是错误的假设（我发现
格式更改后解决了这个问题）。

然后证书类型当前不适用于客户端
证书，即使您知道这些证书如何映射到“证书”消息也是如此。

Client_certificate_type和server_certificate类型不是唯一的问题扩展wrt TLS 1.3。扩展名表也有
（全部标记为允许，我添加了简短的理由，我认为这些是有问题的）：


client_certificate_url：替换证书消息。硬编码SHA-1（现已证明已损坏）。
user_mapping：具有额外的握手消息。
cert_type：CCertT和SCertT的所有问题，以及将它们修复为相同的问题。

使用user_mapping时，应用与status_request中类似的技巧并不是完全简单的
，因为在Client
中回答的扩展名在CertificateRequest中提供。好的，除了
扩展不是ClientHello扩展的答案，而
扩展程序假设客户端和服务器扩展程序之间的报价-答案关系。可能需要一些特殊包装。

...


来源：https://www.ietf.org/mail-archive/web/tls/ current / msg22576.html

在线程中的其他消息中，他们谈论禁用OpenPGP，直到有人提出单独的RFC中的扩展名为止。因此，这似乎不是恶意的，只是出于兼容性方面的考虑。换句话说：就目前而言，它看起来很破损-直到有人设法修复它。

评论

$ \ begingroup $
很好地追踪了原始原因！ TLS 1.3确实试图清除协议中尽可能多的内容（暗角可能掩盖令人讨厌的意外），所以我对它们放弃OpenPGP证书的扩展并不感到惊讶。
$ \ endgroup $
– Kiwidrew
18年11月14日在8:21
$ \ begingroup $
@Maarten我在这里有点措辞不清-让我们看看是否正确理解这点：TLS 1.3声明了身份验证数据的通用格式（它们称为证书，但实际上是X.509证书的列表） ，但RFC 6091会覆盖证书批发，因此即使其安全性很强，它也会在TLS 1.3协议中被破坏。
$ \ endgroup $
– Alex Shpilkin
18年11月14日在12:45
$ \ begingroup $
@kiwidrew这并不令人惊讶：在主要规范之外的信息RFC首先要尽可能地获得IETF的官方认可。令人惊讶的部分是新的主要规格中一定不能存在。但是，如果它更改了有线格式的一部分，则TLS 1.3设计人员希望看到冻结状态，这将对此做出解释。
$ \ endgroup $
– Alex Shpilkin
18年11月14日在12:48
$ \ begingroup $
在我的答案中，似乎在邮件消息下方有一个要更改的消息或记录列表（由...表示）。但是，对于这种情况，我尚不完全清楚，需要进行多少更改。您可以随意查看（该消息是线程的一部分，但是我认为此消息很好地总结了一下）。
$ \ endgroup $
–马腾·博德威斯♦
18-11-14在14:36


$ \ begingroup $
@Demi我想是的。毕竟，客户端身份验证所需的唯一条件就是对公钥和签名的信任。我认为客户端身份验证是最有用的，因为PGP主要用于为个人提供隐私。因此，我认为客户端身份验证比服务器身份验证更重要。服务器验证可能很难添加，因为还有验证服务器名称，吊销等问题。
$ \ endgroup $
–马腾·博德威斯♦
18-11-22在14:59


#2 楼

除了纯粹的机械元素，Maarten的出色回答（我们应该如何在新的数据结构中发送这些证书）还涉及与OpenPGP也相关的TLS 1.3的更改。

在以前的TLS中可能的（通常的）版本可以协商一种密钥交换方法，在该方法中，用于创建会话密钥的“主密钥”从客户端发送到服务器进行加密。这看起来很像PGP的加密邮件消息，这是一个简单的混合系统，其中对批量数据进行对称加密，然后使用公共密钥加密技术仅对对称密钥进行加密。这意味着服务器身份验证是隐式发生的，因为只有可靠的服务器才能解密消息。

在TLS 1.3中，仅允许DH密钥交换。临时对称密钥将由参与者随机选择，并立即用于加密连接。身份验证始终在此加密通道上显式进行。在显示证书（与TLS 1.2和更早版本不同，现在通过加密通道显示）后，对等方签署了到目前为止的步骤记录，从而证明他们具有与证书相对应的私钥，并且见证了与您完全相同的设置。 br />
因此，这将密钥使用从加密更改为签名，这非常重要。肯定（出于某种原因）想要使用OpenPGP密钥和证书进行TLS的任何人都应该进行全新的考虑。

评论

$ \ begingroup $
当然可以，但是使用PGP私钥对数据进行签名当然是可能的。因此，尽管这当然是一个额外的障碍，但它不应阻止PGP的使用（但我想您也可以说所有其他问题）。
$ \ endgroup $
–马腾·博德威斯♦
18年11月14日在15:08