3. Overview of Approach (方法概述)

以下是使用X.509的公钥基础设施 (Public-Key Infrastructure using X.509, PKIX) 规范所假设的架构模型的简化视图.

该模型中的组件包括:

• 终端实体 (End Entity): PKI证书的用户和/或作为证书主体的最终用户系统
• CA: 证书颁发机构 (Certification Authority)
• RA: 注册机构 (Registration Authority), 即CA委托某些管理功能的可选系统
• CRL颁发者 (CRL Issuer): 生成并签名CRL的系统
• 存储库 (Repository): 存储证书和CRL的系统或分布式系统集合, 并作为向终端实体分发这些证书和CRL的方式

CA负责指示其颁发的证书的撤销状态. 撤销状态信息可以使用在线证书状态协议 (Online Certificate Status Protocol, OCSP) [RFC2560], 证书撤销列表 (CRLs) 或其他机制提供. 通常, 当使用CRL提供撤销状态信息时, CA也是CRL颁发者. 但是, CA可以将颁发CRL的责任委托给不同的实体.

注意, 属性机构 (Attribute Authority, AA) 也可以选择将CRL的发布委托给CRL颁发者.

PKI实体关系图

+---+
| C |                       +------------+
| e | <-------------------->| End entity |
| r |       Operational     +------------+
| t |       transactions          ^
| i |      and management         |  Management
| f |       transactions          |  transactions        PKI
| i |                             |                     users
| c |                             v
| a | =======================  +--+------------+  ==============
| t |                          ^               ^
| e |                          |               |         PKI
|   |                          v               |      management
| & |                       +------+           |       entities
|   | <---------------------|  RA  |<----+     |
| C |  Publish certificate  +------+     |     |
| R |                                    |     |
| L |                                    |     |
|   |                                    v     v
| R |                                +------------+
| e | <------------------------------|     CA     |
| p |   Publish certificate          +------------+
| o |   Publish CRL                     ^      ^
| s |                                   |      |  Management
| i |                +------------+     |      |  transactions
| t | <--------------| CRL Issuer |<----+      |
| o |   Publish CRL  +------------+            v
| r |                                      +------+
| y |                                      |  CA  |
+---+                                      +------+

                图1. PKI实体

3.1. X.509 Version 3 Certificate (X.509版本3证书)

公钥用户需要确信相关的私钥由正确的远程主体 (Subject) (人员或系统) 拥有, 该主体将与加密或数字签名机制一起使用. 这种信心是通过使用公钥证书 (Public Key Certificates) 获得的, 公钥证书是将公钥值绑定到主体的数据结构. 通过让受信任的CA对每个证书进行数字签名来断言该绑定. CA可以基于技术手段 (即, 通过质询-响应协议 (Challenge-Response Protocol) 进行持有证明 (Proof of Possession)), 私钥的呈现或主体的断言来做出此断言. 证书具有有限的有效生命周期, 该生命周期在其签名内容中指示. 因为证书的签名和时效性可以由使用证书的客户端独立检查, 所以证书可以通过不受信任的通信和服务器系统分发, 并且可以在使用证书的系统中以不安全的存储方式缓存.

ITU-T X.509 (以前称为CCITT X.509) 或ISO/IEC 9594-8, 于1988年作为X.500目录建议的一部分首次发布, 定义了标准证书格式 [X.509]. 1988年标准中的证书格式称为版本1 (v1) 格式. 当X.500在1993年修订时, 添加了两个字段, 形成了版本2 (v2) 格式.

互联网隐私增强邮件 (Privacy Enhanced Mail, PEM) RFC于1993年发布, 包括基于X.509 v1证书的公钥基础设施的规范 [RFC1422]. 在尝试部署RFC 1422过程中获得的经验清楚地表明, v1和v2证书格式在几个方面存在缺陷. 最重要的是, 需要更多字段来承载PEM设计和实现经验证明是必要的信息. 为了响应这些新需求, ISO/IEC, ITU-T和ANSI X9开发了X.509版本3 (v3) 证书格式. v3格式通过添加附加扩展字段的规定来扩展v2格式. 特定的扩展字段类型可以在标准中指定, 也可以由任何组织或社区定义和注册. 1996年6月, 基本v3格式的标准化完成 [X.509].

ISO/IEC, ITU-T和ANSI X9还开发了用于v3扩展字段的标准扩展 [X.509][X9.55]. 这些扩展可以传达诸如附加主体识别信息, 密钥属性信息, 策略信息和证书路径约束等数据.

然而, ISO/IEC, ITU-T和ANSI X9标准扩展在其适用性方面非常广泛. 为了开发用于互联网使用的X.509 v3系统的可互操作实现, 有必要为互联网量身定制X.509 v3扩展的使用配置文件. 本文档的一个目标是为互联网WWW, 电子邮件和IPsec应用程序指定配置文件. 具有附加要求的环境可以基于此配置文件构建或可以替换它.

3.2. Certification Paths and Trust (证书路径和信任)

