5. CRL and CRL Extensions Profile (CRL和CRL扩展配置)
如上所述, 此X.509 v2 CRL配置文件的一个目标是促进可互操作和可重用的互联网PKI的创建. 为实现此目标, 指定了扩展使用的指南, 并对CRL中包含的信息的性质做出了一些假设.
CRL可用于广泛的应用程序和环境, 涵盖广泛的互操作性目标和更广泛的操作和保证要求. 此配置文件为需要广泛互操作性的通用应用程序建立了通用基线. 该配置文件定义了可以在每个CRL中期望的一组信息. 此外, 该配置文件定义了CRL中常用属性的常见位置以及这些属性的常见表示.
CRL颁发者 (CRL issuers) 颁发CRL. CRL颁发者是CA或已被CA授权颁发CRL的实体. CA发布CRL以提供有关其颁发的证书的状态信息. 但是, CA可以将此责任委托给另一个受信任的机构.
每个CRL都有特定的范围 (scope). CRL范围是可能出现在给定CRL上的证书集. 例如, 范围可以是"CA X颁发的所有证书", "CA X颁发的所有CA证书", "CA X颁发的因密钥泄露和CA泄露原因而被撤销的所有证书", 或基于任意本地信息的证书集, 例如"颁发给位于Boulder的NIST员工的所有证书".
完整CRL (complete CRL) 列出了其范围内因CRL范围涵盖的撤销原因之一而被撤销的所有未过期证书. 完整CRL (full and complete CRL) 列出了CA颁发的因任何原因而被撤销的所有未过期证书. (注意, 由于CA和CRL颁发者由名称标识, 因此CRL的范围不受用于签署CRL的密钥或用于签署证书的密钥的影响.)
如果CRL的范围包括由CRL颁发者以外的实体颁发的一个或多个证书, 则它是间接CRL (indirect CRL). 间接CRL的范围可能仅限于单个CA颁发的证书, 或者可能包括多个CA颁发的证书. 如果间接CRL的颁发者是CA, 则间接CRL的范围也可以 (MAY) 包括CRL颁发者颁发的证书.
CRL颁发者也可以 (MAY) 生成增量CRL (delta CRLs). 增量CRL仅列出其范围内自引用的完整CRL颁发以来撤销状态已更改的那些证书. 引用的完整CRL称为基本CRL (base CRL). 增量CRL的范围必须 (MUST) 与其引用的基本CRL相同.
此配置文件定义了一个私有互联网CRL扩展, 但未定义任何私有CRL条目扩展.
具有额外或特殊目的要求的环境可以在此配置文件的基础上构建或可以替换它.
如果提供了其他撤销或证书状态机制, 则不要求符合标准的CA颁发CRL. 当颁发CRL时, CRL必须 (MUST) 是版本2 CRL, 在nextUpdate字段 (第5.1.2.5节) 中包含下一个CRL将颁发的日期, 包含CRL编号扩展 (第5.2.3节), 并包含授权密钥标识符扩展 (第5.2.1节). 支持CRL的符合标准的应用程序必须 (REQUIRED) 处理为一个CA颁发的所有证书提供撤销信息的版本1和版本2完整CRL. 符合标准的应用程序不需要支持增量CRL、间接CRL或范围不是一个CA颁发的所有证书的CRL的处理.
5.1. CRL Fields (CRL字段)
X.509 v2 CRL语法如下. 对于签名计算, 要签名的数据是ASN.1 DER编码的. ASN.1 DER编码是每个元素的标签、长度、值编码系统.
CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertList ::= SEQUENCE {
version Version OPTIONAL,
-- if present, MUST be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, version MUST be v2
} OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL
-- if present, version MUST be v2
}
-- Version, Time, CertificateSerialNumber, and Extensions
-- are all defined in the ASN.1 in Section 4.1
-- AlgorithmIdentifier is defined in Section 4.1.1.2
以下各项描述X.509 v2 CRL在互联网PKI中的使用.
5.1.1. CertificateList Fields (CertificateList字段)
CertificateList是一个包含三个必需字段的序列 (SEQUENCE). 这些字段在以下小节中详细描述.
5.1.1.1. tbsCertList (待签名CertList)
序列中的第一个字段是tbsCertList. 该字段本身是一个序列, 包含颁发者的名称、颁发日期、下一个列表的颁发日期、撤销证书的可选列表以及可选的CRL扩展. 当没有撤销的证书时, 撤销证书列表不存在. 当撤销一个或多个证书时, 撤销证书列表上的每个条目由用户证书序列号、撤销日期和可选CRL条目扩展的序列定义.
5.1.1.2. signatureAlgorithm (签名算法)
signatureAlgorithm字段包含CRL颁发者用于签署CertificateList的算法的算法标识符. 该字段的类型是AlgorithmIdentifier, 在第4.1.1.2节中定义. [RFC3279]、[RFC4055] 和 [RFC4491] 列出了此规范支持的算法, 但也可以 (MAY) 支持其他签名算法.
此字段必须 (MUST) 包含与序列tbsCertList中signature字段 (第5.1.2.2节) 相同的算法标识符.
5.1.1.3. signatureValue (签名值)
signatureValue字段包含对ASN.1 DER编码的tbsCertList计算的数字签名. ASN.1 DER编码的tbsCertList用作签名函数的输入. 此签名值编码为位串 (BIT STRING) 并包含在CRL signatureValue字段中. [RFC3279]、[RFC4055] 和 [RFC4491] 中为每个支持的算法指定了此过程的详细信息.
也是CRL颁发者的CA可以 (MAY) 使用一个私钥对证书和CRL进行数字签名, 或可以 (MAY) 使用单独的私钥对证书和CRL进行数字签名. 当使用单独的私钥时, 与这些私钥关联的每个公钥都放置在单独的证书中, 一个在密钥用途扩展中设置keyCertSign位, 另一个在密钥用途扩展中设置cRLSign位 (第4.2.1.3节). 当使用单独的私钥时, CA颁发的证书包含一个授权密钥标识符, 而相应的CRL包含不同的授权密钥标识符. 对证书签名和CRL签名的验证使用单独的CA证书可以提供改进的安全特性; 但是, 它对应用程序施加了负担, 并且可能限制互操作性. 许多应用程序构建证书路径, 然后验证证书路径 (第6节). CRL检查反过来需要构建和验证单独的证书路径以用于CA的CRL签名验证证书. 执行CRL检查的应用程序必须 (MUST) 支持当证书和CRL使用相同CA私钥进行数字签名时的证书路径验证. 这些应用程序应该 (SHOULD) 支持当证书和CRL使用不同CA私钥进行数字签名时的证书路径验证.
5.1.2. Certificate List "To Be Signed" (待签名证书列表)
待签名证书列表 (TBSCertList) 是必需和可选字段的序列. 必需字段标识CRL颁发者、用于签署CRL的算法以及CRL颁发的日期和时间.
可选字段包括CRL颁发者将颁发下一个CRL的日期和时间、撤销证书列表以及CRL扩展. 撤销证书列表是可选的, 以支持CA未撤销其颁发的任何未过期证书的情况. 此配置文件要求符合标准的CRL颁发者在颁发的所有CRL中包含nextUpdate字段以及CRL编号和授权密钥标识符CRL扩展.
5.1.2.1. Version (版本)
此可选字段描述编码CRL的版本. 当使用扩展时 (如此配置文件所要求), 此字段必须 (MUST) 存在并且必须 (MUST) 指定版本2 (整数值为1).
5.1.2.2. Signature (签名)
此字段包含用于签署CRL的算法的算法标识符. [RFC3279]、[RFC4055] 和 [RFC4491] 列出了互联网PKI中使用的最流行签名算法的OID.
此字段必须 (MUST) 包含与序列CertificateList中signatureAlgorithm字段 (第5.1.1.2节) 相同的算法标识符.
5.1.2.3. Issuer Name (颁发者名称)
issuer name标识已签署并颁发CRL的实体. 颁发者身份在issuer字段中携带. 备用名称形式也可能出现在issuerAltName扩展中 (第5.2.2节). issuer字段必须 (MUST) 包含非空的X.500可辨别名称 (DN). issuer字段定义为X.501类型Name, 并且必须 (MUST) 遵循证书中颁发者名称字段的编码规则 (第4.1.2.4节).
5.1.2.4. This Update (本次更新)
此字段指示此CRL的颁发日期. thisUpdate可以编码为UTCTime或GeneralizedTime.
符合此配置文件的CRL颁发者必须 (MUST) 将到2049年的thisUpdate编码为UTCTime. 符合此配置文件的CRL颁发者必须 (MUST) 将2050年或以后的thisUpdate编码为GeneralizedTime. 符合标准的应用程序必须 (MUST) 能够处理以UTCTime或GeneralizedTime编码的日期.
当编码为UTCTime时, thisUpdate必须 (MUST) 按第4.1.2.5.1节定义的方式指定和解释. 当编码为GeneralizedTime时, thisUpdate必须 (MUST) 按第4.1.2.5.2节定义的方式指定和解释.
5.1.2.5. Next Update (下次更新)
此字段指示下一个CRL将颁发的日期. 下一个CRL可能在指示日期之前颁发, 但不会晚于指示日期颁发. CRL颁发者应该 (SHOULD) 颁发nextUpdate时间等于或晚于所有先前CRL的CRL. nextUpdate可以编码为UTCTime或GeneralizedTime.
符合标准的CRL颁发者必须 (MUST) 在所有CRL中包含nextUpdate字段. 注意, TBSCertList的ASN.1语法将此字段描述为可选 (OPTIONAL), 这与 [X.509] 中定义的ASN.1结构一致. 此配置文件未指定客户端处理省略nextUpdate的CRL的行为.
符合此配置文件的CRL颁发者必须 (MUST) 将到2049年的nextUpdate编码为UTCTime. 符合此配置文件的CRL颁发者必须 (MUST) 将2050年或以后的nextUpdate编码为GeneralizedTime. 符合标准的应用程序必须 (MUST) 能够处理以UTCTime或GeneralizedTime编码的日期.
当编码为UTCTime时, nextUpdate必须 (MUST) 按第4.1.2.5.1节定义的方式指定和解释. 当编码为GeneralizedTime时, nextUpdate必须 (MUST) 按第4.1.2.5.2节定义的方式指定和解释.
5.1.2.6. Revoked Certificates (撤销的证书)
当没有撤销的证书时, 撤销证书列表必须 (MUST) 不存在. 否则, 撤销的证书按其序列号列出. CA撤销的证书由证书序列号唯一标识. 指定了撤销发生的日期. revocationDate的时间必须 (MUST) 按第5.1.2.4节中描述的方式表示. 可以在CRL条目扩展中提供其他信息; CRL条目扩展在第5.3节中讨论.
5.1.2.7. Extensions (扩展)
此字段只能在版本为2 (第5.1.2.1节) 时出现. 如果存在, 此字段是一个或多个CRL扩展的序列. CRL扩展在第5.2节中讨论.
5.2. CRL Extensions (CRL扩展)
ANSI X9、ISO/IEC和ITU-T为X.509 v2 CRL [X.509] [X9.55] 定义的扩展提供了将附加属性与CRL关联的方法. X.509 v2 CRL格式还允许社区定义私有扩展以携带这些社区特有的信息. CRL中的每个扩展可以指定为关键 (critical) 或非关键 (non-critical). 如果CRL包含应用程序无法处理的关键扩展, 则应用程序禁止 (MUST NOT) 使用该CRL来确定证书的状态. 但是, 应用程序可以忽略无法识别的非关键扩展. 以下小节介绍互联网CRL中使用的那些扩展. 社区可以选择在CRL中包含此规范中未定义的扩展. 但是, 在采用可能在一般上下文中使用的CRL中的任何关键扩展时应谨慎行事.
符合标准的CRL颁发者必须 (REQUIRED) 在颁发的所有CRL中包含授权密钥标识符 (第5.2.1节) 和CRL编号 (第5.2.3节) 扩展.
5.2.1. Authority Key Identifier (授权密钥标识符)
授权密钥标识符扩展提供了一种识别与用于签署CRL的私钥相对应的公钥的方法. 识别可以基于密钥标识符 (CRL签名者证书中的主体密钥标识符) 或颁发者名称和序列号. 此扩展在颁发者具有多个签名密钥时特别有用, 这可能是由于多个并发密钥对或由于转换.
符合标准的CRL颁发者必须 (MUST) 使用密钥标识符方法, 并且必须 (MUST) 在颁发的所有CRL中包含此扩展.
此CRL扩展的语法在第4.2.1.1节中定义.
5.2.2. Issuer Alternative Name (颁发者备用名称)
颁发者备用名称扩展允许将附加身份与CRL的颁发者关联. 定义的选项包括电子邮件地址 (rfc822Name)、DNS名称、IP地址和URI. 可以包含名称形式的多个实例和多个名称形式. 每当使用此类身份时, 必须 (MUST) 使用颁发者备用名称扩展; 但是, 如第4.1.2.4节所述, 可以 (MAY) 使用domainComponent属性在issuer字段中表示DNS名称.
符合标准的CRL颁发者应该 (SHOULD) 将issuerAltName扩展标记为非关键 (non-critical).
此CRL扩展的OID和语法在第4.2.1.7节中定义.
5.2.3. CRL Number (CRL编号)
CRL编号是非关键CRL扩展, 它为给定CRL范围和CRL颁发者传达单调递增的序列号. 此扩展允许用户轻松确定特定CRL何时取代另一个CRL. CRL编号还支持补充完整CRL和增量CRL的识别. 符合此配置文件的CRL颁发者必须 (MUST) 在所有CRL中包含此扩展, 并且必须 (MUST) 将此扩展标记为非关键 (non-critical).
如果CRL颁发者为给定范围生成增量CRL以及完整CRL, 则完整CRL和增量CRL必须 (MUST) 共享一个编号序列. 如果涵盖相同范围的增量CRL和完整CRL同时颁发, 它们必须 (MUST) 具有相同的CRL编号并提供相同的撤销信息. 也就是说, 增量CRL和可接受完整CRL的组合必须 (MUST) 提供与同时颁发的完整CRL相同的撤销信息.
如果CRL颁发者在不同时间为相同范围生成两个CRL (两个完整CRL、两个增量CRL或一个完整CRL和一个增量CRL), 则两个CRL禁止 (MUST NOT) 具有相同的CRL编号. 也就是说, 如果两个CRL中的thisUpdate字段 (第5.1.2.4节) 不同, 则两个CRL中的CRL编号也必须不同.
根据上述要求, 可以预期CRL编号包含长整数. CRL验证者必须 (MUST) 能够处理最多20个八位字节的CRLNumber值. 符合标准的CRL颁发者禁止 (MUST NOT) 使用长于20个八位字节的CRLNumber值.
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
CRLNumber ::= INTEGER (0..MAX)
5.2.4. Delta CRL Indicator (增量CRL指示符)
增量CRL指示符是关键CRL扩展, 它将CRL标识为增量CRL. 增量CRL包含对先前分发的撤销信息的更新, 而不是完整CRL中出现的所有信息. 在某些环境中, 使用增量CRL可以显著减少网络负载和处理时间. 增量CRL通常比它们更新的CRL小, 因此获取增量CRL的应用程序比获取相应完整CRL的应用程序消耗更少的网络带宽. 以CRL结构以外的格式存储撤销信息的应用程序可以将新撤销信息添加到本地数据库, 而无需重新处理信息.
增量CRL指示符扩展包含BaseCRLNumber类型的单个值. CRL编号标识为给定范围完整的CRL, 该CRL用作生成此增量CRL的起点. 符合标准的CRL颁发者必须 (MUST) 将引用的基本CRL作为完整CRL发布. 增量CRL包含同一范围的撤销状态的所有更新. 在增量CRL发布时, 增量CRL加上引用的基本CRL的组合等效于适用范围的完整CRL.
当符合标准的CRL颁发者生成增量CRL时, 增量CRL必须 (MUST) 包含关键增量CRL指示符扩展.
当颁发增量CRL时, 它必须 (MUST) 涵盖与其引用的基本CRL涵盖的相同原因集和相同证书集. 也就是说, 增量CRL的范围必须 (MUST) 与作为基本的完整CRL引用的范围相同. 引用的基本CRL和增量CRL必须 (MUST) 省略颁发分发点扩展或包含相同的颁发分发点扩展. 此外, CRL颁发者必须 (MUST) 使用相同的私钥对增量CRL和可用于更新的任何完整CRL进行签名.
支持增量CRL的应用程序可以通过将该范围的增量CRL与为该范围颁发的完整CRL或为该范围本地构造的CRL相结合来构造为给定范围完整的CRL.
当增量CRL与完整CRL或本地构造的CRL组合时, 生成的本地构造CRL具有在其构造中使用的增量CRL中找到的CRL编号扩展中指定的CRL编号. 此外, 生成的本地构造CRL具有在其构造中使用的增量CRL的相应字段中指定的thisUpdate和nextUpdate时间. 此外, 本地构造的CRL从增量CRL继承颁发分发点.
如果满足以下四个条件, 则可以 (MAY) 组合完整CRL和增量CRL:
(a) 完整CRL和增量CRL具有相同的颁发者.
(b) 完整CRL和增量CRL具有相同的范围. 如果满足以下任一条件, 则两个CRL具有相同的范围:
(1) 从完整CRL和增量CRL中都省略了issuingDistributionPoint扩展.
(2) issuingDistributionPoint扩展存在于完整CRL和增量CRL中, 并且扩展中每个字段的值在两个CRL中相同.
(c) 完整CRL的CRL编号等于或大于增量CRL中指定的BaseCRLNumber. 也就是说, 完整CRL包含 (至少) 引用的基本CRL持有的所有撤销信息.
(d) 完整CRL的CRL编号小于增量CRL的CRL编号. 也就是说, 增量CRL在编号序列中跟随完整CRL.
CRL颁发者必须 (MUST) 确保增量CRL和任何适当完整CRL的组合准确反映当前撤销状态. CRL颁发者必须 (MUST) 在增量CRL中包含增量CRL范围内自引用的基本CRL生成以来状态已更改的每个证书的条目:
(a) 如果证书因CRL范围中包含的原因而被撤销, 则将证书列为已撤销.
(b) 如果证书有效并且在引用的基本CRL或任何后续CRL上以原因码certificateHold列出, 并且原因码certificateHold包含在CRL的范围内, 则将证书列为原因码removeFromCRL.
(c) 如果证书因CRL范围之外的原因而被撤销, 但该证书在引用的基本CRL或任何后续CRL上以CRL范围内包含的原因码列出, 则将证书列为已撤销但省略原因码.
(d) 如果证书因CRL范围之外的原因而被撤销, 并且该证书既未在引用的基本CRL上列出, 也未在任何后续CRL上以此CRL范围内包含的原因码列出, 则不要在此CRL上列出该证书.
如果证书被撤销 (因任何撤销原因, 包括certificateHold)、从暂挂中释放或其撤销原因更改, 则认为证书的状态已更改.
即使证书在引用的基本CRL中未处于暂挂状态, 在增量CRL上以原因码removeFromCRL列出证书也是适当的. 如果证书在基本之后但在此增量CRL之前颁发的任何CRL中被暂挂, 然后从暂挂中释放, 则必须 (MUST) 以撤销原因removeFromCRL在增量CRL上列出.
如果证书中指定的notAfter时间早于增量CRL中指定的thisUpdate时间, 并且该证书在引用的基本CRL上或在基本之后但在此增量CRL之前颁发的任何CRL中列出, 则CRL颁发者可以 (MAY) 选择以原因码removeFromCRL在增量CRL上列出证书.
如果证书撤销通知首次出现在增量CRL上, 则证书有效期可能在为同一范围颁发下一个完整CRL之前到期. 在这种情况下, 撤销通知必须 (MUST) 包含在所有后续增量CRL中, 直到撤销通知至少包含在此范围的一个显式颁发的完整CRL上.
支持增量CRL的应用程序必须 (MUST) 能够通过组合先前颁发的完整CRL和最新的增量CRL来构造当前完整CRL. 支持增量CRL的应用程序也可以 (MAY) 能够通过组合先前本地构造的完整CRL和当前增量CRL来构造当前完整CRL. 如果当前时间在thisUpdate和nextUpdate字段中包含的时间之间, 则认为增量CRL是当前的. 在某些情况下, CRL颁发者可能在nextUpdate字段指示的时间之前发布一个或多个增量CRL. 如果遇到给定范围的多个当前增量CRL, 则应用程序应该 (SHOULD) 将thisUpdate中具有最新值的那个视为最新的.
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
BaseCRLNumber ::= CRLNumber
5.2.5. Issuing Distribution Point (颁发分发点)
颁发分发点是关键CRL扩展, 它标识特定CRL的CRL分发点和范围, 并指示CRL是仅涵盖终端实体证书的撤销、仅涵盖CA证书、仅涵盖属性证书, 还是仅涵盖有限的原因码集. 尽管此扩展是关键的, 但不要求符合标准的实现支持此扩展. 但是, 不支持此扩展的实现必须 (MUST) 将此CRL上未列出的任何证书的状态视为未知, 或定位不包含任何无法识别的关键扩展的另一个CRL.
CRL使用CRL颁发者的私钥签名. CRL分发点没有自己的密钥对. 如果CRL存储在X.500目录中, 它存储在与CRL分发点对应的目录条目中, 该条目可能与CRL颁发者的目录条目不同.
与分发点关联的原因码必须 (MUST) 在onlySomeReasons中指定. 如果onlySomeReasons不出现, 则分发点必须 (MUST) 包含所有原因码的撤销. CA可以使用CRL分发点根据泄露和常规撤销对CRL进行分区. 在这种情况下, 原因码为keyCompromise (1)、cACompromise (2) 和 aACompromise (8) 的撤销出现在一个分发点中, 而具有其他原因码的撤销出现在另一个分发点中.
如果CRL包含存在onlySomeReasons的issuingDistributionPoint扩展, 则CRL范围内被撤销的每个证书必须 (MUST) 被分配除unspecified之外的撤销原因. 分配的撤销原因用于确定在哪些CRL上列出撤销的证书, 但是, 不需要在相应的CRL条目中包含reasonCode CRL条目扩展.
distributionPoint字段的语法和语义与cRLDistributionPoints扩展 (第4.2.1.13节) 中的distributionPoint字段相同. 如果存在distributionPoint字段, 则它必须 (MUST) 至少包含此CRL范围内的每个证书的cRLDistributionPoints扩展的相应distributionPoint字段中的一个名称. 在证书和CRL的distributionPoint字段中必须 (MUST) 使用相同的编码.
如果distributionPoint字段不存在, 则CRL必须 (MUST) 包含CRL范围内CRL颁发者颁发的所有撤销的未过期证书的条目 (如果有).
如果CRL的范围仅包括CRL颁发者颁发的证书, 则indirectCRL布尔值必须 (MUST) 设置为FALSE. 否则, 如果CRL的范围包括CRL颁发者以外的一个或多个机构颁发的证书, 则indirectCRL布尔值必须 (MUST) 设置为TRUE. 每个条目的负责机构由证书颁发者CRL条目扩展 (第5.3.3节) 指示.
如果CRL的范围仅包括终端实体公钥证书, 则onlyContainsUserCerts必须 (MUST) 设置为TRUE. 如果CRL的范围仅包括CA证书, 则onlyContainsCACerts必须 (MUST) 设置为TRUE. 如果onlyContainsUserCerts或onlyContainsCACerts设置为TRUE, 则CRL的范围禁止 (MUST NOT) 包含任何版本1或版本2证书. 符合标准的CRL颁发者必须 (MUST) 将onlyContainsAttributeCerts布尔值设置为FALSE.
符合标准的CRL颁发者禁止 (MUST NOT) 颁发颁发分发点扩展的DER编码为空序列的CRL. 也就是说, 如果onlyContainsUserCerts、onlyContainsCACerts、indirectCRL和onlyContainsAttributeCerts都为FALSE, 则distributionPoint字段或onlySomeReasons字段必须 (MUST) 存在.
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
IssuingDistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE,
onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
-- 最多一个onlyContainsUserCerts、onlyContainsCACerts
-- 和onlyContainsAttributeCerts可以设置为TRUE.
5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution Point) (最新CRL,又名增量CRL分发点)
最新CRL扩展标识如何获取此完整CRL的增量CRL信息. 符合标准的CRL颁发者必须 (MUST) 将此扩展标记为非关键 (non-critical). 此扩展禁止 (MUST NOT) 出现在增量CRL中.
此扩展使用与cRLDistributionPoints证书扩展相同的语法, 并在第4.2.1.13节中描述. 但是, 在此上下文中只有分发点字段有意义. reasons和cRLIssuer字段必须 (MUST) 从此CRL扩展中省略.
每个分发点名称提供可以找到此完整CRL的增量CRL的位置. 这些增量CRL的范围必须 (MUST) 与此完整CRL的范围相同. 此CRL扩展的内容仅用于定位增量CRL; 内容不用于验证CRL或引用的增量CRL. 第4.2.1.13节中为分发点定义的编码约定适用于此扩展.
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
FreshestCRL ::= CRLDistributionPoints
5.2.7. Authority Information Access (授权信息访问)
本节定义授权信息访问扩展在CRL中的使用. 第4.2.2.1节中为证书扩展定义的语法和语义也用于CRL扩展.
此CRL扩展必须 (MUST) 标记为非关键 (non-critical).
当存在于CRL中时, 此扩展必须 (MUST) 至少包含一个指定id-ad-caIssuers作为accessMethod的AccessDescription. id-ad-caIssuers OID在可用信息列出可用于验证CRL上签名的证书 (即, 具有与CRL上颁发者名称匹配的主体名称并且具有与用于签署CRL的私钥相对应的主体公钥的证书) 时使用. 禁止 (MUST NOT) 包含id-ad-caIssuers以外的访问方法类型. 至少一个AccessDescription实例应该 (SHOULD) 指定accessLocation为HTTP [RFC2616] 或 LDAP [RFC4516] URI.
当信息通过HTTP或FTP可用时, accessLocation必须 (MUST) 是uniformResourceIdentifier, 并且URI必须 (MUST) 指向 [RFC2585] 中指定的单个DER编码证书或 [RFC2797] 中指定的BER或DER编码的"certs-only" CMS消息中的证书集合.
支持HTTP或FTP访问证书的符合标准应用程序必须 (MUST) 能够接受单个DER编码证书, 并且应该 (SHOULD) 能够接受"certs-only" CMS消息.
通过URI访问的HTTP服务器实现应该 (SHOULD) 在单个DER编码证书的响应的content-type头字段中指定媒体类型application/pkix-cert [RFC2585], 并且应该 (SHOULD) 在"certs-only" CMS消息的响应的content-type头字段中指定媒体类型application/pkcs7-mime [RFC2797]. 对于FTP, 包含单个DER编码证书的文件名应该 (SHOULD) 具有后缀".cer" [RFC2585], 包含"certs-only" CMS消息的文件名应该 (SHOULD) 具有后缀".p7c" [RFC2797]. 使用客户端可以使用媒体类型或文件扩展名作为内容的提示, 但不应该仅依赖于服务器响应中存在正确的媒体类型或文件扩展名.
当accessLocation为directoryName时, 应用程序将从本地配置的任何目录服务器获取信息. 当一个CA公钥用于验证证书和CRL上的签名时, 所需的CA证书存储在 [RFC4523] 中指定的crossCertificatePair和/或cACertificate属性中. 当不同的公钥用于验证证书和CRL上的签名时, 所需的证书存储在 [RFC4523] 中指定的userCertificate属性中. 因此, 支持accessLocation的directoryName形式的实现必须 (MUST) 准备在这三个属性中的任何一个中找到所需的证书. 应用程序用于访问目录的协议 (例如, DAP或LDAP) 是本地事务.
当信息通过LDAP可用时, accessLocation应该 (SHOULD) 是uniformResourceIdentifier. LDAP URI [RFC4516] 必须 (MUST) 包含包含保存证书的条目的可辨别名称的<dn>字段, 必须 (MUST) 包含列出保存DER编码证书或交叉证书对的属性的适当属性描述的<attributes>字段 [RFC4523], 并且应该 (SHOULD) 包含<host> (例如, <ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>). 省略<host> (例如, <ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary>) 的效果是依赖于客户端可能具有的任何先验知识来联系适当的服务器.
5.3. CRL Entry Extensions (CRL条目扩展)
ISO/IEC、ITU-T和ANSI X9为X.509 v2 CRL定义的CRL条目扩展提供了将附加属性与CRL条目关联的方法 [X.509] [X9.55]. X.509 v2 CRL格式还允许社区定义私有CRL条目扩展以携带这些社区特有的信息. CRL条目中的每个扩展可以指定为关键 (critical) 或非关键 (non-critical). 如果CRL包含应用程序无法处理的关键CRL条目扩展, 则应用程序禁止 (MUST NOT) 使用该CRL来确定任何证书的状态. 但是, 应用程序可以忽略无法识别的非关键CRL条目扩展.
以下小节介绍互联网CRL条目中使用的推荐扩展和信息的标准位置. 社区可以选择使用额外的CRL条目扩展; 但是, 在采用可能在一般上下文中使用的CRL中的任何关键CRL条目扩展时应谨慎行事.
此规范中定义的CRL条目扩展的支持对于符合标准的CRL颁发者和应用程序是可选的. 但是, 每当此信息可用时, CRL颁发者应该 (SHOULD) 包含原因码 (第5.3.1节) 和无效日期 (第5.3.2节).
5.3.1. Reason Code (原因码)
reasonCode是非关键CRL条目扩展, 它标识证书撤销的原因. 强烈鼓励CRL颁发者在CRL条目中包含有意义的原因码; 但是, 原因码CRL条目扩展应该 (SHOULD) 不存在而不是使用unspecified (0) reasonCode值.
removeFromCRL (8) reasonCode值只能出现在增量CRL中, 并指示应从CRL中删除证书, 因为证书过期或从暂挂中删除. 所有其他原因码可以出现在任何CRL中, 并指示应将指定的证书视为已撤销.
id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
-- reasonCode ::= { CRLReason }
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
-- 值7未使用
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }
5.3.2. Invalidity Date (无效日期)
无效日期是非关键CRL条目扩展, 它提供已知或怀疑私钥被泄露或证书以其他方式失效的日期. 此日期可能早于CRL条目中的撤销日期, 撤销日期是CA处理撤销的日期. 当CRL颁发者在CRL中首次发布撤销时, 无效日期可能早于较早CRL的颁发日期, 但撤销日期不应该 (SHOULD NOT) 早于较早CRL的颁发日期. 每当此信息可用时, 强烈鼓励CRL颁发者与CRL用户共享它.
此字段中包含的GeneralizedTime值必须 (MUST) 以格林威治标准时间 (Zulu) 表示, 并且必须 (MUST) 按第4.1.2.5.2节中定义的方式指定和解释.
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
InvalidityDate ::= GeneralizedTime
5.3.3. Certificate Issuer (证书颁发者)
此CRL条目扩展标识与间接CRL中条目关联的证书颁发者, 即在其颁发分发点扩展中设置了indirectCRL指示符的CRL. 当存在时, 证书颁发者CRL条目扩展包括与CRL条目对应的证书的issuer字段和/或颁发者备用名称扩展中的一个或多个名称. 如果此扩展不存在于间接CRL中的第一个条目上, 则证书颁发者默认为CRL颁发者. 在间接CRL的后续条目上, 如果此扩展不存在, 则条目的证书颁发者与前一个条目的证书颁发者相同. 此字段定义如下:
id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
CertificateIssuer ::= GeneralNames
符合标准的CRL颁发者必须 (MUST) 在此扩展中包含与此CRL条目对应的证书的issuer字段中的可辨别名称 (DN). DN的编码必须 (MUST) 与证书中使用的编码相同.
CRL颁发者必须 (MUST) 将此扩展标记为关键 (critical), 因为忽略此扩展的实现无法正确地将CRL条目归属于证书. 此规范推荐 (RECOMMENDS) 实现识别此扩展.