跳到主要内容

5. Clients (客户端)

5. Clients (客户端)​

日志客户端可能执行多种不同功能. 此处描述若干典型客户端及其工作方式. 任何不一致均可作为日志未正确运行的证据, 且数据结构上的签名防止日志否认该不当行为.

所有客户端应彼此交换八卦 (gossip), 至少交换 STH; 仅此就足以确保它们拥有一致的视图. 八卦的确切机制将在另一份文档中描述, 但预期会有多种方式.

5.1. Submitters (提交者)​

提交者按上文所述向日志提交证书或预证书. 它们可以继续使用返回的 SCT 构造证书或直接在 TLS 握手中使用.

5.2. TLS Client (TLS 客户端)​

TLS 客户端并非日志的直接客户端, 但它们会在服务器证书旁收到 SCT. 除正常的证书及其链验证外, 它们应通过根据 SCT 数据及证书计算签名输入并验证签名来验证 SCT, 使用相应日志的公钥. 注意本文档未描述客户端如何获取各日志的公钥.

TLS 客户端必须拒绝时间戳在未来时刻的 SCT.

5.3. Monitor (监视器)​

监视器监视日志并检查其行为是否正确. 它们还监视感兴趣的证书.

监视器至少需要检查其监视的每个日志中的每个新条目. 还可能希望保留整个日志的副本. 为此, 对每个日志宜遵循以下步骤:

  1. 获取当前 STH (第 4.3 节).

  2. 验证 STH 签名.

  3. 获取与该 STH 对应的树中所有条目 (第 4.6 节).

  4. 确认由获取的条目构成的树产生的散列与 STH 中的一致.

  5. 获取当前 STH (第 4.3 节). 重复直至 STH 发生变化.

  6. 验证 STH 签名.

  7. 获取与该 STH 对应的树中所有新条目 (第 4.6 节). 若长时间仍不可用, 则应视为日志方面的不当行为.

  8. 任选其一:

    1. 验证更新后的全部条目列表生成的树与新 STH 具有相同散列.

    或者, 若未保留所有日志条目:

    1. 为新 STH 与先前 STH 获取一致性证明 (第 4.4 节).

    2. 验证一致性证明.

    3. 验证新条目生成一致性证明中的相应元素.

  9. 返回步骤 5.

5.4. Auditor (审计者)​

审计者将关于日志的部分信息作为输入, 并验证该信息与其拥有的其他部分信息一致. 审计者可以是 TLS 客户端的组成部分; 可以是独立服务; 也可以是监视器的次要功能.

同一日志的任意两个 STH 可通过请求一致性证明 (第 4.4 节) 进行验证.

附带 SCT 的证书可针对 SCT 时间戳加上最大合并延迟之后的任意 STH, 通过请求 Merkle 审计证明 (第 4.5 节) 进行验证.

审计者当然可以自行不时获取 STH (第 4.3 节).

最后于 更新