Let’s Kerberos

（我认为这值得深思，但不必太过严肃——无需恐慌。）

后量子签名的规模是否让您感到沮丧？是否对部署后量子Web PKI感到绝望？别担心！对称密码学也是后量子的！

当您连接到某个站点时，同时从DNS获取包含若干“CA”记录的记录。每条记录包含：

“CA-key”是仅CA知晓的对称密钥，“server-CA-key”是服务器和CA知晓的对称密钥。

客户端找到三条UUID与受信任CA匹配的CA记录，随后向每个CA发送包含以下内容的消息：

CA可以解密“client-CA-key”，然后使用AAD（要么是客户端指定的主机名，要么是将第一个标签替换为*的通配符记录）解密“server-CA-key”。

CA回复Eserver-CA-key(client-server-key)，即客户端选择的密钥，使用服务器密钥加密。客户端随后可以启动与服务器的TLS连接，向其发送三个加密的客户端-服务器密钥，客户端和服务器可以使用三个串联的共享密钥对Kyber密钥协商进行认证。

要使此方案正常工作，客户端和服务器都需要与每个CA建立对称密钥。为此，它们需要建立到CA的公钥认证连接。这些连接将需要大型后量子签名，但该成本可以通过客户端和服务器之间的多次连接分摊。（服务器必须通过标准挑战以证明其能够合法代表给定主机名。）

关键要点

CA能够看到客户端与哪些服务器通信，类似于过去的OCSP服务器。需要技术和策略控制来防止该信息被滥用，例如CA至少在SEV/TDX环境中运行经审计的代码。
需要攻破至少三个CA才能达成任何攻击。虽然我们现在有证书透明度，但那是事后审计机制，在当前WebPKI中单次CA泄露仍是问题。
可以要求CA发布其识别的每个主机名的服务器密钥ID日志。它们可能选择不记录某条记录，但需要三个CA同时作恶才能破坏系统。
联系CA会带来额外延迟，但或许可以与服务器进行Kyber交换重叠执行。客户端可以暂时缓存和重用客户端-服务器密钥。
CA可以每天生成新密钥。旧密钥可以继续工作几天。服务器每天与CA更新共享密钥（这里非常假定使用类似ACME的自动化）。
然而，各方用于建立共享密钥的公钥是非常长期的，就像现在的根证书一样。
在此模型中不信任CA不必像现在这样复杂：要求站点设置至少五个受信任CA，以便可以在不影响的情况下不信任任何CA。这类似于不信任证书透明度日志。
CA的撤销很容易且可以立即生效。
CA应具有高可用性，但系统可以通过使用其他CA来处理某个CA不可用的情况。CA处理的高可用部分被设计为几乎无状态，因此应该能够很好地扩展，并使用任播地址实现合理鲁棒性。