8. Security Considerations (安全考虑)
本规范的大部分内容专门讨论证书和CRL的格式和内容. 由于证书和CRL是数字签名的, 因此不需要额外的完整性服务. 证书和CRL都不需要保密, 对证书和CRL的无限制和匿名访问没有安全影响.
但是, 本规范范围之外的安全因素将影响提供给证书用户的保证. 本节重点介绍实现者、管理员和用户需要考虑的关键问题.
身份验证程序
CA和RA为验证主体身份与其公钥的绑定而执行的程序极大地影响应该放置在证书中的保证. 依赖方可能希望审查CA的证书实践声明 (Certification Practice Statement). 这在向其他CA颁发证书时尤为重要.
密钥用途分离
强烈不建议 将单个密钥对同时用于签名和其他用途. 对签名和密钥管理使用单独的密钥对为用户提供了几个好处. 与签名密钥的丢失或泄露相关的后果不同于密钥管理密钥的丢失或泄露. 使用单独的密钥对允许平衡和灵活的响应. 类似地, 在某些应用环境中, 每个密钥对的不同有效期或密钥长度可能是合适的. 不幸的是, 某些传统应用程序 (例如, 安全套接字层 (Secure Sockets Layer, SSL)) 对签名和密钥管理使用单个密钥对.
私钥保护
对私钥提供的保护是关键的安全因素. 在小范围内, 用户无法保护其私钥将允许攻击者伪装成他们或解密其个人信息. 在更大范围内, CA私有签名密钥的泄露可能会产生灾难性影响. 如果攻击者在未被注意的情况下获得私钥, 攻击者可能会颁发虚假证书和CRL. 虚假证书和CRL的存在将破坏对系统的信任. 如果检测到此类泄露, 则必须 (MUST) 撤销颁发给受损CA的所有证书, 从而阻止其用户与其他CA用户之间的服务. 在此类泄露后重建将是有问题的, 因此建议CA实施强大技术措施 (例如, 防篡改加密模块) 和适当管理程序 (例如, 职责分离) 的组合以避免此类事件.
CA私有签名密钥的丢失也可能是有问题的. CA将无法生成CRL或执行正常的密钥滚动. CA应该 (SHOULD) 为签名密钥维护安全备份. 密钥备份程序的安全性是避免密钥泄露的关键因素.
撤销信息的可用性和及时性
撤销信息的可用性和及时性影响应该放置在证书中的保证程度. 虽然证书自然会过期, 但在其自然生命周期内可能会发生使主体与公钥之间的绑定无效的事件. 如果撤销信息不及时或不可用, 则与绑定相关的保证明显降低. 依赖方可能无法处理CRL中可能出现的每个关键扩展. 当仅通过包含关键扩展的CRL提供撤销信息时, CA应该 (SHOULD) 格外小心, 特别是如果此配置文件未强制支持这些扩展.
例如, 如果使用增量CRL和完整CRL的组合提供撤销信息, 并且增量CRL的颁发频率高于完整CRL, 则无法处理与增量CRL处理相关的关键扩展的依赖方将无法获得最新的撤销信息. 或者, 如果在颁发增量CRL时也颁发完整CRL, 则所有依赖方都可以获得及时的撤销信息. 类似地, 省略撤销检查的第6节中描述的证书路径验证机制的实现提供的保证少于支持它的实现.
信任锚的认证分发
证书路径验证算法依赖于对一个或多个受信任CA的公钥 (和其他信息) 的确定知识. 信任CA的决定是一个重要决定, 因为它最终决定了对证书提供的信任. 受信任CA公钥的认证分发 (通常以"自签名"证书的形式) 是一个安全关键的带外过程, 超出了本规范的范围.
此外, 当受信任CA发生密钥泄露或CA失败时, 用户将需要修改提供给路径验证例程的信息. 选择过多受信任CA会使受信任CA信息难以维护. 另一方面, 仅选择一个受信任CA可能会将用户限制在封闭的用户社区中.
实现质量
处理证书的实现质量也会影响提供的保证程度. 第6节中描述的路径验证算法依赖于受信任CA信息的完整性, 特别是与受信任CA关联的公钥的完整性. 通过替换攻击者拥有私钥的公钥, 攻击者可以欺骗用户接受虚假证书.
加密算法强度
密钥和证书主体之间的绑定不能强于用于生成签名的加密模块实现和算法. 短密钥长度或弱哈希算法将限制证书的效用. 鼓励CA注意密码学的进步, 以便他们可以采用强大的加密技术. 此外, CA应该 (SHOULD) 拒绝向生成弱签名的CA或终端实体颁发证书.
名称比较规则的一致应用
名称比较规则的不一致应用可能导致接受无效的X.509证书路径或拒绝有效的路径. X.500系列规范定义了比较可辨别名称的规则, 这些规则要求比较字符串而不考虑大小写、字符集、多字符空白子字符串或前导和尾随空白. 本规范放宽了这些要求, 至少要求支持二进制比较.
CA必须 (MUST) 在CA证书的主体字段中编码可辨别名称的方式与该CA颁发的证书中颁发者字段中可辨别名称的编码方式相同. 如果CA使用不同的编码, 实现可能无法识别包含此证书的路径的名称链. 因此, 有效路径可能会被拒绝.
此外, 可辨别名称的名称约束必须 (MUST) 与主体字段或subjectAltName扩展中使用的编码相同. 否则, 声明为excludedSubtrees的名称约束将不匹配, 并且将接受无效路径, 而表示为permittedSubtrees的名称约束将不匹配, 并且将拒绝有效路径. 为避免接受无效路径, CA应该 (SHOULD) 尽可能将可辨别名称的名称约束声明为permittedSubtrees.
名称形式限制
通常, 使用nameConstraints扩展约束一种名称形式 (例如, DNS名称) 不能防止使用其他名称形式 (例如, 电子邮件地址).
颁发者名称冲突
虽然X.509要求名称是明确的, 但存在两个不相关的机构将以相同颁发者名称颁发证书和/或CRL的风险. 作为减少与颁发者名称冲突相关的问题和安全问题的手段, CA和CRL颁发者名称应该 (SHOULD) 以降低名称冲突可能性的方式形成. 实现者应该考虑可能存在多个具有相同名称的不相关CA和CRL颁发者. 至少, 验证CRL的实现必须 (MUST) 确保证书的证书路径和用于验证证书的CRL颁发者证书路径在同一信任锚处终止.
电子邮件地址的大小写敏感性
虽然电子邮件地址的本地部分 (local-part) 区分大小写 [RFC2821], 但emailAddress属性值不区分大小写 [RFC2985]. 因此, 如果电子邮件服务器利用邮箱本地部分的大小写敏感性, 则存在当使用emailAddress属性的匹配规则时, 两个不同的电子邮件地址将被视为相同地址的风险. 如果托管电子邮件地址的电子邮件服务器将电子邮件地址的本地部分视为区分大小写, 则实现者不应在emailAddress属性中包含电子邮件地址.
恶意代码链接
实现者应该意识到, 如果损坏的证书或CRL的CRL分发点或授权信息访问扩展包含指向恶意代码的链接, 则涉及的风险. 实现者应该始终采取验证检索到的数据的步骤, 以确保数据格式正确.
循环依赖
当证书在cRLDistributionPoints扩展中包含https URI或类似方案时, 可能会引入循环依赖. 依赖方被迫执行额外的路径验证, 以获取完成初始路径验证所需的CRL! 当authorityInfoAccess或subjectInfoAccess扩展中的https URI (或类似方案) 也可以创建循环条件. 在最坏的情况下, 这种情况可能会创建无法解决的依赖关系.
CA不应该 (SHOULD NOT) 在扩展中包含指定https、ldaps或类似方案的URI. 在这些扩展之一中包含https URI的CA必须 (MUST) 确保可以在不使用URI指向的信息的情况下验证服务器的证书. 在cRLDistributionPoints、authorityInfoAccess或subjectInfoAccess扩展中的https URI处获取信息时选择验证服务器证书的依赖方必须 (MUST) 准备好这可能导致无限递归的可能性.
自颁发证书
自颁发证书为CA提供了一种自动机制来指示CA操作的变更. 特别是, 自颁发证书可用于实现从一个未泄露的CA密钥对到下一个的优雅转换. [RFC4210] 中指定了"CA密钥更新"的详细程序, 其中CA使用其先前的私钥保护其新公钥, 反之亦然, 使用两个自颁发证书. 符合标准的客户端实现将处理自颁发证书并确定是否可以信任在新密钥下颁发的证书. 自颁发证书可以 (MAY) 用于使用类似程序支持CA操作中的其他变更, 例如对CA策略集的添加.
字符编码问题
某些传统实现支持在ISO 8859-1字符集 (Latin1String) [ISO8859] 中编码的名称, 但将它们标记为TeletexString. TeletexString编码的字符集比ISO 8859-1大, 但它对某些字符的编码不同. 第7.1节中指定的名称比较规则假定TeletexString按ASN.1标准中的描述进行编码. 当比较使用Latin1String字符集编码的名称时, 可能会出现假阳性和假阴性.
视觉混淆攻击
当字符串从内部表示映射到视觉表示时, 有时两个不同的字符串将具有相同或相似的视觉表示. 这可能由于许多不同的原因而发生, 包括使用相似的字形和使用组合字符 (例如e + '等于U+00E9, 韩文组合字符和某些语言中辅音簇上方的元音). 由于这种情况, 人们在两个不同名称之间进行视觉比较时可能会认为它们相同, 而实际上它们不是. 此外, 人们可能会将一个字符串误认为另一个字符串. 证书颁发者和依赖方都需要意识到这种情况.