组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：张海斌（netdebug internetdebug@elong.com ）
译文发布时间：2001-7-14
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。
Network Working Group R. Housley
Request for Comments: 2459 SPYRUS
Category: Standards Track W. Ford
VeriSign
W. Polk
NIST
D. Solo
Citicorp
January 1999
Internet X.509 公钥基础设施
证书和CRL简介
（Internet X.509 Public Key Infrastructure
Certificate and CRL Profile）
备忘录现状
这份文档需要Internet社区进一步讨论和改进的Internet试验标准协议。关于这份文档
的标准化情况和状态请参阅"Internet官方协议标准"（STD1）组织的当前版。这份备忘录分
发不受限制。
版权声明
Copyright （C） The Internet Society （1999）。版权所有。
摘要
这份备忘录描述了应用在Internet中的X.509 v3证书和X.509 v2CRL（证书撤销列表），
以接近的综述和模型引入介绍。X.509 v3证书格式随着关于Internet名字（例如IP地址）的
格式和语义学附加信息被描绘。标准证书扩展被描绘和新的Internet-specific（特有扩展）被
定义。一套证书扩展被指定。同时X.509 v2 CRL格式被描绘和一套扩展被定义。一组X.509
证书路径确认算法被描述。X.509证书中通用Internet公开密钥密码算法（即RSA，DSA和
Diffie-Hellman）的公开密钥和数字签名的格式在补充信息中提供描述。ASN.1模块和例子
在附录中提供。
约定：
本文中的关键词"MUST"， "MUST NOT"， "REQUIRED"， "SHALL"， "SHALL NOT"，
"SHOULD"， "SHOULD NOT"， "RECOMMENDED"， "MAY"， 以及"OPTIONAL"与
RFC 2119【3】中的描述的意义是相同的。
请把对本文的意见邮寄给ietf-pkix@imc.org邮递清单。
译者的话
阅读RFC2459的读者应该首先了解一下有关网络安全方面的知识，例如密码学知识（加
密、解密、签名、验证以及安全协议等），RFC2459文档中出现的所有数据结构均采用ASN1
语法描述以及编码与解码（具体的实现也是这样），所以读者最好对ASN1语言比较熟悉。
RFC2459是RFC分类中的试验性文档，描述了Internet X.509公钥基础设施证书和CRL方
面的知识，文档涉及的内容很多（文档中很多内容是建议性的），具体的细节论述的比较少，
感兴趣的读者可以以此文档为基础指导性地去了解、学习、研究其相关内容的细节，因为这
篇文档叙述的内容比较全面。
译者在翻译这篇文档时尽量保留原文的原意，采用直译的方式，对晦涩难懂或者有指导
性的阅读其他内容的地方均有译者的注释，希望对读者有所帮助。由于翻译的时间较短以及
译者水平有限，译文中一定会有很多不当及疏漏甚至错误的地方，希望读者来信赐教，谢谢。
张海斌
2001-7-9
目 录
1介绍 5
2要求和假定 6
2.1通讯和拓扑 6
2.2可以接受的标准（Acceptability Criteria） 6
2.3用户期望 7
2.4行政管理人员期望 7
3 概览 7
3.1 X.509 v3证书 8
3.2证书路径和信任 9
3.3撤销 10
3.4操作协议 11
3.5管理协议 11
4证书和证书扩展项概要 12
4.1基本证书字段 13
4.1.1证书字段 14
4.1.1.1 tbsCertificate 14
4.1.1.2 signatureAlgorithm 14
4.1.1.3 signatureValue 15
4.1.2 TBSCertificate 15
4.1.2.1版本 15
4.1.2.2序列号 15
4.1.2.3签名 16
4.1.2.4发行者 16
4.1.2.5有效性 19
4.1.2.5.1 UTCTime 19
4.1.2.5.2 GeneralizedTime 19
4.1.2.6主题 20
4.1.2.7主题公开密钥信息 20
4.1.2.8唯一标识符 21
4.1.2.9扩展 21
4.2标准证书扩展 21
4.2.1标准扩展 22
4.2.1.1权威密钥标识符 22
4.2.1.2主题密钥标识符 23
4.2.1.3 密钥使用 24
4.2.1.4私有密钥使用周期 25
4.2.1.5证书策略 26
4.2.1.6策略映射 28
4.2.1.7主题可替换名字 28
4.2.1.8发行者可替换名字 30
4.2.1.9主题目录服务系统属性 30
4.2.1.10基本约束 31
4.2.1.11名字约束 31
4.2.1.12策略约束 33
4.2.1.13扩大密钥使用领域 33
4.2.1.14 CRL发布点 35
4.2.2私有Internet扩展 35
4.2.2.1权威信息存取 36
5 CRL和CRL扩展简介 37
5.1 CRL字段 37
5.1.1 CertificateList字段 38
5.1.1.1 tbsCertList 38
5.1.1.2 signatureAlgorithm 39
5.1.1.3 signatureValue 39
5.1.2证书列表" To Be Signed" 39
5.1.2.1版本 39
5.1.2.2签名 40
5.1.2.3发行者名字 40
5.1.2.4更新 40
5.1.2.5下次更新 40
5.1.2.6撤销证书 41
5.1.2.7扩展 41
5.2 CRL扩展 41
5.2.1权威密钥标识符 42
5.2.2发行者可替换名字 42
5.2.3 CRL Number 42
5.2.4 Delta CRL标识符 43
5.2.5发行发布点 43
5.3 CRL入口扩展 44
5.3.1理由代码 44
5.3.2保持指示代码 45
5.3.3无效日期 45
5.3.4证书发行者 46
6证书路径批准 46
6.1基本路径批准 47
6.2扩展路径批准 50
7算法技术支持 50
7.1个单向哈希函数 50
7.1.1 MD2单向哈希函数 51
7.1.2 MD5单向哈希函数 51
7.1.3 SHA1单向哈希函数 51
7.2签名算法 51
7.2.1 RSA签名算法 52
7.2.2 DSA签名算法 53
7.3主题公开密钥算法 53
7.3.1 RSA密钥 54
7.3.2 Diffie-Hellman密钥交换密钥 54
7.3.3 DSA签名密钥 56
8参考资料 57
9知识产权 59
10安全考虑 59
附录A. PsuedoASN.1结构和OIDs 61
A.1 明示目标模块（Explicitly Tagged Module），1988句法 61
A.2 隐式目标模块（Implicitly Tagged Module）, 1988 句法 76
附录 B. 1993 ASN.1 结构 and OIDs 83
B.1 明示目标模块（Explicitly Tagged Module）, 1993 句法 83
B.2 隐示目标模块（Implicitly Tagged Module）, 1993 句法 101
附录 C. ASN.1 注解 109
附录 D. 示例 110
D.1 证书 111
D.2 证书 114
D.3 RSA算法终端证书 117
D.4 证书撤销列表 121
附录 E. Authors' Addresses 122
附录F.完整版权声明 123
1介绍
本文作为Internet中X.509公开密钥基础设施（PKI）标准家族的一部分，同时也是独
立的文件；另外这套标准的执行可能继续同其他部分分开。
本文介绍了应用于Internet PKI证书和证书撤销列表的格式和语义学。描述了在Internet
环境中证书路径的处理，提供密码学算法的编码规则。最后，在附录中以ASN.1语法形式
描述了本文出现的所有数据结构定义。
本文描绘了能激起完善本文档的激情和影响它的在部分2中（范围）的假定。第3段引
见一个结构的模块以及描绘它们和前一IETF和ISO/IECITU标准的关系。特别是本文IETF
PEM描述和ISO/IEC ITU X.509文档之间的关系。
本文在部分4中介绍了X.509 v3证书；在部分5中介绍了X.509 v2证书撤销列表（CRL）。
包括在Internet PKI中有效的ISO/IEC/ITU和ANSI扩展的定义。本文使用的是1988年定义
的摘要句法注释1（ASN.1），而不是在1994年在ISO/IEC/ITU定义的语法标准。
本文还在部分6中说明了路径确认过程。这些过程基于在ISOIEC/ITU上的定义，但是
颁发假定一个或多个自我签名受信任的CA证书，只需要得到同样的结果，而不需要制定具
体的处理过程。
本文第7部分描绘公开密钥内容和数字签名的确认和编码的过程。不需要任何特别的密
码学算法，然而需要能识别出（这些）算法，这些算法能被识别出并可编码。
最后，四个附录中提供了implementers（应用）帮助。附录A包含所有的在本文说明以
内或者推荐的ASN.1结构。正如上面所说的，这些数据结构的描述应用1988的摘要语法注
释1（ASN.1），而不是1994的句法。附录B包含了同样的信息，这些信息使用作为更新的
toolsets（工具集）的implementers（应用）服务的1994 ASN.1注释。但是，附录A采取时
间次序以防冲突。附录C包含关于在本文说明以内使用ASN.1注释的不那么熟悉特征的笔
记。附录D含有证书和CRL的例子。
2要求和假定
本文的目标是提供帮助，以方便在那些Internet社区内希望利用X.509技术申请X.509
证书的使用。这些应用包括WWW、电子邮件、用户证明和Ipsec等。为了减轻某些使用
X.509证书的障碍，本文定义了促进证书管理系统发展的轮廓；应用工具的发展；和按照可
由双方共同制定的策略。
为了附加（额外）批准，保证或者操作上的要求符合专门的应用领域、或者环境的要求，
一些社区将需要补充、或许取代本文的（某些）描述。但是，为了基本应用，那些经常用的
属性和共用的代表被定义出来，以便应用开发者能得到必要知识，而不管证书或者证书撤销
列表（CRL）的发行者。
在信赖之前，一个证书用户应该浏览证书策略，由证书权威机构（CA，以下统称CA）
所产生的授权或者非拒绝服务，这些服务和一个特定证书中的公开密钥联系起来。为此目的，
这标准不定义合法捆绑的规则或者职责。
当补充授权和属性管理工具出现时，例如属性证书，它适合限制在一张证书内的授权的
属性证明。这些（其它的、辅助的）管理工具可以提供表达很多属性授权的更适合方法。
2.1通讯和拓扑
使用证书的用户将在关于他们的通讯拓扑环境中，特别是安全电子邮件的用户的宽阔范
围中操作。本文支持那些没有高带宽，实时IP连接或者高连接可用（high connection
availability）的可能性用户。此外，本文允许防火墙或者（其他）过滤通讯设备的存在。
本文不假定X.500目录服务系统的展开。本文不禁止X.500目录服务系统的使用，但是
发布证书和证书撤销列表（CRLs）的（其他）另一手段可以被使用。
2.2可以接受的标准（Acceptability Criteria）
Internet公开密钥基础设施（PKI）的目标是要满足决定论（deterministic），自动化确认，
认证，存取控制授权功能的需求。支持这些服务是通过包含在证书中的属性，以及一些从属
的控制信息，例如证书中策略数据和证书路径约束。
2.3用户期望
Internet PKI的用户是在证书中使用客户软件和主题名字的人们和过程。他们包括那些
使用电子邮件的读者和作者，WWW浏览器客户，WWW服务器和路由器中Ipsec的密钥管
理。本文识别那些使用局限性平台和局限于老于世故和注意的用户自己。这个在极小用户配
置责任（例如受信任的CA密钥，规则），明确在证书中的平台使用约束，证书路径约束以
及自动的验证有效性功能，使其保护用户免受很多恶意行为。
2.4行政管理人员期望
和用户期望一样，Internet PKI是有结构地支持通常运作CAs的个体。为行政管理人员
提供无边际的选择以减少CA行政管理人员微妙错误造成的宽广损害结果的机会。同时，无
边际的选择造成处理和验证由CA中心签发证书的有效性软件的复杂化。
3 概览
下面是按照PKIX标准本文说明的假定结构模范视图。
+---+
| C | +------------+
| e | <-------------------->| End entity |
| r | Operational +------------+
| t | transactions ^
| | and management | Management
| / | transactions | transactions
| | | PKI users
| C | v
| R | -------------------+--+-----------+----------------
| L | ^ ^
| | | | PKI management
| | v | entities
| R | +------+ |
| e | <---------------------| RA | <---+ |
| p | Publish certificate +------+ | |
| o | | |
| s | | |
| I | v v
| t | +------------+
| o | <------------------------------| CA |
| r | Publish certificate +------------+
| y | Publish CRL ^
| | |
+---+ Management |
transactions |
v
+------+
| CA |
+------+
图1-PKI实体
这个模型组成部分包括：
? 末端实体（end entity）：PKI证书或者最终用户证书主题系统的用户；
? CA：证书授权中心；
? RA：证书登记中心，即一个可选的由CA委派的具有管理功能的代表系统；
? 存储：一个系统或者收集的分配系统，存储分配给末端实体的证书和CRLs以及服
务。
3.1 X.509 v3证书
公开密钥的用户将是对结合私有密钥被确定的远程主体（人或者系统），这些实体将使
用加密或者签名算法。信任是通过证书中公开密钥的使用而得到，证书是绑定公开密钥到主
题信息的数据结构。捆绑通过信任的CA数字签名的证书，CA可以基于这样的技术手段
（a.k.a.，posession的通过“挑战反应”协议证明）断言，或者有关一个按照主题断言的私
有密钥的描述上。每张证书在它的签名内容中都有生命期。因为每张证书的签名和生命期在
证书使用的客户端是独立检查的，证书能够（可以）在不受信任的通讯和服务器系统中传输
也能在证书使用系统中非安全存储。
ITU TX.509（过去CCITT X.509）或者ISO/IEC ITU9594-8定义一标准证书格式[X.509]，
首先在1988年作为X.500目录服务系统推荐的一部分出版。在1988标准中证书格式称为版
本1（v1）格式。当X.500在1993年修正的时候，在版本2（v2）格式中增加一额外的两个
字段。这两个字段可以使用来支持目录服务系统的存取控制。
在1993年出版的Internet隐私增强邮递（PEM）RFCs，包含在X.509 v1证书[RFC 1422]
的基础上公开密钥基础设施建立说明。在部署RFC 1422的尝试中获得经验明确表示v1和
v2证书格式在几个方面不足。最重要的是在PEM设计和应用经验已证明需要携带更多的信
息。面对这些新的要求，ISO IEC/ITU和ANSI X9开发了X.509版本3（v3）证书格式。v3
格式在v2基础上通过扩展添加额外的字段（扩展字段）。特殊的扩展字段类型可以在标准中
或者可以由任何组织或者社区定义和注册。在1996年6月，基本v3格式的标准化被完成
[X.509]。
同时ISO IEC/ITU和ANSI X9为在v3扩展字段[X.509][X9.55]中使用发展标准范围。这
些扩展能表达像附加主题确认信息、密钥属性信息、策略信息和证书路径约束这样的数据。
然而ISO IEC/ITU和ANSI X9标准扩展在他们的应用中是非常宽广的。为了开发Internet
使用X.509 v3系统可由双方共同操作的工具，指定一本文作为使X.509 v3扩展适合Internet
的使用是必要的。它是本文的一个目标，指定一本文作为Internet WWW，电子邮件和IPsec
应用。同时随着附加要求环境的改变可以建设本文或者可以取代它。
3.2证书路径和信任
作为安全服务的用户通常需要公开密钥如何获得以及需要公开密钥验证证书有效性方
面的知识。如果公开密钥用户还没有一份由CA签发的证书的公开密钥拷贝、CA的名字和
相关信息（例如有效期和名字约束），然后它可能需要一张附加证书得到公开密钥。一般地
说，需要经过CA签发的一系列多重证书公开密钥所有者（末端实体）和其它CAs签发的
零张或更多附加CAs证书。这样的链被称作证书路径，因为一个公开密钥用户仅用有限CA
的数目签发。
CAs可以有不同的方式被配置为了公开密钥用户能查找证书路径。在PEM，RFC 1422
定义了CAs的严格等级制度的结构。有三类型的PEM证明授权中心：
(a) Internet策略注册授权中心（IPRA）：这个授权中心，作为PEM证书等级制度的
根（等级1），预兆Internet社会的权力。为下一级发行证书，称为PCAs。所有
的证书路径以IPRA开始。
(b) 策略授权中心（PCAs）：每个PCA由IPRA等级制度中授权，PCAs在等级制定
中处于2级。PCA将建立和发表它关于确认用户或者下属认证权威（当局）策略
的声明。不同PCAs目标是符合不同用户的需要。例如，一PCA（一组织的PCA）
可以支持普遍电子邮件商业组织的需求，而另一PCA（一高保证（high-assurance ）
PCA）可以有一更严格策略设计去符合合法捆绑的数字的签名要求。
(c) 授权中心（CAs）：CAs是在等级制度的第3级，可能也是在低水平方面。在第3
级被PCAs授权。CAs代表特殊组织， 例如特定组织的单位（例如区，组织，
部门）或者特定地理区域。
此外RFC 1422还有一名字下级定义规则，其要求一CA仅能为名字是CA本身从属的
实体（在X.500命名树中）颁发证书。使用PCA名字意味着把信任和一PEM证书路径联系
起来。名字下级定义规则保证在PCA以下的CAs针对他们从属能验证的实体是敏感强迫的
（例如，一CA仅能验证在那个特定组织名字树中的实体）。证书用户系统有能力用机器检
查遵守名字下级定义的规则。
RFC 1422使用X.509 v1证书格式。X.509 v1的局限性要求征收对清楚地限制结合的策
略或者限制证书的功用的几个结构上。这些限制包含：
(a) 伴随所有的从IPRA开始的证书路径的纯粹上下（top-down）等级制度；
(b) 限制一CA的主题名字下级命名规则；以及
(c) 使用需要个人PCAs的知识构建证书逻辑的验证链条的概念。个人PCAs的知识
决定是否链条能被接受。
经过RFC 1422的呼吁请求使用证书扩展，使用X.509 v3不需要限制使用CA结构的使
用。特别是，和证书政策相关联的证书扩展排除PCAs的需要以及扩展约束排除下级名字定
义规则的需要。因此，本文支持更有弹性的证书结构，包含：
(a) 证书路径可以在一个用户的自己领域中CA的公开密钥或者等级制度顶部的公开
密钥开始。开始于一个用户的自己领域中CA的公开密钥确实有优势。在一些环
境中，本地领域是最受信任的。
(b) 名字约束可以通过在证书中的名字约束扩展的明确被接收，但不作为要求。
(c) 策略扩展和策略映射代替允许一定程度的自动化PCA概念。应用程序应该能决
定是否接受把证书路径建立在代替PCAs的先验知识的证书的目录的基础上。这
允许证书链条处理的自动化。
3.3撤销
当一张证书被颁发的时候，预期它是在它的整个有效期内使用。但是，各种各样境况可
能导致一张证书在有效期满期之前变得无效。这样境况包含名字的改变，在主题和CA之间
联合的改变（例如，一雇员结束在一个组织的工作），以及损害或者怀疑相应的私有密钥。
在这样情况下，CA需要撤销证书。
X.509定义一种证书撤销的方法。这方法需要CA周期性地发布称为证书撤销列表
（CRL）的由CA签名的数据结构。CRL是盖了时间印章的经过CA签名的自由发布长期有
效的能识别出被撤销证书的清单。每一个撤销证书在CRL中通过证书序列号识别出。当一
证书使用系统使用证书（例如，验证一个远程用户的数字签名），那个系统不仅需要检验证
书签名和有效性而且需要在最近发布的CRL中检验证书序列号不在其中。"最近发布"的意
思是可能随着本地策略改变，但是它通常意味着最近一次发行的CRL。CA按照正常周期（例
如，每隔一小时，每天或者每周）发行一次新的CRL。也有可能随着撤销通知的到来而发
布下一个新的信息被加入到CRL。这个时刻可能出现在一正常CRL发布周期之后不久，而
远离下一次发布的周期。
这种撤销算法的优势是CRLs可以准确地和证书发布同样的做法经由不受信任的通讯
和服务器系统传播。
CRL撤销算法的一个局限是在不受信任的通讯和服务器限制CRL颁发周期撤销的时间
粒度。例如，如果撤销现在发布，那撤销将不能保证通知证书应用系统，直到下一个周期
CRL被发布，这可能是一个小时、一天或者一星期，CA发行CRLs取决于频率。
和X.509 v3证书格式一样，为了便于（支持）从多重销售商共同操作的工具，X.509
v2CRL格式应该是为Internet使用描述轮廓。这是（指定）本文的一个目标。但是，本文不
要求CAs发行CRLs。支持联机（On-line）撤销通知信息格式和协议可以在其它PKIX文本
中定义（中找到）。撤销通知的联机方法可以是适用于一些可选择X.509 CRL的环境。联机
撤销检查可以在相当大的程度上减少在（一份）撤销报告之间和信息分配依赖双方的潜伏。
CA一旦接受的报告是可靠的和有效的，任何联机服务问题将正确反映出撤销的证书批准影
响。但是，这些方法需要新的安全要求；当仓库（repository）不应该受信任的同时，证书
生效者将指望联机批准服务。
3.4操作协议
操作协议要求将证书和CRLs （或者状况信息）传递给客户证书应用系统。为各种各
样的证书和CRL提供不同传递，包括基于LDAP、HTTP、FTP和X.500的发布过程。支持
这些操作的草案在其它PKIX文本说明中被解释。这些本文说明可以包含信息格式和支持全
部的上述操作的环境，包含适合MIME内容类型的定义或者参考过程的定义。
3.5管理协议
管理协议需要支持在PKI用户和管理实体之间联机相互作用。例如，管理协议随着相
关联的密钥对可以在CA和客户系统之间被使用，或者在两CAs之间的交叉认证。这套功
能应该潜在地按照管理协议支持，包含：
(a) 登记：这是一个过程，通过它用户自身先于CA发布证书给那个用户知道CA在
哪 （直接或者通过RA）。
(b) 初始化：在一客户系统能安全运作之前，把密钥安装在其适合储藏密钥的其它地
方是必要的。例如，客户应该安全地在受信任的CA（s）的公开密钥和另一被保
险人信息初始化有效证书路径方面被使用。此外，一个客户（典型）应该用它自
己的密钥对初始化。
(c) 认证：这是个过程，其中CA为一个用户的公开密钥发行一张证书，并且把那张
证书传递到用户的客户系统和/或在仓库中张贴那张证书。
(d) 密钥对恢复：作为一个选项，用户客户密钥（用于加密的用户私有密钥）可以被
CA或者密钥备份系统备份。如果用户需要恢复这些备份密钥，（例如，当忘记密
码或者失去密钥链文件的时候）一个支持这样恢复的联机交流协议是所需要的。
(e) 密钥对更新：所有的密钥对需要定期更新。例如，替换新的密钥对，发布新的证
书。
(f) 撤销请求：一个授权人通知CA要求将处于不正常处境的证书被撤销。
(g) 交叉认证：两CAs交换知识用于建立交叉认证证书。交叉认证证书是一张经过
一CA给另一个包括签名密钥的CA颁发的证书。
注意联机协议不是唯一的执行上述功能的方式，还有取得同样结果的离线方法，这在本
文说明为不托管联机协议的使用。例如，当硬件设备（hardware tokens）使用的时候，很多
功能可以作为物理设备传递的一部分而实现。此外，某些上述功能可以合并成为一种协议交
换（protocol exchange）。特别的，两个或者多个登记、初始化和证书功能可以合并为一种协
议交换。
PKIX系列的文本说明可以定义一套标准信息格式，支持上述功能的将来文本中说明。
如果那样，表达这些在不同环境中信息（例如联机、文件传输、e-mail和WWW）的协议将
在那些文本被描绘。
4证书和证书扩展项概要
这部分提出公开密钥证书概要，将帮助发展可由双方共同操作和可再用PKI体系。这
部分基于X.509 v3证书标准格式和在[X.509]上定义标准证书扩展。ISO IEC/ITU文件使用
1993版本的ASN.1语法；然而本文使用1988 ASN.1语法，但是证书编码和标准扩展是等同
的。这部分也定义支持Internet社区PKI体系的私有扩展。
证书可以在宽广的应用环境中使用，其覆盖宽广的可由双方共同操作为目标和更宽阔范
围中的操作上的和认证要求的环境。本文的目标是为宽广的由双方共同操作和有限特殊目的
要求的环境建立一条共用基线。特别是强调支持X.509 v3证书应用在非正式的Internet电子
邮件、IPsec和WWW上。
4.1基本证书字段
X.509 v3证书基本语法如下。为签名计算，将证书按照ASN.1语法（DER） [X.208]
规则进行编码传递。ASN.1 DER编码是对每个元素对应的标签、长度、值编码系统。
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate，
signatureAlgorithm AlgorithmIdentifier，
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1，
serialNumber CertificateSerialNumber，
signature AlgorithmIdentifier，
issuer Name，
validity Validity，
subject Name，
subjectPublicKeyInfo SubjectPublicKeyInfo，
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL，
-- If present， version shall be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL，
-- If present， version shall be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present， version shall be v3
}
Version ::= INTEGER { v1（0）， v2（1）， v3（2） }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore Time，
notAfter Time }
Time ::= CHOICE {
utcTime UTCTime，
generalTime GeneralizedTime }
UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier，
subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE （1..MAX） OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER，
critical BOOLEAN DEFAULT FALSE，
extnValue OCTET STRING }
下面几个小段的项目定义了在Internet中使用的X.509 v3证书。
4.1.1证书字段
证书是三个连串（SEQUENCE）的字段。这些字段将在下列部分中详细描绘。
4.1.1.1 tbsCertificate
这个字段含有主题和发行者的名字，主题联系起来的公开密钥，有效期和其他相关信息。
字段在部分4.1.2中详细被描述；字段tbscertificate也可以包括在部分4.2中描述的扩展项。
4.1.1.2 signatureAlgorithm
signatureAlgorithm字段含有CA签发证书使用的密码学算法标识符。第7.2段列出支持
的签名算法。
由下列的ASN.1结构确定一个算法标识符：
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER，
parameters ANY DEFINED BY algorithm OPTIONAL }
算法标识符用于识别出密码学的算法。算法标识符（OBJECT IDENTIFIER）成分识别
出（例如SHA 1的DSA）算法。可选参数字段的内容将根据识别出的算法改变。第7.2段
列出了本文支持的算法。
这个字段必须（MUST）含有在序列tbsCertificate（见4.1.2.3）中签名字段算法标识符
同样的算法标识符。
4.1.1.3 signatureValue
signatureValue字段包括对tbsCertificate的ASN.1 DER编码的数字签名。TbsCertificate
的ASN.1 DER编码作为签名函数的输入参数。这个签名结果值然后作为BIT STRING 类型
的ASN.1编码，并且包括在证书的签名字段中。这个过程在7.2段中针对每种支持算法（进
行了）详细描述。
通过产生数字签名，CA能证明在tbsCertificate字段中信息的有效性。特别是，CA能
够认证在证书中公开密钥和证书的主题的绑定。
4.1.2 TBSCertificate
序列TBSCertificate含有和CA发行证书的主题联系起来的信息。每一个TBSCertificate
含有主题和发行者的名字；以及和主题联系起来的公开密钥、有效期、版本号和序列号；一
些可选的唯一标识符字段。这部分余下的部分描述这些字段的句法和语义学。TBSCertificate
也可以包含扩展项。扩展部分在Internet PKI（在部分）4.2中被描绘。
4.1.2.1版本
这个字段描绘编码证书的版本。当扩展被使用的时候，如同在本文中预期那样，使用
X.509版本3（值是2）。但是如果没有扩展项，UniqueIdentifier将存在，这时使用版本2（值
是1）。如果仅仅基本字段存在，使用版本1（作为缺省值，版本号将在证书中删掉）。
（证书系统应用）工具应该（SHOULD）有准备接受任何版本的证书。最低限度，工
具（MUST）必须能够识别出第3版的证书。
第2版证书的产生不是本文预期的描述对象。
4.1.2.2序列号
序列号是CA给每一个证书分配一个整数。它必须（MUST）是特定CA签发的证书唯
一识别（即，发行者名字和序列号唯一识别一张证书）。
4.1.2.3签名
这字段含有算法标识符，这个算法是CA在证书上签名使用的算法。
这个字段必须（MUST）含有作为在序列Certificate （见4.1.1.2）中signatureAlgorithm
字段同样的算法标识符。可选参数字段的内容将根据识别出的算法改变。第7.2段列出支持
的签名算法。
4.1.2.4发行者
发行者字段用来标识在证书上签名和发行的实体。发行者字段必须（MUST）含有一非
空的能辨别出的名字（DN）。把发行者字段定义为X.501类型名字。[X.501]名字由下列的
ASN.1结构确定：
Name ::= CHOICE {
RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType，
value AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
DirectoryString ::= CHOICE {
teletexString TeletexString （SIZE （1..MAX）），
printableString PrintableString （SIZE （1..MAX）），
universalString UniversalString （SIZE （1..MAX）），
utf8String UTF8String （SIZE （1.. MAX）），
bmpString BMPString （SIZE （1..MAX）） }
名字（Name）描绘了一等级制度的名字属性组成，例如国家名字和对应的值，例如US。
类型AttributeValue的成分由AttributeType决定；一般地说它将是一DirectoryString（类型）。
DirectoryString类型定义为一个对PrintableString、TeletexString、BMPString、UTF8String
和UniversalString（类型）的选择。UTF8String编码是DirectoryString的首选编码，以及所
有的在2003年12月31日之后签发的证书必须（MUST）使用UTF8String编码（正如同下
面指出那样）。直到那日期，当创建一个可辨别的名字时CAs必须（MUST）在下列的选择
中挑选，包括他们自己：
（a） 如果字符集是足够的，字符可以（MAY）被描述为一PrintableString；
（b） 失败（a），如果BMPString字符集是足够的，字符可以被描述为一BMPString；
和
（c） 失败（a）和（b），字符必须（MUST）被描述为一UTF8String。如果（a）
或者（b）是满足的，CA可以（MAY）仍然宁愿选择把字符描述为一
UTF8String。
2003年12月31日 UTF8编码要求的例外如下：
（a） CAs可以（MAY）签发“名字滚翻”（"name rollover"）支持一向UTF8String
编码整齐的迁移证书。这样证书将包含CA的作为发行者UTF8String编码名
字和作为主题的老名字编码，或者反之亦然。
（b） CAs在部分4.1.2.6中表明，主题字段必须（MUST）存在由主题CA不管如
何编码签发的所有证书中发行者字段的内容相配的一非空的可识别名字。
TeletexString和UniversalString为向后兼容（性）被包含，并且不应该为新主题的证书
使用。但是，这些类型可以在名字以前就存在的证书中被使用。证书用户应该（SHOULD）
是有准备的以这些类型接受证书。
此外，很多遗留工具支持名字在ISO 8859-1字符集（Latin1String）中的编码，但是使
用TeletexString作为他们的标签。Latin1String包含在西方欧洲人国家中使用并不是部分
TeletexString 字符集的字符。加工TeletexString的工具应该（SHOULD）是有准备的处理整
个ISO 8859-1字符集。[ISO 8859-1]
同样，可识别名字由属性组成。本文说明不限制可以出现在名字的属性类型。但是，工
具必须（MUST）是有准备的以发行者名字接受证书，发行者名字含有下面确定的属性类型。
本文说明也支持额外的属性类型。
标准套装属性被定义在X.500系列的文档中。本文说明的[X.520]工具必须（MUST）是
有准备接受在发行者名字中（包括的）下列标准属性类型：国家、组织、组织的单位
（organizational-unit）、限定语的可识别名字、国家或者省名字和普通名字（common name）
（例如" Susan Housley"）。此外，本文说明的工具应该（SHOULD）是有准备的收到下列的
在发行者名字中标准属性类型：地区、题目、姓、名字、开头的字母和产生限定语（例如"Jr.""，
3rd"或者"IV"）。这些属性类型句法和相结合对象标识符（OIDs）在附录A和B中ASN.1模
块中提供说明。
此外，本文说明的工具必须（MUST）是有准备的如同[RFC 2247]定义的那样接受
domainComponent属性。域名（Nameserver）系统（DNS）提供为系统贴上标签等级制度的
方法。这个属性提供为希望使用DNS和他们的DNS名字平行的组织一个方便的机制。这不
是用作替换名字字段的dNSName成分的替代。工具不需要把这样名字变成DNS名字。这
属性类型句法和相结合的OID在附录A和B中ASN.1模块中提供。
证书用户必须（MUST）是有准备处理发行者可识别名字和主题识别名字（见4.1.2.6）
去执行证书有效路径的名字链（部分6）。名字链由相匹配的随CA证书主题名字的在一张
证书中可识别的名字签发者执行。
本文说明仅要求在X.500系列文档中指定功能相似的一子集名字。使工具遵照的要求如
下：
（a） 可以被假定代表不同字符，属性值在不同类型（例如PrintableString和
BMPString）中编码；
（b） 除了PrintableString类型，属性值是区分大小写的（这个允许属性值和二进
制对象匹配）；
（c） 在PrintableString中属性值不区分大小写（例如，" Marianne Swanson"和"
MARIANNE SWANSON"相同）；和
（d） 在去除头部和尾部的空格以及去转换在内部子串中一个或多个连续空格为一
个单一的空格后，在PrintableString中属性值可被比较。
这些名字比较规则允许一个证书用户验证使用证书用户所不熟悉的语言或者编码签发
的证书的有效性。
此外，本文说明的工具可以（MAY）使用这些比较规则为名字链处理不熟悉的属性类
型。这允许工具随着在发行者名字中不熟悉的属性处理证书。
注意在X.500系列文档中定义的比较规则指出用于在可识别名字中数据编码的字符集
是无关紧要的。字符（他们）自身被比较而不关心编码。允许本文的工具使用定义在X.500
系列文档中的比较算法。这样工具将通过前面指定算法认出相匹配的名字超集。
4.1.2.5有效性
证书有效期是时间间隔，在这期间CA保证它将保持关于证书的状况的信息。把字段描
述为一连串（SEQUENCE）的两个日期：日期证书有效期开始（notBefore）和日期证书有
效期结束（notAfter）。notBefore和notAfter可以作为UTCTime或者GeneralizedTime类型编
码。
在本文中CAs必须（MUST）在2049年以前证书有效日期总是作为UTCTime类型编
码；在2050年或者以后证书有效性日期必须（MUST）作为GeneralizedTime类型编码。
4.1.2.5.1 UTCTime
世界时间（universal time）类型，UTCTime是作为国际应用的一标准ASN.1类型，因
为本地时间不适合国际应用。UTCTime通过两个低次序数字指定年以及指定精确（性）到
一分钟或者一秒钟。UTCTime包含（Zulu或者格林威治标准时间）Z或者一时间微分。
在本文描述中，UTCTime值必须（MUST）是格林威治标准时间表示（Zulu）并且必须
（MUST）包含秒（即，时间（格式）是YYMMDDHHMMSSZ），甚至秒的数目等于零。
系统必须（MUST）如下解释年字段（YY）：
当YY大于等于50，年将被认为是19YY；和
当YY不到50，年将被认为是20YY。
4.1.2.5.2 GeneralizedTime
普遍时间类型，GeneralizedTime为时间的可变精确性的标准ASN.1类型。随意地，
GeneralizedTime字段能包含一在本地和格林威治标准时间之间时间微分的代表。
为了本文的目标，GeneralizedTime值必须（MUST）是格林威治标准时间表示（Zulu）
并且必须（MUST）包含秒（即，时间格式是YYYYMMDDHHMMSSZ），甚至其秒的数目
等于零。GeneralizedTime值必须不（MUST NOT）包含小数部分秒（fractional seconds）。
4.1.2.6主题
主题字段标识符与存储在主题公开密钥字段中相关联的密钥实体。主题名字和/或在
subjectAltName扩展中被附带。如果主题是一CA（例如，如同在4.2.1.10讨论那样，基本
约束扩展存在和cA的值是真的（TRUE）），那么主题字段必须（MUST）是随着一非空的
可识别的名字存在，在所有的主题CA签发的证书和发行者字段（见4.1.2.4）的目录相匹配。
如果主题命名信息仅存在subjectAltName扩展（例如一把密钥局限于一电子邮件地址或者
URI）中，那么主题名字必须（MUST）是一空的序列并且subjectAltName扩展一定是关键
的。
在它非空的地方，主题字段必须（MUST）含有一X.500可识别名字 （DN）。DN必须
（MUST）对于每一主题实体是唯一的通过被签发者名字字段定义的一CA证明。一CA可
以用同样的DN向同样的主题实体签发多个证书。
主题名字字段定义为X.501类型名字。工具（应用）要求这字段是那些签发者字段定义
的 （见4.1.2.4）。当将类型DirectoryString的属性值编码的时候，关于签发者字段的编码规
则必须（MUST）被执行。本文说明的工具一定是有准备的接收包含为签发者字段推荐的属
性类型的主题名字。本文说明的工具应该（SHOULD）是有准备的接收含有为签发人字段
建议属性类型的主题名字。这些属性类型句法和相结合的对象标识符（OIDs）在附录A和
BASN.1模块中被提供。本文说明的工具可以（MAY）使用这些相似规则去处理不熟悉属性
类型（例如，对于名字链条）。这允许工具在不熟悉属性的主题名字中处理证书。
此外，遗留工具存在于一RFC 822名字作为EmailAddress属性被嵌入在可识别的名字
中。作为IA5String类型的EmailAddress属性值允许包含字符'@'，其不在PrintableString字
符集中。EmailAddress属性值是不区分大小写的（例如，"fanfeedback@redsox.com"与
FANFEEDBACK@REDSOX.COM是一样的）。
随着电子邮件地址使产生新证书工具必须（MUST）在主题字段可能的选择中使用
rfc822Name （见4.2.1.7）的名字描绘。同时包含在主题中可识别名字的EmailAddress属性
值去支持遗留工具被反对，但是允许（即不禁止）。
4.1.2.7主题公开密钥信息
使用这字段携带公开密钥和密钥使用算法的标识符。算法使用在部分4.1.1.2中指定
AlgorithmIdentifier结构被标识。在部分7.3中指定对象标识符作为将公开密钥材料（公开密
钥和参数）支持的编码算法和方法。
4.1.2.8唯一标识符
这些字段可能仅出现在版本2或者3中（见4.1.2.1）。主题和发行者的唯一标识符存在
于证书中去处理在超出（有效）时间主题和/或发行者名字的再使用的可能性。本文推荐名
字不在不同实体中重用以及Internet证书唯一标识符不被使用。CAs遵从本文不应该
（SHOULD NOT）使用唯一标识符产生证书。遵从本文应用（程序）应该（SHOULD）是
能解析唯一标识符的语法并且作比较。
4.1.2.9扩展
这字段可能如果仅出现在版本3（见4.1.2.1）中。如果存在，这字段是一连串
（SEQUENCE）的一个或多个证书扩展。在Internet PKI中证书扩展的格式和内容将在4.2
定义。
4.2标准证书扩展
在X.509 v3证书扩展定义中提供为用户或者公开密钥和证书管理等级制度相结合的附
加属性的方法。X.509 v3证书格式也允许社区（一个具体应用环境――译者注）定义私有范
围为那些社区携带所特有信息。在一张证书中的每一扩展可以是关键的或者非关键的。如果
遇到一项不能识别的关键扩展，那么应用系统必须（MUST）拒绝接受此证书；但是，如果
不被认出的项是非关键扩展则可以被忽视。下面章节推荐在Internet证书和标准信息以内使
用扩展。然而社区可以选择使用附加扩展（针对具体应用环境的自定义扩展――译者注）；
但是，应该谨慎采用在证书中的任何关键扩展，其可以阻碍在一般背景（证书比较普遍的应
用环境――译者注）中的证书应用。
每一项扩展包含一OID和一ASN.1结构。当一扩展出现在一张证书中的时候，OID作
为字段extnID和相应的ASN.1结构按照八位字符（octet string ）extnValue的值编码。仅一
特定扩展的事例可以出现在一张特定证书中。例如，一张证书可以含有仅一当局密钥标识符
扩展（见4.2.1.1）。一扩展包含boolean类型关键值，缺省值为FALSE。文本为每一扩展指
定可接受作为关键字段的值。
CAs必须（MUST）支持密钥标识符（见4.2.1.1和4.2.1.2）、基本约束（见4.2.1.10）、
密钥应用（见4.2.1.3，）和证书策略（见4.2.1.5）扩展。如果CA颁发空序列主题证书，CA
必须（MUST）支持可选择的名字扩展 （见4.2.1.7）。支持余下的扩展是可选的。CAs可以
支持在本文说明以内不被识别的扩展标识符；提醒证书发行者把这样的扩展标记关键可以抑
制双方的共同操作。
最低限度，本文的应用必须（MUST）能够识别在本文中必须或者可能的扩展。这些扩
展是：密钥应用（见4.2.1.3）、证书策略（见4.2.1.5）、主题可替换名字（见4.2.1.7）、基本
约束（见4.2.1.10）、名字约束（见4.2.1.11）、策略约束（见4.2.1.12）和密钥应用扩展（见
4.2.1.13）。
此外，本文推荐（RECOMMENDS）支持权威和主题密钥标识符（见4.2.1.1和4.2.1.2）
的应用扩展。
4.2.1标准扩展
这部分介绍在Internet PKI应用中[X.509]定义的标准证书。[X.509] 定义中的每一扩展
和一OID联系起来。这些OIDs 是id-arc的成员，定义如下：
译者注：OID是OBJECT IDENTIFIER（对象标识符）的简称，其是国际性组织定义的全球
标准的对象定义，是一树结构，id-arc是树结构中ISO组织定义的一枝，感兴趣的
读者请阅读相关文档。
id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt（2） ds（5） 29}
4.2.1.1权威密钥标识符
权威密钥标识符扩展提供一识别出对使用私有密钥在一张证书上签名相对应的公开密
钥的手段。这个扩展用于一个发行者有多个签名密钥（也由于多重同时发生的密钥对或者由
于密钥更换）。标识符可以建立在任一个密钥标识符（在发行者的证书中的主题密钥标识符）
或者有关发行者名字和序列号的基础上。
authorityKeyIdentifier扩展的keyIdentifier字段必须（MUST）是包含在所有的由CAs
遵照便于链条构建所产生的证书内。有一例外：一CA以一张"自我签名"证书的形式分配它
的公开密钥，权威密钥标识符可以被删掉。在这个情况中，主题和权威密钥标识符将是完全
相同的（等价的）。
keyIdentifier字段的值应该（SHOULD）从验证证书签名的公开密钥或者产生唯一值的
方法中得到（keyIdentifier字段的值产生算法――译者注）。两个从公开密钥产生密钥标识符
的通用方法描述在4.2.1.2。一个产生唯一值的通用方法在4.2.1.2中描述。因为一个密钥标
识符还没有先前建立，本文推荐使用这些方法中的一种产生keyIdentifiers。
本文推荐（使用）经过所有的证书用户支持密钥标识符的算法。
这扩展必须不（MUST NOT）要被标记为关键。
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
4.2.1.2主题密钥标识符
主题密钥标识符扩展提供一种识别出包含一特定公开密钥的证书的手段。
为了便于链条（证书链）构建，这个扩展必须（MUST）出现在所有CA证书中，也就
是说所有证书中包含基本约束扩展证书（见4.2.1.10）它的cA的值是TRUE。主题密钥标识
符的值必须（MUST）是按照这张证书的主题值放入权威密钥标识符扩展（见4.2.1.1）的证
书的发出的密钥标识符字段。
同CA证书一样，主题密钥标识符应该（SHOULD）从公开密钥或者产生唯一值方法中
得到。两种从公开密钥产生密钥标识符的通用方法如下：
（1） keyIdentifier由BIT STRING subjectPublicKey的值的160位SHA1哈希值
组成（排除标签，长度和不在使用的bits数目）。
（2） keyIdentifier 四bit类型字段值为0100以及随后的由BIT STRING
subjectPublicKey的值SHA 1哈希的值中最后60 bits连接组成。
一个产生唯一值通用方法是一整数的monotomically递增序列。
为末端实体证书，主题密钥标识符扩展提供一识别出包含在一种应用中使用特定公开密
钥的证书的手段。一末端实体已经得到多重证书，特别从多重CAs，主题密钥标识符提供一
迅速识别出包含一特定公开密钥证书的手段。为帮助在应用方面识别适合末端实体证书，这
扩展应该包含在所有的末端实体证书内。
为末端实体证书，主题密钥标识符应该（SHOULD）从公开密钥得到。从公开密钥产
生密钥标识符的两个通用方法在上面描述了。
因为一个密钥标识符还没有先前建立，本文说明推荐使用这些方法中的一种产生密钥标
识符。
这扩展必须不（MUST NOT）要标记为关键。
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier
4.2.1.3 密钥使用
密钥使用扩展定义包含在证书的密钥的目的（例如加密，签名，签名证书）。当一把能
被用于超出一个操作时候（超出了密钥应用范围――译者注），密钥使用限制可以被使用。
例如，当一RSA密钥应该是仅用于签名使用的时候，digitalSignature和/或nonRepudiation
位（bits）将被断言（有效，置为1――译者注）。同样，当一RSA密钥应该是仅用于密钥
管理使用的时候，keyEncipherment位将被断言。当使用的时候，这扩展应该（SOULD）被
标记为关键。
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
KeyUsage ::= BIT STRING {
digitalSignature （0）,
nonRepudiation （1）,
keyEncipherment （2）,
dataEncipherment （3）,
keyAgreement （4）,
keyCertSign （5）,
cRLSign （6）,
encipherOnly （7）,
decipherOnly （8） }
在KeyUsage类型中位（Bits）使用如下：
digitalSignature位被断言，当主题公开密钥用一数字的签名算法来支持安全服务而非抗
抵赖性（位1）、签名证书（位5）或者签名撤销信息（位6） 的时候。数字的签名算法常
常为实体和数据起源（做）完整性验证。
nonRepudiation位被断言，当主题公开密钥被用于验证提供抗抵赖性服务的数字签名的
时候，其签名实体避免虚假拒绝的一些行动所造成的危害，这些行动排除签名证书或者
CRL。
keyEncipherment位被断言，当主题公开密钥被用于密钥传输的时候。例如，当一RSA
密钥用于密钥管理时候，那么这位将被断言。
当主题公开密钥用于（除了密码学的密钥）将用户数据加密使用的时候，
dataEncipherment位被断言。
keyAgreement位被断言，当主题公开密钥为用于密钥协议的时候。例如，当一Diffie
Hellman密钥是要为密钥管理被使用的时候，那么这位将被断言。
当主题公开密钥用于验证在证书上的签名使用的时候，keyCertSign位被断言。这位可
以仅在CA证书中被断言。
当主题公开密钥用于验证有关撤销信息（例如一CRL）签名使用的时候，cRLSign位被
断言。
encipherOnly位的意思是在没有keyAgreement位（缺席）时定义的。当encipherOnly
位被断言和keyAgreement位也被设定的时候，主题公开密钥可以仅用于将数据加密（加密）
被使用，同时履行密钥协议。
decipherOnly位的意思是在没有keyAgreement位（缺席）时定义的。当decipherOnly
位被断言和keyAgreement位也被设定的时候，主题公开密钥可以仅用于译解出数据（解密）
被使用，同时履行密钥协议。
本文不限制在keyUsage扩展实例中那些位的结合。但是，在部分7.3中将指定适合值
作为为特定算法keyUsage扩展。
4.2.1.4私有密钥使用周期
本文推荐反对这扩展的使用。CAs遵从本文一定不（MUST NOT）要私有密钥使用周
期为关键扩展时产生证书。
私有密钥使用周期扩展允许证书发行者与证书相比，为私有密钥明确不同的有效性周
期。这扩展打算用于给数字的签名密钥的使用。这扩展由两个可选成分组成，notBefore和
notAfter。和证书联系起来的私有密钥不应该在两个成分指定的时间提前或者过后对对象签
名使用。CAs除非至少两个成分之一存在，遵从本文一定不（MUST NOT）要在私有密钥
使用周期扩展存在时产生证书。
使用的地方，如同在部分4.1.2.5.2中定义那样，描述为GeneralizedTime必须（MUST）
指定notBefore和notAfter。
id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
PrivateKeyUsagePeriod ::= SEQUENCE {
notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL }
4.2.1.5证书策略
证书策略扩展包含一连串的一个或多个策略信息条目，每一个由一对象标识符（OID）
和可选的限定语（组成）。这些策略信息条款指示在其之下证书被签发的策略和证书可以被
使用的目的。可以存在的可选的限定语不预期改变策略的定义。
预期随着特有策略需求的应用有那些他们将接受的策略的清单以及把在证书中策略
OIDs和那清单比较。如果这扩展是关键的，路径验证软件必须（MUST）是能理解这（包
含可选的限定语）扩展的，否则必须丢弃证书。
为促进双方的互操作性，本文推荐（RECOMMENDS）策略信息条目由仅一OID构成。
单独OID不足的地方，本文强烈建议在这部分中识别出那些限制使用限定语。
本文为经过证书策略书写者（writers）和证书发行者使用定义的两个策略限定语。限定
语类型是CPS Pointer和User Notice 。
CPS Pointer限定语含有一指向经过CA发布的（Certification Practice Statement）
证书实施声明（CPS）的指针。指针是URI的格式。
当证书被使用的时候，User notice将展示依靠部分。应用（软件）应该（SHOULD）在
所有的证书上展示所有的使用证书路径的用户注意（User notice），除了如果那个注意（notes）
被复制，仅一复制品需求被展示的情况下。为阻碍这样复制，这个限定语应该（SHOULD）
仅是存在于末端实体（end-entity）证书和签发给其它组织的CA证书中。
用户注意（user notice）有两个可选字段：noticeRef字段和explicitText字段。
如果使用noticeRef字段通过数字（经过那组织准备的特殊原文的陈述）给一组织命名。
例如，它可以识别出组织"CertsRUs"和注意数字（notice number ）1。在一典型工具中，应
用（软件）将有一为含有当前一套注意（notices）CertsRUs文件：应用将从文件摘取注意文
本并且展示它。信息可以是用多种语言表达的允许软件为它的自己环境选择特定语言信息。
explicitText字段在证书中直接包含原文的声明。explicitText字段是一个最大为200个字
符的字符串。
如果在noticeRef和explicitText两个可选项中包含在一个限定语内并且如果应用软件能
找到按照noticeRef可选项指示注意的文本，那么那文本应该被展示；除此之外，explicitText
字符应该被展示。
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
certificatePolicies ::= SEQUENCE SIZE （1..MAX） OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE （1..MAX） OF
PolicyQualifierInfo OPTIONAL }
CertPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
-- policyQualifierIds for Internet policy qualifiers
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
PolicyQualifierId ::=
OBJECT IDENTIFIER （ id-qt-cps | id-qt-unotice ）
Qualifier ::= CHOICE {
cPSuri CPSuri,
userNotice UserNotice }
CPSuri ::= IA5String
UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
DisplayText ::= CHOICE {
visibleString VisibleString （SIZE （1..200））,
bmpString BMPString （SIZE （1..200））,
utf8String UTF8String （SIZE （1..200）） }
4.2.1.6策略映射
这扩展使用在CA证书中。它列出一对或多对OIDs；每一对包含issuerDomainPolicy和
subjectDomainPolicy。配对指示签发CA认为它的issuerDomainPolicy等于主题CA的
subjectDomainPolicy。
为特定应用签发CA的用户可以接受一issuerDomainPolicy。策略映射对发行与主题CA
相联系的策略的CA用户是可以与他们接受的策略相比较起作用。
这扩展可以被CAs和/或应用支持，并且它必须（MUST）是非关键的。
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
PolicyMappings ::= SEQUENCE SIZE （1..MAX） OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }
4.2.1.7主题可替换名字
主题可替换名字扩展允许附加与证书的主题相同的标识符。定义可选项包含Internet电
子邮件地址、DNS名字、IP地址和uniform resource identifier （URI）。其它可选项存在，
并且包含完全的本地定义。每一名字形式的多重名字形式和多重事例可以被包含。每当这样
相同的标识符是要被绑定成一张证书，主题可选名字（或者发行者可替换名字）扩展必须
（MUST）被使用。
因为主题可替换名字被认为是与公开密钥结合，主题可选名字所有的部分必须（MUST）
被CA验证。
进一步，如果在证书中仅包含有主题身份是一可替换名字形式（例如一电子邮件地址），
那么主题可识别名字必须（MUST）为空（一空序列）以及subjectAltName扩展必须（MUST）
存在。如果主题字段包含一空序列，subjectAltName扩展必须（MUST）是标记为关键。
当subjectAltName扩展含有一Internet邮递地址的时候，地址必须（MUST）是作为一
rfc822Name包含。rfc822Name的格式是一" addr-spec "，如同在RFC 822[RFC 822]中定
义那样。addr-spec格式为" local-part@domain "。注意在addr-spec之前没有（例如一
通用名字）短语，在它之后没有comment （text surrounded in parentheses）并且没有
"<"和">"包围。注意在RFC 822 addr-spec中大写和小写体字符是允许的，这种情况不区分
大小写。
当subjectAltName扩展含有一iPAddress的时候，地址必须（MUST）是如同在RFC
791[RFC 791]中指定那样，在"network byte order"八位字符中储藏。每一八位的最低有效位
（LSB）是在网络地址中相应字节的LSB。如同在RFC 791中指定的IP版本4那样，八位
字符必须（MUST）含有正好四个八位。如同在RFC 1883中指定的IP版本6那样，八位字
符必须（MUST）含有正好十六个八位[RFC 1883]。
当subjectAltName扩展含有一个域名服务标签的时候，域名必须（MUST）是在dNSName
（IA5String）中储藏。名字一定是如同经过RFC 1034[RFC 1034]指定那样，在" preferred name
syntax "中。注意在域名中允许大写和小写体字符，并且在这种情况下不分大小写。另外“ ”
（空格）在域名中是一个合法的字符的同时，dNSName的subjectAltName扩展“ ” （空
格）是不允许的。最后，DNS代表Internet邮递地址 （以wpolk.nist.gov代替wpolk@nist.gov）
的使用是不允许的；这样的标识符是要作为rfc822Name被编码。
当subjectAltName扩展含有一URI的时候，名字必须（MUST）存储在
uniformResourceIdentifier（IA5String）中。名字必须（MUST）是无关的（non-relative） URL
并且必须（MUST）按照[RFC 1738] 定义的URL句法和编码规则。名字必须包含两种模式
（例如"http"或者"ftp"）和scheme-specific-part。scheme-specific-part必须包含作为主机完全
合格域名或者IP地址。
如同在[RFC 1738]定义的那样，模式（scheme）名字不是大小写敏感的（case-sensitive ）
（例如，"http"是等于"HTTP"）。主机部分也不是大小写敏感的，但是scheme-specific-part
的其它成分可以是大小写敏感的。当比较URIs的时候，保证工具必须（MUST）比较scheme
和主机而不管大小写，但是认为scheme-specific-part的剩下的部分是大小写敏感的。
主题可替换名字如同在部分4.2.1.11中描绘那样主题识别名字使用名字约束扩展同样的
方式被约束。
如果subjectAltName扩展存在，序列必须（MUST）含有至少一入口。不像主题字段，
使CAs遵照必须不（MUST NOT）颁发subjectAltNames含有空GeneralName字段的证书。
例如，把rfc822Name描述为IA5String。在一个空字符串是有效IA5String的同时，这样的
rfc822Name在本文不被允许。当客户（软件）加工一证书路径的时候，不由本文定义客户
（软件）的行为。
最后，包括通配符（例如，是为一套名字的占位符号）的主题替换名字语义学不在本文
说明。随着具体需求应用可以使用这样的名字，但是要定义语义学。
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE （1..MAX） OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER}
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
4.2.1.8发行者可替换名字
和4.2.1.7一样，使用这扩展把Internet类型标识符和证书发行者联系起来。发行者可替
换名字必须（MUST）是4.2.1.7中描述的方式编码。
目前的情况，这扩展不应该（SHOULD NOT）被标记为关键。
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
IssuerAltName ::= GeneralNames
4.2.1.9主题目录服务系统属性
主题目录服务系统属性扩展不推荐作为本文的必须的部分，但是它可以在本地环境中被
使用。这扩展一定是非关键的。
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
SubjectDirectoryAttributes ::= SEQUENCE SIZE （1..MAX） OF Attribute
4.2.1.10基本约束
基本约束扩展识别出是否证书的主题一CA以及一证书路径通过CA可以存在的深度。
仅当如果cA被设置为TRUE，那么pathLenConstraint字段是有意义的。在这个情况中，
它给出最大CA证书的数目（证书链的长度――译者注），其可以随着这张在一证书路径中
证书来到的。零值指示仅一张末端实体证书沿着路径可以进入。它出现的地方，
pathLenConstraint字段必须（MUST）是大于等于零。pathLenConstraint不出现的地方，事
实上没有对证书路径的允许长度进行限制。
这个扩展必须（MUST）似乎在所有的CA证书中是关键扩展。这扩展不应该（SHOULD
NOT）出现在末端实体证书中。
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER （0..MAX） OPTIONAL }
4.2.1.11名字约束
名字约束扩展指示一名字空间，必须（MUST）是仅在一张CA证书中使用的，在一证
书路径中以内所有的随后证书中主题名字将被找到的。限制可以施加可识别名字或者主题可
替换名字于主题。仅当指定的名字形式存在的时候，限制提出申请。如果没有类型的名字在
证书中，证书是可接受。
限制按照允许或者排除名字子树中被定义。不管出现在permittedSubtrees的信息，任何
在excludedSubtrees字段限制相配的名字是无效的。这扩展必须（MUST）是关键的。
在本文以内，最低的和最大的字段域不随着任何名字形式被应用，因此最低的总是零，
和最大的限度总是不存在。
约束向主机部分名字申请URIs。约束可以指定一个主机或者域。例子可以是
"foo.bar.com"和".xyz.com"。什么时候约束以一分隔符开始，它可以是一或更多子域
（subdomains）膨胀。也就是说约束".xyz.com"被abc.xyz.com和abc.def.xyz.com满足。但是，
约束".xyz.com"不被"xyz.com"满足。当约束不以一分隔符开始的时候，它指定一个主机。
为Internat邮递地址名字约束可以指定一个特定邮箱、所有的在一个特定主机地址或者
所有的在一域中的邮箱。指示一个特定邮箱，约束是完整邮递地址。例如，"root@xyz.com"
指示在主机"xyz.com"上根邮箱。说明所有的在一个特定主机上Internet邮递地址，指定约束
作为主机名字。例如，约束"xyz.com"在主机"xyz.com"被任何邮递地址满足。指定任何在域
以内的地址，用一领头的分隔符约束（和URIs）一样被指定。例如，".xyz.com"指示所有的
Internet邮递地址在"xyz.com"域中，但是Internet邮递地址在主机"xyz.com"上。
DNS名字限制作为foo.bar.com被表示。任何子域满足名字约束。例如，www.foo.bar.com
将满足约束，但是bigfoo.bar.com不满足。
遗留工具存在于RFC 822名字嵌入的在一个类型EmailAddress（见4.1.2.6）的属性中
可识别名字主题。当rfc822名字是限制的，但是证书不包含主题可替换名字的时候，rfc822
名字约束必须（MUST）是在主题识别名字中施加于EmailAddress类型的属性。对
EmailAddress ASN.1句法和相应的OID在附录A和B中被补充。
形式directoryName的限制必须（MUST）是施加于在证书中主题字段和directoryName
类型的subjectAltName扩展。形式x400Address的限制必须（MUST）是施加于类型
x400Address的subjectAltName扩展。
当应用形式directoryName的限制的时候，工具必须（MUST）比较DN属性。在一最
低限度，工具必须（MUST）履行在部分4.1.2.4中指定DN比较规则。CAs颁发的形式
directoryName限制的证书不应该（SHOULD NOT）信赖完全ISO DN名字比较算法的工具
上。这个暗示名字限制将向在主题字段或者subjectAltName扩展中使用的编码同一地陈述。
iPAddress的句法必须（MUST）是如同在第4.2.1.7段中那样，对于名字约束被特别描
绘。对于IPv4地址，generalName的ipAddress字段必须（MUST）含有八（8） octets，在
RFC 1519（CIDR）的款式中编码表现为地址范围。对于IPv6 地址，ipAddress字段必须
（MUST）包含同样的32 octets编码。例如对于" class C "名字约束亚网10.9.8.0将是0A 09 08
00 FF FF FF 00octets描述为八位代表，CIDR注释代表为10.9.8.0/255.255.255.0。
不由本文定义为otherName，ediPartyName和registeredID名字约束句法和语义学。
id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE （1..MAX） OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER （0..MAX）
4.2.1.12策略约束
策略约束扩展能在颁发的CAs证书中被使用。策略约束扩展在两种方式中强迫路径验
证。它能用于禁止策略映射或者要求每一在路径中证书含有一个可接受策略标识符。
如果inhibitPolicyMapping字段存在，在策略映射是不再允许之前，值指示附加证书可
以出现在路径的数目。例如，一值指示策略映射可以在这张证书的主题发出的证书中处理，
但是不在路径中附加。
如果requireExplicitPolicy字段存在，随后的证书将包含一个可接受策略标识符。在一
显示策略被要求之前，requireExplicitPolicy的值指示可以出现在路径的附加证书的数目。一
个可接受策略标识符是一经过证书路径或者标识符的用户对一通过策略映射被宣布是等于
策略需求标识符的。
使CAs遵照一定不（MUST NOT）要颁发在策略约束空序列时的证书。也就是说在
inhibitPolicyMapping字段或者requireExplicitPolicy字段中最少一个必须（MUST）存在。当
遭遇一空的策略约束字段时，客户（软件）的行为不在本文中描述。
这扩展可以是关键或者非关键。
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER （0..MAX）
4.2.1.13扩大密钥使用领域
这字段指示一或更多确认的公开密钥增加或者代替基本密钥使用扩展字段中表明的目
的。这字段定义如下：
id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
ExtKeyUsageSyntax ::= SEQUENCE SIZE （1..MAX） OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
密钥目的可以由任何有需求的组织定义。使用对象标识符识别出密钥目的将与IANA或
者ITU TRec.X.660|ISO IEC/ITU 9834-1一致被分配。
这扩展在证书发行者的可选项方面可以扩展，是既关键又非关键。
如果扩展被标志为关键，那么证书必须（MUST）是仅用于目的标志之一使用。
如果扩展被标志为非关键，那么它指示密钥的预设目的或者可以在发现在有多重密钥/
证书的实体中恰当的密钥/证书方面被使用。它是一顾问字段并且不暗示密钥的使用被证书
权威机构目的指示的限制。尽管如此证书应用可以要求一特殊目的被表明为了证书能对那种
应用是可接受的。
如果一张证书含有一关键的密钥使用字段和一关键的扩展密钥使用字段，那么在两字段
必须（MUST）被独立处理并且证书必须（MUST）仅对两个字段一致目的被使用。如果事
实上没有和两个字段一致目的，那么证书一定不要（MUST NOT）用于任何目的。
本文确定下列的密钥使用目的：
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1}
-- TLS Web server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
--
id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2}
-- TLS Web client authentication
-- Key usage bits that may be consistent: digitalSignature and/or
-- keyAgreement
--
id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3}
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature
--
id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4}
-- E-mail protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or （keyEncipherment
-- or keyAgreement）
--
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time from an agreed-upon time
-- source. Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation
4.2.1.14 CRL发布点
CRL发布点扩展标识出CRL信息如何得到。扩展应该（SHOULD）是非关键，但是本
文建议由CAs和应用（程序）支持这扩展。CRL管理的进一步讨论包含在部分5中。
如果cRLDistributionPoints扩展含有一类型URI的DistributionPointName，下列的语义
学必须被假定：URI为相关的理由和将结合cRLIssuer被发出的指向当前CRL。为URI预期
值在4.2.1.7部分定义。处理关于其它值的规则不由本文定义。如果distributionPoint删掉理
由，CRL必须（MUST）撤销所有理由。如果distributionPoint删掉cRLIssuer，CRL必须（MUST）
是由发行证书的CA发出的。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
cRLDistributionPoints ::= {
CRLDistPointsSyntax }
CRLDistPointsSyntax ::= SEQUENCE SIZE （1..MAX） OF DistributionPoint
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
ReasonFlags ::= BIT STRING {
unused （0）,
keyCompromise （1）,
cACompromise （2）,
affiliationChanged （3）,
superseded （4）,
cessationOfOperation （5）,
certificateHold （6） }
4.2.2私有Internet扩展
这部分为在Internet公开密钥基础中的使用定义一新扩展。这扩展可以被直接应用
（direct applications）识别出一联机批准服务的申请支撑的发行CA。当信息可以是在多重形
式有效时，每一扩展是一连串的IA5String值、每一个代表一URI。URI不言明地指定关于
得到信息的信息和方法的位置和格式。
一个对象标识符为私有扩展被定义。把对象标识符和私有扩展联系起来在id-pkix名字
空间以内的arc id-pe下面被定义。任何为Internet PKI定义的未来扩展将也在arc id-pe 下面
被定义。
id-pkix OBJECT IDENTIFIER ::=
{ iso（1） identified-organization（3） dod（6） internet（1）
security（5） mechanisms（5） pkix（7） }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
4.2.2.1权威信息存取
权威信息存取扩展指示怎样访问CA关于扩展出现在证书的发行人的信息和服务。信息
和服务可以包含联机授权服务和CA策略数据。（CRLs的位置不在这扩展中被指定；那信息
被cRLDistributionPoints扩展提供）这扩展可以包含在主题或者CA证书内，并且它一定是
非关键的。
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
AuthorityInfoAccessSyntax ::=
SEQUENCE SIZE （1..MAX） OF AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
每一在序列AuthorityInfoAccessSyntax入口中描绘附加关于CA的信息的格式和位置，
其发行这扩展出现的证书。信息的类型和格式被accessMethod字段指定；accessLocation字
段指定信息的位置。恢复机制意味着可以用accessMethod或者由accessLocation指定。
本文为accessMethod定义一OID。当附加信息列出CAs其已发行的比发行证书的CA
地位高证书的时候，id-ad-caIssuers OID被使用含有这扩展。参照CA发行者描绘在选择一
由证书用户信任终止点的证书路径中帮助证书用户。
当id-ad-caIssuers作为accessInfoType出现的时候，accessLocation字段描绘推荐服务器
和存取协议去得到参照描绘。把accessLocation字段定义为能采取几种格式的
GeneralName。经由http，ftp或者ldap信息可用的地方，accessLocation必须（MUST）是
一uniformResourceIdentifier。信息可用的地方经由目录服务系统存取协议（dap），
accessLocation必须（MUST）是一directoryName。当信息经由电子邮件可用的时候，
accessLocation必须（MUST）是一rfc822Name。不由本文说明确定accessLocation的其它名
字格式（当accessMethod是id-ad-caIssuers）的语义学。
附加存取描述符可以在其它PKIX文本说明中被定义。
5 CRL和CRL扩展简介
如同前面描绘那样，X.509 v2CRL本文的一个目标是要帮助发展创造一可由双方共同操
作的和可再用的Internet PKI。达到这目标，扩展使用的指南被指定和一些关于包含在CRL
中本质的假定信息。
CRLs可以被使用在覆盖宽广范围的可由双方共同操作目标和甚至更宽广范围的应用和
环境的宽阔范围中的操作上的和担保需求。本文为要求宽广可由双方共同操作的应用建立一
条共用基线。本文定义一基线套能在每一个CRL中被预期的信息。同时，本文定义为以及
为这些属性共用代表经常用过的属性在CRL以内的通用位置。
本文不定义任何私有InternetCRL扩展或者CRL入口扩展。
随着附加或者特殊目的需求环境可以建立在本文基础上 