它公开确认证书确实已颁发（而不仅仅是预证书）

引用 RFC6962bis ( draft-ietf-trans-rfc6962-bis-28 )，第 3.2 节：

"signature" MUST be from the same (root or intermediate) CA that will ultimately issue the certificate. This signature indicates the CA's intent to issue the certificate. This intent is considered binding (i.e., misissuance of the precertificate is considered equivalent to misissuance of the corresponding certificate).

从本质上讲，这意味着如果 CT 日志中存在预认证，那么在与证书透明度相关的任何意义上，最终证书确实已颁发。

进一步的操作细节（例如，当时是否颁发了证书，是否已颁发的证书随后发送给客户，客户是否收到了证书，他们是否部署了证书等）超出了证书透明度框架的范围。

（我相信，如果证书已实际颁发，并且不仅已颁发，而且已由证书颁发机构的客户实际获得，那么客户 — 通常称为“服务器运营商”） CT 相关文件——如果他们有这样的政策，可以自己提交最终证书。）

因此，没有任何优势。但是，您提到的缺点仍然存在。因此，最终分数是 0:1 反对提交最终证书。

经过更多思考，我的结论是：

缺点：

• 它是 ct-log 大小的两倍

好处：

• 它公开确认证书确实已颁发（而不仅仅是预证书）
• 它可以防止大量提交到 ct-logs，这可能会导致合并延迟（日志取消资格的原因）证书透明度日志策略
• 它允许捕获发布错误（例如错误的 SCT 编码）任务完成了吗？DigiNotar 之后的 HTTPS 安全性
• 请求吊销可能会有所帮助（如果您收到警报，因为 ct-log 有您没有请求的预证书，吊销真正的证书更容易获得它）如何吊销我没有颁发的证书

由于唯一的缺点是日志操作员，并且很大程度上通过防止大规模提交来弥补，因此两个证书的日志记录应该是最佳实践。

让我们加密讨论：不记录最终证书