需要公钥知识的安全服务用户通常需要获取并验证包含所需公钥的证书. 如果公钥用户尚未持有签署证书的CA的公钥的保证副本, CA的名称以及相关信息 (例如有效期或名称约束), 则可能需要额外的证书来获取该公钥. 通常, 可能需要多个证书的链, 包括由一个CA签署的公钥所有者 (终端实体) 的证书, 以及由其他CA签署的CA的零个或多个附加证书. 这样的链称为证书路径 (Certification Paths), 之所以需要它们, 是因为公钥用户仅使用有限数量的保证CA公钥进行初始化.

CA可以以不同的方式配置, 以便公钥用户能够找到证书路径. 对于PEM, RFC 1422定义了CA的严格分层结构. PEM证书颁发机构有三种类型:

(a) 互联网策略注册机构 (Internet Policy Registration Authority, IPRA): 该机构在互联网协会 (Internet Society) 的支持下运营, 在第1级充当PEM证书层次结构的根. 它仅为下一级机构PCA颁发证书. 所有证书路径都从IPRA开始.

(b) 策略证书颁发机构 (Policy Certification Authorities, PCAs): PCA位于层次结构的第2级, 每个PCA由IPRA认证. PCA应 (shall) 建立并发布其关于认证用户或下级证书颁发机构的策略声明. 不同的PCA旨在满足不同的用户需求. 例如, 一个PCA (组织PCA) 可能支持商业组织的一般电子邮件需求, 而另一个PCA (高保证PCA) 可能具有更严格的策略, 旨在满足具有法律约束力的数字签名要求.

(c) 证书颁发机构 (Certification Authorities, CAs): CA位于层次结构的第3级, 也可以位于更低级别. 第3级的CA由PCA认证. CA例如代表特定组织, 特定组织单位 (例如, 部门, 小组, 部分) 或特定地理区域.

RFC 1422还有一个名称从属规则 (Name Subordination Rule), 该规则要求CA只能为名称从属于 (在X.500命名树中) CA本身名称的实体颁发证书. 与PEM证书路径相关的信任由PCA名称暗示. 名称从属规则确保PCA下的CA在可以认证的下级实体集方面受到合理约束 (例如, 组织的CA只能认证该组织名称树中的实体). 证书用户系统能够机械地检查名称从属规则是否已被遵循.

RFC 1422使用X.509 v1证书格式. X.509 v1的限制需要施加若干结构限制, 以明确关联策略信息或限制证书的效用. 这些限制包括:

• (a) 纯粹的自上而下层次结构, 所有证书路径都从IPRA开始
• (b) 限制CA主体名称的名称从属规则
• (c) 使用PCA概念, 这需要将各个PCA的知识内置到证书链验证逻辑中. 需要了解各个PCA以确定链是否可以被接受

使用X.509 v3, RFC 1422解决的大多数要求都可以使用证书扩展来解决, 而无需限制使用的CA结构. 特别是, 与证书策略 (Certificate Policies) 相关的证书扩展消除了对PCA的需求, 约束扩展 (Constraint Extensions) 消除了对名称从属规则的需求. 因此, 本文档支持更灵活的架构, 包括:

(a) 证书路径从用户自己域中的CA的公钥或层次结构顶部的公钥开始. 从用户自己域中的CA的公钥开始具有某些优势. 在某些环境中, 本地域是最受信任的.

(b) 名称约束可以通过在证书中明确包含名称约束扩展来施加, 但不是必需的.

(c) 策略扩展和策略映射取代了PCA概念, 这允许更大程度的自动化. 应用程序可以根据证书的内容而不是对PCA的先验知识来确定证书路径是否可接受. 这允许证书路径处理的自动化.

X.509 v3还包括一个扩展, 该扩展将证书的主体识别为CA或终端实体, 从而减少了对PEM中所需的带外信息的依赖.

本规范涵盖两类证书: CA证书和终端实体证书. CA证书可以进一步分为三类: 交叉证书 (Cross-Certificates), 自颁发证书 (Self-Issued Certificates) 和自签名证书 (Self-Signed Certificates). 交叉证书是颁发者和主体是不同实体的CA证书. 交叉证书描述了两个CA之间的信任关系. 自颁发证书是颁发者和主体是同一实体的CA证书. 自颁发证书是为了支持策略或操作的变更而生成的. 自签名证书是自颁发证书, 其中数字签名可以由证书中绑定的公钥验证. 自签名证书用于传达用于开始证书路径的公钥. 终端实体证书颁发给未被授权颁发证书的主体.

3.3. Revocation (撤销)

当颁发证书时, 期望它在其整个有效期内使用. 但是, 各种情况可能导致证书在有效期到期之前失效. 此类情况包括名称更改, 主体与CA之间的关联更改 (例如, 员工终止与组织的雇佣关系), 以及相应私钥的泄露或疑似泄露. 在这种情况下, CA需要撤销证书.

