翻译：RFC 2459 摘要与第三章节
Title: RFC 2459 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile
标题:RFC 2459——Internet X.509 公钥基础设施证书和CRL简介
Abstract
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms(i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples areprovided in the appendices.3.1 X.509 Version 3 Certificate
摘要
这份备忘录描述了应用在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模块和例子在附录中提供。
3.1 X.509 Version 3 Certificate
Users of a public key shall be confident that the associated privatekey is owned by the correct remote subject (person or system) withwhich an encryption or digital signature mechanism will be used.This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subjects. The binding is asserted by having a trusted CA digitally sign each certificate. The CA may base this assertion upon technical means (a.k.a., proof of posession through a challenge-response protocol), presentation of the private key, or on an assertion by the subject. A certificate has a limited valid lifetime which is indicated in its signed contents. Because a certificate\'s signature and timeliness can be independently checked by a certificate-using client, certificates can be distributed via untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems.
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which wasfirst published in 1988 as part of the X.500 Directory recommendations, defines a standard certificate format [X.509]. The certificate format in the 1988 standard is called the version 1 (v1) format. When X.500 was revised in 1993, two more fields were added,resulting in the version 2 (v2) format. These two fields may be used to support directory access control.
The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,include specifications for a public key infrastructure based on X.509 v1 certificates [RFC 1422]. The experience gained in attempts to deploy RFC 1422 made it clear that the v1 and v2 certificate formats are deficient in several respects. Most importantly, more fields were needed to carry information which PEM design and implementation experience has proven necessary. In response to these new requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3(v3) certificate format. The v3 format extends the v2 format by adding provision for additional extension fields. Particular extension field types may be specified in standards or may be defined and registered by any organization or community. In June 1996,standardization of the basic v3 format was completed [X.509].
ISO/IEC/ITU and ANSI X9 have also developed standard extensions for use in the v3 extensions field [X.509][X9.55]. These extensions can convey such data as additional subject identification information,key attribute information, policy information, and certification path constraints.
However, the ISO/IEC/ITU and ANSI X9 standard extensions are very broad in their applicability. In order to develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 extensions tailored for the Internet. It is one goal of this document to specify a profile for Internet WWW, electronic mail, and IPsec applications.
Environments with additional requirements may build on this profile or may replace it.
3.2 Certification Paths and Trust
A user of a security service requiring knowledge of a public key generally needs to obtain and validate a certificate containing the required public key. If the public-key user does not already hold an assured copy of the public key of the CA that signed the certificate,the CA\'s name, and related information (such as the validity period or name constraints), then it might need an additional certificate to obtain that public key. In general, a chain of multiple certificates may be needed, comprising a certificate of the public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is only initialized with a limited number of assured CA public keys.
There are different ways in which CAs might be configured in order for public key users to be able to find certification paths. For PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There are three types of PEM certification authority:
(a) Internet Policy Registration Authority (IPRA): This authority, operated under the auspices of the Internet Society,acts as the root of the PEM certification hierarchy at level 1.It issues certificates only for the next level of authorities,PCAs. All certification paths start with the IPRA.
(b) Policy Certification Authorities (PCAs): PCAs are at level 2 of the hierarchy, each PCA being certified by the IPRA. A PCA shall establish and publish a statement of its policy with respect to certifying users or subordinate certification authorities.Distinct PCAs aim to satisfy different user needs. For example,one PCA (an organizational PCA) might support the generalelectronic mail needs of commercial organizations, and another PCA(a high-assurance PCA) might have a more stringent policy designedfor satisfying legally binding digital signature requirements.
(c) Certification Authorities (CAs): CAs are at level 3 of the hierarchy and can also be at lower levels. Those at level 3 are certified by PCAs. CAs represent, for example, particular organizations, particular organizational units (e.g., departments,groups, sections), or particular geographical areas.
RFC 1422 furthermore has a name subordination rule which requires that a CA can only issue certificates for entities whose names are subordinate (in the X.500 naming tree) to the name of the CA itself.The trust associated with a PEM certification path is implied by the PCA name. The name subordination rule ensures that CAs below the PCA are sensibly constrained as to the set of subordinate entities they can certify (e.g., a CA for an organization can only certify entities in that organization\'s name tree). Certificate user systems are able to mechanically check that the name subordination rule has been followed.
The RFC 1422 uses the X.509 v1 certificate formats. The limitations of X.509 v1 required imposition of several structural restrictions to clearly associate policy information or restrict the utility of certificates. These restrictions included:
(a) a pure top-down hierarchy, with all certification paths starting from IPRA;
(b) a naming subordination rule restricting the names of a CA\'s subjects; and
(c) use of the PCA concept, which requires knowledge of individual PCAs to be built into certificate chain verification logic.
Knowledge of individual PCAs was required to determine if a chain could be accepted.
With X.509 v3, most of the requirements addressed by RFC 1422 can be addressed using certificate extensions, without a need to restrict the CA structures used. In particular, the certificate extensions relating to certificate policies obviate the need for PCAs and the constraint extensions obviate the need for the name subordination rule. As a result, this document supports a more flexible architecture, including:
(a) Certification paths may start with a public key of a CA in a user\'s own domain, or with the public key of the top of a hierarchy. Starting with the public key of a CA in a user\'s own domain has certain advantages. In some environments, the local domain is the most trusted.
(b) Name constraints may be imposed through explicit inclusion of a name constraints extension in a certificate, but are not required.
(c) Policy extensions and policy mappings replace the PCA concept, which permits a greater degree of automation. The application can determine if the certification path is acceptable based on the contents of the certificates instead of a priori knowledge of PCAs. This permits automation of certificate chain processing.
Revocation
When a certificate is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate.
X.509 defines one method of certificate revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time stamped list identifying revoked certificates which is signed by a CA and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a certificate-using system uses a certificate (e.g., for verifying a remote user\'s digital signature), that system not only checks the certificate signature and validity but also acquires a suitably-recent CRL and checks that the certificate serial number is not on that CRL. The meaning of "suitably-recent" may vary with local policy, but it usually means the most recently-issued CRL. A CA issues a new CRL on a regular periodic basis (e.g., hourly, daily, or weekly). An entry is added to the CRL as part of the next update following notification of revocation. An entry may be removed from the CRL after appearing on one regularly scheduled CRL issued beyondthe revoked certificate\'s validity period.
An advantage of this revocation method is that CRLs may be distributed by exactly the same means as certificates themselves,namely, via untrusted communications and server systems.
One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until the next periodic CRL is issued -- this may be up to one hour, one day, or one week depending on the frequency that the CA issues CRLs.
As with the X.509 v3 certificate format, in order to facilitate interoperable implementations from multiple vendors, the X.509 v2 CRL format needs to be profiled for Internet use. It is one goal of this document to specify that profile. However, this profile does not require CAs to issue CRLs. Message formats and protocols supporting on-line revocation notification may be defined in other PKIX
specifications. On-line methods of revocation notification may be applicable in some environments as an alternative to the X.509 CRL.On-line revocation checking may significantly reduce the latency between a revocation report and the distribution of the information to relying parties. Once the CA accepts the report as authentic and valid, any query to the on-line service will correctly reflect the certificate validation impacts of the revocation. However, these methods impose new security requirements; the certificate validator shall trust the on-line validation service while the repository does not need to be trusted.
3.4 Operational Protocols
Operational protocols are required to deliver certificates and CRLs(or status information) to certificate using client systems.Provision is needed for a variety of different means of certificate and CRL delivery, including distribution procedures based on LDAP,HTTP, FTP, and X.500. Operational protocols supporting these functions are defined in other PKIX specifications. These specifications may include definitions of message formats and procedures for supporting all of the above operational environments,including definitions of or references to appropriate MIME content types.
3.5 Management Protocols
Management protocols are required to support on-line interactions between PKI user and management entities. For example, a management protocol might be used between a CA and a client system with which a key pair is associated, or between two CAs which cross-certify each other. The set of functions which potentially need to be supported by management protocols include:
(a) registration: This is the process whereby a user first makes itself known to a CA (directly, or through an RA), prior to that CA issuing a certificate or certificates for that user.
(b) initialization: Before a client system can operate securely it is necessary to install key materials which have the appropriate relationship with keys stored elsewhere in the infrastructure. For example, the client needs to be securely initialized with the public key and other assured information of the trusted CA(s), to be used in validating certificate paths.Furthermore, a client typically needs to be initialized with its own key pair(s).
(c) certification: This is the process in which a CA issues a certificate for a user\'s public key, and returns that certificate to the user\'s client system and/or posts that certificate in a
repository.
(d) key pair recovery: As an option, user client key materials(e.g., a user\'s private key used for encryption purposes) may be backed up by a CA or a key backup system. If a user needs torecover these backed up key materials (e.g., as a result of a forgotten password or a lost key chain file), an on-line protocol exchange may be needed to support such recovery.
(e) key pair update: All key pairs need to be updated regularly,i.e., replaced with a new key pair, and new certificates issued.
(f) revocation request: An authorized person advises a CA of an abnormal situation requiring certificate revocation.
(g) cross-certification: Two CAs exchange information used in establishing a cross-certificate. A cross-certificate is a certificate issued by one CA to another CA which contains a CA signature key used for issuing certificates.
Note that on-line protocols are not the only way of implementing the above functions. For all functions there are off-line methods of achieving the same result, and this specification does not mandate use of on-line protocols. For example, when hardware tokens are used, many of the functions may be achieved as part of the physical token delivery. Furthermore, some of the above functions may be combined into one protocol exchange. In particular, two or more of the registration, initialization, and certification functions can be combined into one protocol exchange.
The PKIX series of specifications may define a set of standard message formats supporting the above functions in future specifications. In that case, the protocols for conveying these messages in different environments (e.g., on-line, file transfer, e-mail, and WWW) will also be described in those specifications.
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）的协议将在那些文本被描绘。