第7讲 证书撤销技术.ppt

PKI技术 回顾 证书并不是永远有效的，经过了一定时间，就会失效 证书有效期 事先设定的 CA可以预期的、用户信息保持不变的期限 不可预期的事件 如何处理？ 不可预期－用户自己要求 在签发时候，没有预期的 在证书有效期内 用户身份发生变化（Subject DN和现实情况不再相符合） 用户私钥丢失、泄漏、怀疑泄漏等 用户不再拥有自己的私钥 必须及时通知应用系统、PKI User： 该证书不再有效！ 不可预期－其他要求 证书撤销也有可能是其他方面的要求 用户不交年费 用户擅自将证书用于CA不允许的用途 政府机关的要求 撤销过程 撤销过程如下 用户/或者其他方向RA提出撤销请求 RA审查撤销请求 通过后，RA将撤销请求发给CA或者CRL Issuer CA或者CRL Issuer修改证书状态 CA或者CRL Issuer定期签发CRL 证书撤销 Revocation CA告知各PKI User，某个还在证书有效期内的证书不再有效 撤销的方法 CA/CRL Issuer定期地签发CRL CRL，certificate revocation list 证书撤销列表 其他 OCSP/证书撤销树CRT 证书验证 构造证书路径 一系列证书，从订户证书到信任锚 对于证书路径中的每个证书 验证CA签名是否有效 验证是否处于有效期 有了证书撤销，就需要检查撤销状态 撤销状态检查 仅仅对于证书有效性的最基本检查 还要检查各种证书扩展 其他的各种检查 还需要进行证书扩展方面的检查 路径长度限制 密钥用途 证书策略 命名限制等等 应用系统才能使用证书 看似简单的PKI，用起来也比较麻烦 证书撤销状态 除了CRL，还有其他证书撤销状态的处理方法 CRL OCSP CRT 注意：OCSP、CRT仍然要依赖以CRL 后面说明 短周期证书 NOVOMODO 后面逐一说明 CRL CRL的各种相关基本概念 CRL中的基本内容 版本 Issuer 时间 thisUpdate－签发本CRL的时间 nextUpdate－下一次签发的时间（相当于本CRL的失效时间） 扩展 对于每一个被撤销的证书 序列号 撤销时间 CRL的ASN.1描述 与证书的结构相似 内容TBSCertList－TBSCertificate 签名算法，一致 签名结果，一致 TBSCertList 列出了被撤销的证书（后面详细说明格式） CRL 各种与CRL相关的概念 完全CRL－Complete CRL 增量CRL－Delta CRL 直接CRL－Direct CRL 间接CRL－Indirect CRL CRL分发点－CRL Distribution Point 完全CRL 完全CRL－Complete CRL 被撤销的证书序列号都是存在于同一个CRL文件中 每次都要下载所有的被撤销列表 可能文件会很大 以前下载的信息，过了很短时间马上没有用 一般是24小时、甚至更短 能否以变化量的形式？ 每次下载的量较小 增量CRL Delta CRL 给出了相对于某次完全CRL的撤销列表的变化量 Base CRL 增量CRL的参照、基准 如下图 完全CRL和增量CRL 如下图 注意：使用不同的Base CRL时，增量CRL的自身内容也就不一样 直接CRL Direct CRL 证书的签发者就是CRL的签发者 最常见的情况 间接CRL 直接CRL 给CA的负担较大 进行分工 专门的机构来签发CRL 分工是社会进步的表现 使用专门的CRL Issuer 间接CRL 如下图 直接和间接CRL 直接CRL 对于用户的证书验证，更为简单 间接CRL 用户的证书验证，比较复杂 要多进行一层的证书验证 验证CRL Issuer的证书 对于CRL Issuer的CRL，周期较长 CRL分发点 CRL Distribution Point 获取CRL的地址 也就是CA/CRL Issuer公布CRL的地址 可以出现在证书扩展中 如下图 CRL Distribution Point 示意图 所有使用证书的人，都会访问 存在问题 同样，也有文件很大的问题 如果CRL中被撤销的证书序列号很多 不利于用户下载 将CRL进行拆分 如图 CRL文件较小 拆分为多个文件 CRL Distribution Point技术 拆分的依据 由CA自己决定 可以是序列号 序列号1－5000，查询crl1.crl 序列号5001－10000，查询crl2.crl 可以是撤销原因 密钥泄漏，查询crl1.crl 其他原因，查询crl2.crl 存在问题 服务器性能问题 同时很多人访问 每天凌晨0时，所以的PKI客户端都更新CRL 同时访问，并发量很大 放置到不同的服务器上 如图 OCSP 在线证书状态协议 Online Certificate Status