X.509定义了一种证书撤销方法. 该方法涉及每个CA定期颁发称为证书撤销列表 (Certificate Revocation List, CRL) 的签名数据结构. CRL是一个带时间戳的列表, 用于识别已撤销的证书, 该列表由CA或CRL颁发者签名, 并在公共存储库中免费提供. 每个已撤销的证书在CRL中由其证书序列号标识. 当使用证书的系统使用证书时 (例如, 用于验证远程用户的数字签名), 该系统不仅检查证书签名和有效性, 还获取适当最新的CRL并检查证书序列号是否不在该CRL上. "适当最新"的含义可能因本地策略而异, 但通常意味着最近颁发的CRL. 新的CRL定期颁发 (例如, 每小时, 每天或每周). 在收到撤销通知后的下一次更新时, 将条目添加到CRL. 在撤销证书的有效期之后颁发的定期计划CRL上出现之前, 禁止 (MUST NOT) 从CRL中删除条目.

这种撤销方法的一个优点是CRL可以通过与证书本身完全相同的方式分发, 即通过不受信任的服务器和不受信任的通信.

使用不受信任的通信和服务器的CRL撤销方法的一个限制是撤销的时间粒度受到CRL颁发周期的限制. 例如, 如果现在报告撤销, 则该撤销将不会可靠地通知使用证书的系统, 直到所有当前颁发的CRL计划更新 - 这可能长达一小时, 一天或一周, 具体取决于CRL的颁发频率.

与X.509 v3证书格式一样, 为了便于来自多个供应商的可互操作实现, X.509 v2 CRL格式需要针对互联网使用进行配置. 本文档的一个目标是指定该配置文件. 但是, 此配置文件不要求颁发CRL. 支持在线撤销通知的消息格式和协议在其他PKIX规范中定义. 在某些环境中, 在线撤销通知方法可能适用作为X.509 CRL的替代方案. 在线撤销检查可以显著减少撤销报告与向依赖方分发信息之间的延迟. 一旦CA接受撤销报告为真实且有效, 对在线服务的任何查询都将正确反映撤销对证书验证的影响. 但是, 这些方法施加了新的安全要求: 证书验证者需要信任在线验证服务, 而存储库不需要受信任.

3.4. Operational Protocols (操作协议)

需要操作协议将证书和CRL (或状态信息) 传递给使用证书的客户端系统. 需要为各种不同的证书和CRL传递方式提供规定, 包括基于LDAP, HTTP, FTP和X.500的分发程序. 支持这些功能的操作协议在其他PKIX规范中定义. 这些规范可能包括支持上述所有操作环境的消息格式和程序的定义, 包括对适当MIME内容类型的定义或引用.

3.5. Management Protocols (管理协议)

需要管理协议来支持PKI用户和管理实体之间的在线交互. 例如, 管理协议可能用于CA与与密钥对相关联的客户端系统之间, 或用于相互交叉认证的两个CA之间. 管理协议可能需要支持的功能集包括:

(a) 注册 (Registration): 这是用户首次向CA (直接或通过RA) 表明自己身份的过程, 在该CA为该用户颁发一个或多个证书之前.

(b) 初始化 (Initialization): 在客户端系统可以安全运行之前, 需要安装与基础设施中其他位置存储的密钥具有适当关系的密钥材料. 例如, 客户端需要使用受信任CA的公钥和其他保证信息进行安全初始化, 以用于验证证书路径. 此外, 客户端通常需要使用自己的密钥对进行初始化.

(c) 认证 (Certification): 这是CA为用户的公钥颁发证书, 并将该证书返回给用户的客户端系统和/或将该证书发布到存储库中的过程.

(d) 密钥对恢复 (Key Pair Recovery): 作为一个选项, 用户客户端密钥材料 (例如, 用户用于加密目的的私钥) 可以由CA或密钥备份系统备份. 如果用户需要恢复这些备份的密钥材料 (例如, 由于忘记密码或丢失密钥链文件), 可能需要在线协议交换来支持此类恢复.

(e) 密钥对更新 (Key Pair Update): 所有密钥对都需要定期更新, 即替换为新的密钥对并颁发新证书.

(f) 撤销请求 (Revocation Request): 授权人员向CA建议需要证书撤销的异常情况.

(g) 交叉认证 (Cross-Certification): 两个CA交换用于建立交叉证书的信息. 交叉证书是一个CA向另一个CA颁发的证书, 该证书包含用于颁发证书的CA签名密钥.

注意, 在线协议不是实现上述功能的唯一方法. 对于所有功能, 都有实现相同结果的离线方法, 本规范不强制使用在线协议. 例如, 当使用硬件令牌时, 许多功能可以作为物理令牌交付的一部分实现. 此外, 上述某些功能可以组合到一个协议交换中. 特别是, 注册, 初始化和认证功能中的两个或多个可以组合到一个协议交换中.

PKIX系列规范定义了一组支持上述功能的标准消息格式. 在不同环境 (例如, 电子邮件, 文件传输和WWW) 中传送这些消息的协议在这些规范中进行了描述.