1. Informal Introduction (非正式引言)

1. Informal Introduction (非正式引言)

证书透明度 (Certificate Transparency, CT) 旨在通过提供可公开审计的, 仅追加的, 不受信任的已签发证书日志, 来缓解错误签发证书的问题. 日志可公开审计, 因此任何人都可以验证每个日志的正确性, 并监视何时向其中添加新证书. 日志本身并不能阻止错误签发, 但它们确保相关方 (尤其是证书中指名的各方) 能够发现此类错误签发. 注意这是一种通用机制, 但在本文档中, 我们只描述其用于由公共证书颁发机构 (certificate authority, CA) 签发的公共 TLS 服务器证书的用途.

每个日志由证书链组成, 任何人都可以提交. 预期公共 CA 会将其新签发的所有证书贡献给一个或多个日志; 也预期证书持有者会贡献自己的证书链. 为避免日志被垃圾信息淹没至无法使用, 要求每条链都必须锚定在已知的 CA 根证书上. 当某条链被提交到日志时, 会返回一个签名时间戳, 之后可用于向客户端证明该链已被提交. 因此 TLS 客户端可以要求其所见的所有证书均已被记录.

关心错误签发问题的一方可以监视日志, 定期向其请求所有新条目, 从而检查其负责的域名是否出现了未预期的证书签发. 他们如何处理这些信息, 尤其是当发现已发生错误签发时, 已超出本文档范围; 但总体而言, 他们可以调用现有的业务机制来处理错误签发的证书. 当然, 任何愿意的人都可以监视日志, 并在认为某证书被错误签发时按其认为合适的方式采取行动.

同样, 见过来自特定日志的签名时间戳的一方, 之后可以要求该日志提供包含性证明 (proof of inclusion). 若日志无法提供 (或者, 监视器所持该日志副本中确实缺少相应证书), 即构成日志运行不正确的证据. 检查操作与 TLS 连接异步进行, 以便尽管存在网络连通性问题与防火墙的不确定性, TLS 连接仍可无延迟继续.

每个日志的仅追加属性在技术上通过 Merkle 树 (Merkle Trees) 实现, 可用于表明日志的任一特定版本都是任一特定先前版本的超集. 同样, Merkle 树避免了对日志的盲目信任: 若日志试图向不同人展示不同内容, 可通过比较树根与一致性证明 (consistency proofs) 高效地发现. 同样, 日志的任何其他不当行为 (例如, 对证书签发签名时间戳后却未将其记入日志) 也可以被高效检测并向全世界证明.