Network Working Group C. Adams
Request for Comments: 2510 Entrust Technologies
Category: Standards Track S. Farrell
SSE
March 1999
Network Working Group C. Adams
Request for Comments: 2510 Entrust Technologies
Category: Standards Track S. Farrell
SSE
March 1999
Internet X.509 Public Key Infrastructure Certificate Management Protocols
Internet X.509公钥基础结构证书管理协议
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that "certificate" in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM].
本文档介绍Internet X.509公钥基础设施（PKI）证书管理协议。协议消息是为证书创建和管理的所有相关方面定义的。请注意，本文件中的“证书”指的是[COR95，X509-AM]中定义的X.509v3证书。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可以”和“可选”（大写，如图所示）应按照[RFC2119]中所述进行解释。
Introduction
介绍
The layout of this document is as follows:
本文件的布局如下：
- Section 1 contains an overview of PKI management; - Section 2 contains discussion of assumptions and restrictions; - Section 3 contains data structures used for PKI management messages; - Section 4 defines the functions that are to be carried out in PKI management by conforming implementations; - Section 5 describes a simple protocol for transporting PKI messages; - the Appendices specify profiles for conforming implementations and provide an ASN.1 module containing the syntax for all messages defined in this specification.
- 第1节概述了PKI管理；-第2节包含对假设和限制的讨论；-第3节包含用于PKI管理消息的数据结构；-第4节定义了通过一致性实现在PKI管理中执行的功能；-第5节描述了用于传输PKI消息的简单协议；-附录规定了一致性实现的概要文件，并提供了一个ASN.1模块，其中包含本规范中定义的所有消息的语法。
1 PKI Management Overview
1 PKI管理概述
The PKI must be structured to be consistent with the types of individuals who must administer it. Providing such administrators with unbounded choices not only complicates the software required but also increases the chances that a subtle mistake by an administrator or software developer will result in broader compromise. Similarly, restricting administrators with cumbersome mechanisms will cause them not to use the PKI.
PKI的结构必须与必须管理PKI的个人类型保持一致。为这样的管理员提供无限的选择不仅使所需的软件复杂化，而且还增加了管理员或软件开发人员的细微错误导致更广泛妥协的可能性。同样，使用繁琐的机制限制管理员将导致他们不使用PKI。
Management protocols are REQUIRED to support on-line interactions between Public Key Infrastructure (PKI) components. For example, a management protocol might be used between a Certification Authority (CA) and a client system with which a key pair is associated, or between two CAs that issue cross-certificates for each other.
需要管理协议来支持公钥基础设施（PKI）组件之间的在线交互。例如，可以在证书颁发机构（CA）和与密钥对关联的客户机系统之间，或者在为彼此颁发交叉证书的两个CA之间使用管理协议。
Before specifying particular message formats and procedures we first define the entities involved in PKI management and their interactions (in terms of the PKI management functions required). We then group these functions in order to accommodate different identifiable types of end entities.
在指定特定的消息格式和过程之前，我们首先定义参与PKI管理的实体及其交互（根据所需的PKI管理功能）。然后，我们将这些功能分组，以适应不同类型的终端实体。
The entities involved in PKI management include the end entity (i.e., the entity to be named in the subject field of a certificate) and the certification authority (i.e., the entity named in the issuer field of a certificate). A registration authority MAY also be involved in PKI management.
参与PKI管理的实体包括最终实体（即，在证书主题字段中命名的实体）和证书颁发机构（即，在证书颁发者字段中命名的实体）。注册机构也可能参与PKI管理。
The term "subject" is used here to refer to the entity named in the subject field of a certificate; when we wish to distinguish the tools and/or software used by the subject (e.g., a local certificate management module) we will use the term "subject equipment". In general, the term "end entity" (EE) rather than subject is preferred in order to avoid confusion with the field name.
术语“主体”在此处用于指证书主体字段中命名的实体；当我们希望区分受试者使用的工具和/或软件（例如，本地证书管理模块）时，我们将使用术语“受试者设备”。一般来说，为了避免与字段名混淆，首选术语“终端实体”（EE）而不是主题。
It is important to note that the end entities here will include not only human users of applications, but also applications themselves (e.g., for IP security). This factor influences the protocols which the PKI management operations use; for example, application software is far more likely to know exactly which certificate extensions are required than are human users. PKI management entities are also end entities in the sense that they are sometimes named in the subject
需要注意的是，此处的终端实体不仅包括应用程序的人工用户，还包括应用程序本身（例如，用于IP安全）。该因素影响PKI管理操作使用的协议；例如，应用程序软件比人类用户更可能准确地知道需要哪些证书扩展。PKI管理实体也是终端实体，因为它们有时在主题中被命名
field of a certificate or cross-certificate. Where appropriate, the term "end-entity" will be used to refer to end entities who are not PKI management entities.
证书或交叉证书的字段。在适当情况下，“最终实体”一词将用于指非PKI管理实体的最终实体。
All end entities require secure local access to some information -- at a minimum, their own name and private key, the name of a CA which is directly trusted by this entity and that CA's public key (or a fingerprint of the public key where a self-certified version is available elsewhere). Implementations MAY use secure local storage for more than this minimum (e.g., the end entity's own certificate or application-specific information). The form of storage will also vary -- from files to tamper-resistant cryptographic tokens. Such local trusted storage is referred to here as the end entity's Personal Security Environment (PSE).
所有终端实体都需要对某些信息进行安全的本地访问——至少是他们自己的名称和私钥、该实体直接信任的CA的名称以及该CA的公钥（或者在其他地方可以获得自认证版本的公钥指纹）。实现可能会使用安全本地存储超过此最小值（例如，终端实体自己的证书或特定于应用程序的信息）。存储的形式也会有所不同——从文件到防篡改的加密令牌。这种本地可信存储在这里称为终端实体的个人安全环境（PSE）。
Though PSE formats are beyond the scope of this document (they are very dependent on equipment, et cetera), a generic interchange format for PSEs is defined here - a certification response message MAY be used.
虽然PSE格式超出了本文件的范围（它们非常依赖于设备等），但此处定义了PSE的通用交换格式-可以使用认证响应消息。
The certification authority (CA) may or may not actually be a real "third party" from the end entity's point of view. Quite often, the CA will actually belong to the same organization as the end entities it supports.
从最终实体的角度来看，认证机构（CA）可能是也可能不是真正的“第三方”。通常，CA实际上与它所支持的终端实体属于同一个组织。
Again, we use the term CA to refer to the entity named in the issuer field of a certificate; when it is necessary to distinguish the software or hardware tools used by the CA we use the term "CA equipment".
同样，我们使用术语CA来指代证书颁发者字段中命名的实体；当需要区分CA使用的软件或硬件工具时，我们使用术语“CA设备”。
The CA equipment will often include both an "off-line" component and an "on-line" component, with the CA private key only available to the "off-line" component. This is, however, a matter for implementers (though it is also relevant as a policy issue).
CA设备通常包括“离线”组件和“在线”组件，CA私钥仅对“离线”组件可用。然而，这是实施者的问题（尽管这也是一个政策问题）。
We use the term "root CA" to indicate a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly.
我们使用术语“根CA”来表示终端实体直接信任的CA；也就是说，安全地获取根CA公钥的值需要一些带外步骤。这一术语并不意味着根CA必须位于任何层次结构的顶部，只是指所讨论的CA直接受信任。
A "subordinate CA" is one that is not a root CA for the end entity in question. Often, a subordinate CA will not be a root CA for any entity but this is not mandatory.
“从属CA”不是所讨论的终端实体的根CA。通常，从属CA不是任何实体的根CA，但这不是强制性的。
In addition to end-entities and CAs, many environments call for the existence of a Registration Authority (RA) separate from the Certification Authority. The functions which the registration authority may carry out will vary from case to case but MAY include personal authentication, token distribution, revocation reporting, name assignment, key generation, archival of key pairs, et cetera.
除了终端实体和CA之外，许多环境要求存在一个独立于证书颁发机构的注册机构（RA）。注册机构可能执行的功能因情况而异，但可能包括个人身份验证、令牌分发、撤销报告、名称分配、密钥生成、密钥对存档等。
This document views the RA as an OPTIONAL component - when it is not present the CA is assumed to be able to carry out the RA's functions so that the PKI management protocols are the same from the end-entity's point of view.
本文档将RA视为一个可选组件-如果不存在，则假定CA能够执行RA的功能，以便从最终实体的角度来看，PKI管理协议是相同的。
Again, we distinguish, where necessary, between the RA and the tools used (the "RA equipment").
在必要时，我们再次区分RA和使用的工具（“RA设备”）。
Note that an RA is itself an end entity. We further assume that all RAs are in fact certified end entities and that RAs have private keys that are usable for signing. How a particular CA equipment identifies some end entities as RAs is an implementation issue (i.e., this document specifies no special RA certification operation). We do not mandate that the RA is certified by the CA with which it is interacting at the moment (so one RA may work with more than one CA whilst only being certified once).
请注意，RA本身就是一个终端实体。我们进一步假设所有RAs实际上都是经过认证的终端实体，并且RAs具有可用于签名的私钥。特定CA设备如何将某些终端实体识别为RAs是一个实施问题（即，本文件未规定特殊的RA认证操作）。我们不要求RA由其目前正在与之交互的CA进行认证（因此一个RA可以与多个CA一起工作，同时只认证一次）。
In some circumstances end entities will communicate directly with a CA even where an RA is present. For example, for initial registration and/or certification the subject may use its RA, but communicate directly with the CA in order to refresh its certificate.
在某些情况下，即使存在RA，终端实体也将直接与CA通信。例如，对于初始注册和/或认证，受试者可以使用其RA，但直接与CA通信以刷新其证书。
The protocols given here meet the following requirements on PKI management.
这里给出的协议满足以下关于PKI管理的要求。
1. PKI management must conform to the ISO 9594-8 standard and the associated amendments (certificate extensions)
1. PKI管理必须符合ISO 9594-8标准和相关修订（证书扩展）
2. PKI management must conform to the other parts of this series.
2. PKI管理必须符合本系列的其他部分。
3. It must be possible to regularly update any key pair without affecting any other key pair.
3. 必须能够在不影响任何其他密钥对的情况下定期更新任何密钥对。
4. The use of confidentiality in PKI management protocols must be kept to a minimum in order to ease regulatory problems.
4. PKI管理协议中的保密性必须保持在最低限度，以缓解监管问题。
5. PKI management protocols must allow the use of different industry-standard cryptographic algorithms, (specifically including RSA, DSA, MD5, SHA-1) -- this means that any given CA, RA, or end entity may, in principle, use whichever algorithms suit it for its own key pair(s).
5. PKI管理协议必须允许使用不同的行业标准加密算法（特别是RSA、DSA、MD5、SHA-1）——这意味着任何给定的CA、RA或最终实体原则上可以使用适合其自身密钥对的算法。
6. PKI management protocols must not preclude the generation of key pairs by the end-entity concerned, by an RA, or by a CA -- key generation may also occur elsewhere, but for the purposes of PKI management we can regard key generation as occurring wherever the key is first present at an end entity, RA, or CA.
6. PKI管理协议不得阻止相关终端实体、RA或CA生成密钥对——密钥生成也可能发生在其他地方，但出于PKI管理的目的，我们可以将密钥生成视为发生在密钥首先出现在终端实体、RA或CA的任何地方。
7. PKI management protocols must support the publication of certificates by the end-entity concerned, by an RA, or by a CA. Different implementations and different environments may choose any of the above approaches.
7. PKI管理协议必须支持相关终端实体、RA或CA发布证书。不同的实现和不同的环境可能会选择上述任何一种方法。
8. PKI management protocols must support the production of Certificate Revocation Lists (CRLs) by allowing certified end entities to make requests for the revocation of certificates - this must be done in such a way that the denial-of-service attacks which are possible are not made simpler.
8. PKI管理协议必须支持证书撤销列表（CRL）的生成，允许经认证的最终实体发出证书撤销请求-这必须以这样的方式完成，即可能的拒绝服务攻击不会变得更简单。
9. PKI management protocols must be usable over a variety of "transport" mechanisms, specifically including mail, http, TCP/IP and ftp.
9. PKI管理协议必须能够通过各种“传输”机制使用，特别是邮件、http、TCP/IP和ftp。
10. Final authority for certification creation rests with the CA; no RA or end-entity equipment can assume that any certificate issued by a CA will contain what was requested -- a CA may alter certificate field values or may add, delete or alter extensions according to its operating policy. In other words, all PKI entities (end-entities, RAs, and CAs) must be capable of handling responses to requests for certificates in which the actual certificate issued is different from that requested (for example, a CA may shorten the validity period requested). Note that policy may dictate that the CA must not publish or otherwise distribute the certificate until the requesting entity has reviewed and accepted the newly-created certificate (typically through use of the PKIConfirm message).
10. 证书创建的最终权限属于CA；任何RA或终端实体设备都不能假设CA颁发的任何证书将包含所请求的内容——CA可以根据其操作策略更改证书字段值或添加、删除或更改扩展。换句话说，所有PKI实体（终端实体、RAs和CA）必须能够处理对证书请求的响应，其中实际颁发的证书与请求的证书不同（例如，CA可能缩短请求的有效期）。请注意，策略可能规定，在请求实体审查并接受新创建的证书之前（通常通过使用PKI确认消息），CA不得发布或以其他方式分发证书。
11. A graceful, scheduled change-over from one non-compromised CA key pair to the next (CA key update) must be supported (note that if the CA key is compromised, re-initialization must be performed for all entities in the domain of that CA). An end entity whose PSE contains the new CA public key (following a CA key update) must also be able to verify certificates verifiable using the old public key. End entities who directly
11. 必须支持从一个未泄露的CA密钥对到下一个（CA密钥更新）的优雅、计划的转换（注意，如果CA密钥泄露，则必须对该CA域中的所有实体执行重新初始化）。其PSE包含新CA公钥（CA密钥更新后）的最终实体还必须能够验证可使用旧公钥验证的证书。终止直接
trust the old CA key pair must also be able to verify certificates signed using the new CA private key. (Required for situations where the old CA public key is "hardwired" into the end entity's cryptographic equipment).
信任旧CA密钥对还必须能够验证使用新CA私钥签名的证书。（旧CA公钥“硬连线”到终端实体的加密设备的情况下需要）。
12. The Functions of an RA may, in some implementations or environments, be carried out by the CA itself. The protocols must be designed so that end entities will use the same protocol (but, of course, not the same key!) regardless of whether the communication is with an RA or CA.
12. 在某些实现或环境中，RA的功能可能由CA本身执行。协议的设计必须确保终端实体将使用相同的协议（当然，不是相同的密钥！），无论通信是与RA还是CA。
13. Where an end entity requests a certificate containing a given public key value, the end entity must be ready to demonstrate possession of the corresponding private key value. This may be accomplished in various ways, depending on the type of certification request. See Section 2.3, "Proof of Possession of Private Key", for details of the in-band methods defined for the PKIX-CMP (i.e., Certificate Management Protocol) messages.
13. 当终端实体请求包含给定公钥值的证书时，终端实体必须准备好证明拥有相应的私钥值。根据认证请求的类型，这可以通过各种方式实现。有关为PKIX-CMP（即证书管理协议）消息定义的带内方法的详细信息，请参见第2.3节“私钥拥有证明”。
PKI Management Operations
PKI管理操作
The following diagram shows the relationship between the entities defined above in terms of the PKI management operations. The letters in the diagram indicate "protocols" in the sense that a defined set of PKI management messages can be sent along each of the lettered lines.
下图显示了上述PKI管理操作中定义的实体之间的关系。图中的字母表示“协议”，即定义的PKI管理消息集可以沿着每个字母行发送。
+---+ cert. publish +------------+ j
| | <--------------------- | End Entity | <-------
| C | g +------------+ "out-of-band"
| | | ^ loading
| e | | | initial
| r | a | | b registration/
| t | | | certification
| | | | key pair recovery
| / | | | key pair update
| | | | certificate update
| C | PKI "USERS" V | revocation request
| R | -------------------+-+-----+-+------+-+-------------------
| L | PKI MANAGEMENT | ^ | ^
| | ENTITIES a | | b a | | b
| | V | | |
| R | g +------+ d | |
| e | <------------ | RA | <-----+ | |
| p | cert. | | ----+ | | |
| o | publish +------+ c | | | |
| s | | | | |
| i | V | V |
| t | g +------------+ i
| o | <------------------------| CA |------->
| r | h +------------+ "out-of-band"
| y | cert. publish | ^ publication
| | CRL publish | |
+---+ | | cross-certification
e | | f cross-certificate
| | update
| |
V |
+------+
| CA-2 |
+------+
+---+ cert. publish +------------+ j
| | <--------------------- | End Entity | <-------
| C | g +------------+ "out-of-band"
| | | ^ loading
| e | | | initial
| r | a | | b registration/
| t | | | certification
| | | | key pair recovery
| / | | | key pair update
| | | | certificate update
| C | PKI "USERS" V | revocation request
| R | -------------------+-+-----+-+------+-+-------------------
| L | PKI MANAGEMENT | ^ | ^
| | ENTITIES a | | b a | | b
| | V | | |
| R | g +------+ d | |
| e | <------------ | RA | <-----+ | |
| p | cert. | | ----+ | | |
| o | publish +------+ c | | | |
| s | | | | |
| i | V | V |
| t | g +------------+ i
| o | <------------------------| CA |------->
| r | h +------------+ "out-of-band"
| y | cert. publish | ^ publication
| | CRL publish | |
+---+ | | cross-certification
e | | f cross-certificate
| | update
| |
V |
+------+
| CA-2 |
+------+
Figure 1 - PKI Entities
图1-PKI实体
At a high level the set of operations for which management messages are defined can be grouped as follows.
在高层，定义管理消息的操作集可以按如下方式分组。
1 CA establishment: When establishing a new CA, certain steps are required (e.g., production of initial CRLs, export of CA public key).
1 CA建立：建立新CA时，需要某些步骤（例如，生成初始CRL，导出CA公钥）。
2 End entity initialization: this includes importing a root CA public key and requesting information about the options supported by a PKI management entity.
2终端实体初始化：这包括导入根CA公钥和请求有关PKI管理实体支持的选项的信息。
3 Certification: various operations result in the creation of new certificates:
3认证：各种操作导致创建新证书：
3.1 initial registration/certification: This is the process whereby an end entity first makes itself known to a CA or RA, prior to the CA issuing a certificate or certificates for that end entity. The end result of this process (when it is successful) is that a CA issues a certificate for an end entity's public key, and returns that certificate to the end entity and/or posts that certificate in a public repository. This process may, and typically will, involve multiple "steps", possibly including an initialization of the end entity's equipment. For example, the end entity's equipment must be securely initialized with the public key of a CA, to be used in validating certificate paths. Furthermore, an end entity typically needs to be initialized with its own key pair(s).
3.1 初始注册/认证：这是在CA为最终实体颁发一个或多个证书之前，最终实体首先向CA或RA表明自己的过程。此过程的最终结果（成功时）是CA为最终实体的公钥颁发证书，并将该证书返回给最终实体和/或将该证书发布到公共存储库中。该过程可能，并且通常将涉及多个“步骤”，可能包括最终实体设备的初始化。例如，终端实体的设备必须使用CA的公钥进行安全初始化，以用于验证证书路径。此外，终端实体通常需要使用自己的密钥对进行初始化。
3.2 key pair update: Every key pair needs to be updated regularly (i.e., replaced with a new key pair), and a new certificate needs to be issued.
3.2 密钥对更新：每个密钥对都需要定期更新（即用新密钥对替换），并且需要颁发新证书。
3.3 certificate update: As certificates expire they may be "refreshed" if nothing relevant in the environment has changed.
3.3 证书更新：当证书过期时，如果环境中没有任何相关内容发生更改，则可能会“刷新”证书。
3.4 CA key pair update: As with end entities, CA key pairs need to be updated regularly; however, different mechanisms are required.
3.4 CA密钥对更新：与终端实体一样，CA密钥对需要定期更新；然而，需要不同的机制。
3.5 cross-certification request: One CA requests issuance of a cross-certificate from another CA. For the purposes of this standard, the following terms are defined. A "cross-certificate" is a certificate in which the subject CA and the issuer CA are distinct and SubjectPublicKeyInfo contains a verification key (i.e., the certificate has been issued for the subject CA's signing key pair). When it is necessary to distinguish more finely, the following terms may be used: a cross-certificate is called an "inter-domain cross-certificate" if the subject and issuer CAs belong to different administrative domains; it is called an "intra-domain cross-certificate" otherwise.
3.5 交叉认证请求：一个CA请求从另一个CA颁发交叉证书。在本标准中，定义了以下术语。“交叉证书”是一种证书，其中主体CA和颁发者CA是不同的，并且主体PublicKeyInfo包含验证密钥（即，已为主体CA的签名密钥对颁发证书）。当需要更精细地区分时，可以使用以下术语：如果主体和颁发者CA属于不同的管理域，则交叉证书称为“域间交叉证书”；否则称为“域内交叉证书”。
Notes:
笔记：
Note 1. The above definition of "cross-certificate" aligns with the defined term "CA-certificate" in X.509. Note that this term is not to be confused with the X.500 "cACertificate" attribute type, which is unrelated.
注1。上述“交叉证书”的定义与X.509中定义的术语“CA证书”一致。请注意，不要将此术语与X.500“cACertificate”属性类型混淆，后者是不相关的。
Note 2. In many environments the term "cross-certificate", unless further qualified, will be understood to be synonymous with "inter-domain cross-certificate" as defined above.
附注2。在许多环境中，“交叉证书”一词除非进一步限定，否则将被理解为上文定义的“域间交叉证书”的同义词。
Note 3. Issuance of cross-certificates may be, but is not necessarily, mutual; that is, two CAs may issue cross-certificates for each other.
附注3。交叉证书的签发可能是相互的，但不一定是相互的；也就是说，两个CA可以相互颁发交叉证书。
3.6 cross-certificate update: Similar to a normal certificate update but involving a cross-certificate.
3.6 交叉证书更新：与普通证书更新类似，但涉及交叉证书。
4 Certificate/CRL discovery operations: some PKI management operations result in the publication of certificates or CRLs:
4证书/CRL发现操作：某些PKI管理操作导致证书或CRL的发布：
4.1 certificate publication: Having gone to the trouble of producing a certificate, some means for publishing it is needed. The "means" defined in PKIX MAY involve the messages specified in Sections 3.3.13 - 3.3.16, or MAY involve other methods (LDAP, for example) as described in the "Operational Protocols" documents of the PKIX series of specifications.
4.1 证书发布：遇到了生成证书的麻烦之后，需要一些发布证书的方法。PKIX中定义的“手段”可能涉及第3.3.13-3.3.16节中规定的消息，或者可能涉及PKIX系列规范的“操作协议”文件中所述的其他方法（例如LDAP）。
4.2 CRL publication: As for certificate publication.
4.2 CRL发布：与证书发布一样。
5 Recovery operations: some PKI management operations are used when an end entity has "lost" its PSE:
5恢复操作：当终端实体“丢失”其PSE时，使用一些PKI管理操作：
5.1 key pair recovery: As an option, user client key materials (e.g., a user's private key used for decryption purposes) MAY be backed up by a CA, an RA, or a key backup system associated with a CA or RA. If an entity needs to recover these backed up key materials (e.g., as a result of a forgotten password or a lost key chain file), a protocol exchange may be needed to support such recovery.
5.1 密钥对恢复：作为一种选择，用户客户端密钥材料（例如，用于解密目的的用户私钥）可以由CA、RA或与CA或RA关联的密钥备份系统进行备份。如果实体需要恢复这些备份的密钥材料（例如，由于忘记密码或丢失密钥链文件），则可能需要协议交换来支持此类恢复。
6 Revocation operations: some PKI operations result in the creation of new CRL entries and/or new CRLs:
6撤销操作：某些PKI操作导致创建新的CRL条目和/或新的CRL：
6.1 revocation request: An authorized person advises a CA of an abnormal situation requiring certificate revocation.
6.1 撤销请求：授权人通知CA需要撤销证书的异常情况。
7 PSE operations: whilst the definition of PSE operations (e.g., moving a PSE, changing a PIN, etc.) are beyond the scope of this specification, we do define a PKIMessage (CertRepMessage) which can form the basis of such operations.
7 PSE操作：虽然PSE操作的定义（例如，移动PSE、更改PIN等）超出了本规范的范围，但我们确实定义了可构成此类操作基础的PKIMessage（CertRepMessage）。
Note that on-line protocols are not the only way of implementing the above operations. For all operations 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 operations MAY be achieved as part of the physical token delivery.
注意，在线协议不是实现上述操作的唯一方法。对于所有操作，都有实现相同结果的离线方法，本规范不强制使用在线协议。例如，当使用硬件令牌时，许多操作可以作为物理令牌传递的一部分来实现。
Later sections define a set of standard messages supporting the above operations. The protocols for conveying these exchanges in different environments (file based, on-line, E-mail, and WWW) is also specified.
后面的部分定义了一组支持上述操作的标准消息。还指定了在不同环境（基于文件、在线、电子邮件和WWW）中传输这些交换的协议。
The first step for an end entity in dealing with PKI management entities is to request information about the PKI functions supported and to securely acquire a copy of the relevant root CA public key(s).
终端实体处理PKI管理实体的第一步是请求有关支持的PKI功能的信息，并安全地获取相关根CA公钥的副本。
There are many schemes that can be used to achieve initial registration and certification of end entities. No one method is suitable for all situations due to the range of policies which a CA may implement and the variation in the types of end entity which can occur.
有许多方案可用于实现最终实体的初始注册和认证。由于CA可能实施的策略范围以及可能发生的终端实体类型的变化，没有一种方法适用于所有情况。
We can however, classify the initial registration / certification schemes that are supported by this specification. Note that the word "initial", above, is crucial - we are dealing with the situation where the end entity in question has had no previous contact with the PKI. Where the end entity already possesses certified keys then some simplifications/alternatives are possible.
但是，我们可以对本规范支持的初始注册/认证方案进行分类。请注意，上面的“初始”一词是至关重要的——我们正在处理有关最终实体以前没有与PKI接触的情况。如果终端实体已经拥有认证密钥，则可以进行一些简化/替代。
Having classified the schemes that are supported by this specification we can then specify some as mandatory and some as optional. The goal is that the mandatory schemes cover a sufficient number of the cases which will arise in real use, whilst the optional schemes are available for special cases which arise less frequently. In this way we achieve a balance between flexibility and ease of implementation.
对本规范支持的方案进行分类后，我们可以将一些方案指定为强制方案，另一些方案指定为可选方案。我们的目标是，强制性计划涵盖实际使用中出现的足够数量的情况，而可选计划可用于不太频繁出现的特殊情况。通过这种方式，我们实现了灵活性和易实现性之间的平衡。
We will now describe the classification of initial registration / certification schemes.
我们现在将介绍初始注册/认证计划的分类。
In terms of the PKI messages which are produced we can regard the initiation of the initial registration / certification exchanges as occurring wherever the first PKI message relating to the end entity is produced. Note that the real-world initiation of the registration / certification procedure may occur elsewhere (e.g., a personnel department may telephone an RA operator).
就生成的PKI消息而言，我们可以将初始注册/认证交换的启动视为发生在与最终实体相关的第一个PKI消息生成的任何地方。请注意，注册/认证程序的实际启动可能发生在其他地方（例如，人事部门可能会致电RA操作员）。
The possible locations are at the end entity, an RA, or a CA.
可能的位置位于终端实体、RA或CA。
The on-line messages produced by the end entity that requires a certificate may be authenticated or not. The requirement here is to authenticate the origin of any messages from the end entity to the PKI (CA/RA).
由需要证书的终端实体生成的在线消息可以通过身份验证，也可以不通过身份验证。这里的要求是验证从终端实体到PKI（CA/RA）的任何消息的来源。
In this specification, such authentication is achieved by the PKI (CA/RA) issuing the end entity with a secret value (initial authentication key) and reference value (used to identify the transaction) via some out-of-band means. The initial authentication key can then be used to protect relevant PKI messages.
在本规范中，这种认证是通过PKI（CA/RA）通过一些带外手段向终端实体发布秘密值（初始认证密钥）和参考值（用于识别交易）来实现的。然后，可以使用初始身份验证密钥来保护相关的PKI消息。
We can thus classify the initial registration/certification scheme according to whether or not the on-line end entity -> PKI messages are authenticated or not.
因此，我们可以根据在线终端实体->PKI消息是否经过身份验证来对初始注册/认证方案进行分类。
Note 1: We do not discuss the authentication of the PKI -> end entity messages here as this is always REQUIRED. In any case, it can be achieved simply once the root-CA public key has been installed at the end entity's equipment or it can be based on the initial authentication key.
注1：此处不讨论PKI->end entity消息的身份验证，因为这始终是必需的。在任何情况下，只要在终端实体的设备上安装了根CA公钥，就可以实现，也可以基于初始身份验证密钥。
Note 2: An initial registration / certification procedure can be secure where the messages from the end entity are authenticated via some out- of-band means (e.g., a subsequent visit).
注2：初始注册/认证程序可以是安全的，其中来自终端实体的消息通过一些带外方式进行认证（例如，后续访问）。
In this specification, "key generation" is regarded as occurring wherever either the public or private component of a key pair first occurs in a PKIMessage. Note that this does not preclude a
在本规范中，“密钥生成”被视为发生在密钥对的公共或私有组件首次出现在PKI消息中的任何地方。请注意，这并不排除
centralized key generation service - the actual key pair MAY have been generated elsewhere and transported to the end entity, RA, or CA using a (proprietary or standardized) key generation request/response protocol (outside the scope of this specification).
集中式密钥生成服务-实际密钥对可能已在别处生成，并使用（专有或标准化）密钥生成请求/响应协议（不在本规范范围内）传输到最终实体、RA或CA。
There are thus three possibilities for the location of "key generation": the end entity, an RA, or a CA.
因此，“密钥生成”的位置有三种可能：终端实体、RA或CA。
Following the creation of an initial certificate for an end entity, additional assurance can be gained by having the end entity explicitly confirm successful receipt of the message containing (or indicating the creation of) the certificate. Naturally, this confirmation message must be protected (based on the initial authentication key or other means).
在为终端实体创建初始证书之后，可以通过让终端实体明确确认成功接收到包含（或指示创建）证书的消息来获得额外的保证。当然，必须保护此确认消息（基于初始身份验证密钥或其他方式）。
This gives two further possibilities: confirmed or not.
这提供了两种进一步的可能性：确认或不确认。
The criteria above allow for a large number of initial registration / certification schemes. This specification mandates that conforming CA equipment, RA equipment, and EE equipment MUST support the second scheme listed below. Any entity MAY additionally support other schemes, if desired.
上述标准允许大量初始注册/认证计划。本规范要求合格的CA设备、RA设备和EE设备必须支持下面列出的第二个方案。如果需要，任何实体都可以额外支持其他方案。
In terms of the classification above, this scheme is, in some ways, the simplest possible, where:
就上述分类而言，该方案在某些方面是最简单的，其中：
- initiation occurs at the certifying CA; - no on-line message authentication is required; - "key generation" occurs at the certifying CA (see Section 2.2.1.3); - no confirmation message is required.
- 启动发生在认证CA处；-不需要在线消息身份验证；-“密钥生成”发生在认证CA（见第2.2.1.3节）；-不需要确认信息。
In terms of message flow, this scheme means that the only message required is sent from the CA to the end entity. The message must contain the entire PSE for the end entity. Some out-of-band means must be provided to allow the end entity to authenticate the message received and decrypt any encrypted values.
在消息流方面，该方案意味着唯一需要的消息是从CA发送到终端实体。消息必须包含终端实体的整个PSE。必须提供一些带外手段，以允许终端实体对接收到的消息进行身份验证并解密任何加密值。
In terms of the classification above, this scheme is where:
就上述分类而言，本方案包括：
- initiation occurs at the end entity; - message authentication is REQUIRED; - "key generation" occurs at the end entity (see Section 2.2.1.3); - a confirmation message is REQUIRED.
- 初始化发生在结束实体处；-需要消息身份验证；-“密钥生成”发生在终端实体（见第2.2.1.3节）；-需要确认信息。
In terms of message flow, the basic authenticated scheme is as follows:
在消息流方面，基本认证方案如下：
End entity RA/CA
========== =============
out-of-band distribution of Initial Authentication
Key (IAK) and reference value (RA/CA -> EE)
Key generation
Creation of certification request
Protect request with IAK
-->>--certification request-->>--
verify request
process request
create response
--<<--certification response--<<--
handle response
create confirmation
-->>--confirmation message-->>--
verify confirmation
End entity RA/CA
========== =============
out-of-band distribution of Initial Authentication
Key (IAK) and reference value (RA/CA -> EE)
Key generation
Creation of certification request
Protect request with IAK
-->>--certification request-->>--
verify request
process request
create response
--<<--certification response--<<--
handle response
create confirmation
-->>--confirmation message-->>--
verify confirmation
(Where verification of the confirmation message fails, the RA/CA MUST revoke the newly issued certificate if it has been published or otherwise made available.)
（如果确认消息验证失败，RA/CA必须撤销新颁发的证书（如果该证书已发布或可用）
In order to prevent certain attacks and to allow a CA/RA to properly check the validity of the binding between an end entity and a key pair, the PKI management operations specified here make it possible for an end entity to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. A given CA/RA is free to choose how to enforce POP (e.g., out-of-band procedural means versus PKIX-CMP in-band messages) in its certification exchanges (i.e., this may be a policy issue). However, it is REQUIRED that CAs/RAs MUST enforce POP by some means because there are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the
为了防止某些攻击并允许CA/RA正确检查终端实体和密钥对之间绑定的有效性，此处指定的PKI管理操作使终端实体能够证明其拥有（即能够使用）与请求证书的公钥相对应的私钥。给定CA/RA可自由选择如何在其认证交换中强制实施POP（例如，带外程序手段与PKIX-CMP带内消息）（即，这可能是一个政策问题）。但是，要求CAs/RAs必须通过某种方式强制执行POP，因为目前使用的许多非PKIX操作协议（各种电子邮件协议就是一个例子）没有明确检查终端实体和私钥之间的绑定。直到运行协议验证
binding (for signature, encryption, and key agreement key pairs) exist, and are ubiquitous, this binding can only be assumed to have been verified by the CA/RA. Therefore, if the binding is not verified by the CA/RA, certificates in the Internet Public-Key Infrastructure end up being somewhat less meaningful.
绑定（用于签名、加密和密钥协议密钥对）存在并且无处不在，只能假设该绑定已由CA/RA验证。因此，如果绑定未经CA/RA验证，则Internet公钥基础设施中的证书的意义将有所降低。
POP is accomplished in different ways depending upon the type of key for which a certificate is requested. If a key can be used for multiple purposes (e.g., an RSA key) then any appropriate method MAY be used (e.g., a key which may be used for signing, as well as other purposes, SHOULD NOT be sent to the CA/RA in order to prove possession).
根据请求证书的密钥类型，POP以不同的方式完成。如果密钥可用于多种目的（例如RSA密钥），则可使用任何适当的方法（例如，可用于签名以及其他目的的密钥，不应发送给CA/RA以证明其拥有权）。
This specification explicitly allows for cases where an end entity supplies the relevant proof to an RA and the RA subsequently attests to the CA that the required proof has been received (and validated!). For example, an end entity wishing to have a signing key certified could send the appropriate signature to the RA which then simply notifies the relevant CA that the end entity has supplied the required proof. Of course, such a situation may be disallowed by some policies (e.g., CAs may be the only entities permitted to verify POP during certification).
本规范明确允许终端实体向RA提供相关证据，并且RA随后向CA证明已收到（并验证！）所需证据的情况。例如，希望认证签名密钥的终端实体可以将适当的签名发送给RA，RA然后简单地通知相关CA终端实体已经提供了所需的证明。当然，某些政策可能不允许出现这种情况（例如，CA可能是认证期间唯一允许验证POP的实体）。
For signature keys, the end entity can sign a value to prove possession of the private key.
对于签名密钥，终端实体可以签署一个值来证明拥有私钥。
For encryption keys, the end entity can provide the private key to the CA/RA, or can be required to decrypt a value in order to prove possession of the private key (see Section 3.2.8). Decrypting a value can be achieved either directly or indirectly.
对于加密密钥，终端实体可以向CA/RA提供私钥，或者需要解密一个值以证明拥有私钥（见第3.2.8节）。解密值可以直接或间接实现。
The direct method is for the RA/CA to issue a random challenge to which an immediate response by the EE is required.
直接方法是RA/CA发出随机质询，要求EE立即响应。
The indirect method is to issue a certificate which is encrypted for the end entity (and have the end entity demonstrate its ability to decrypt this certificate in the confirmation message). This allows a CA to issue a certificate in a form which can only be used by the intended end entity.
间接方法是颁发为最终实体加密的证书（并让最终实体在确认消息中演示其解密该证书的能力）。这允许CA以只能由预期的最终实体使用的形式颁发证书。
This specification encourages use of the indirect method because this requires no extra messages to be sent (i.e., the proof can be demonstrated using the {request, response, confirmation} triple of messages).
本规范鼓励使用间接方法，因为这不需要发送额外的消息（即，可以使用{request，response，confirmation}三重消息来证明）。
For key agreement keys, the end entity and the PKI management entity (i.e., CA or RA) must establish a shared secret key in order to prove that the end entity has possession of the private key.
对于密钥协议密钥，最终实体和PKI管理实体（即CA或RA）必须建立共享密钥，以证明最终实体拥有私钥。
Note that this need not impose any restrictions on the keys that can be certified by a given CA -- in particular, for Diffie-Hellman keys the end entity may freely choose its algorithm parameters -- provided that the CA can generate a short-term (or one-time) key pair with the appropriate parameters when necessary.
注意，这不需要对可由给定CA认证的密钥施加任何限制——特别是对于Diffie-Hellman密钥，终端实体可以自由选择其算法参数——前提是CA可以在必要时生成具有适当参数的短期（或一次性）密钥对。
This discussion only applies to CAs that are a root CA for some end entity.
本讨论仅适用于作为某些终端实体的根CA的CA。
The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa. Thus when a CA updates its key pair it must generate two extra cACertificate attribute values if certificates are made available using an X.500 directory (for a total of four: OldWithOld; OldWithNew; NewWithOld; and NewWithNew).
这里描述的过程的基础是CA使用其以前的私钥保护其新公钥，反之亦然。因此，当CA更新其密钥对时，如果使用X.500目录提供证书，则必须生成两个额外的cACertificate属性值（总共四个：OldWithOld；OldWithNew；NewWithOld；和NewWithNew）。
When a CA changes its key pair those entities who have acquired the old CA public key via "out-of-band" means are most affected. It is these end entities who will need access to the new CA public key protected with the old CA private key. However, they will only require this for a limited period (until they have acquired the new CA public key via the "out-of-band" mechanism). This will typically be easily achieved when these end entities' certificates expire.
当CA更改其密钥对时，通过“带外”方式获取旧CA公钥的实体受到的影响最大。正是这些终端实体需要访问由旧CA私钥保护的新CA公钥。但是，他们将只在有限的时间内需要此密钥（直到他们通过“带外”机制获得新的CA公钥）。当这些终端实体的证书过期时，这通常很容易实现。
The data structure used to protect the new and old CA public keys is a standard certificate (which may also contain extensions). There are no new data structures required.
用于保护新旧CA公钥的数据结构是一个标准证书（也可能包含扩展名）。不需要新的数据结构。
Note 1. This scheme does not make use of any of the X.509 v3 extensions as it must be able to work even for version 1 certificates. The presence of the KeyIdentifier extension would make for efficiency improvements.
注1。此方案不使用任何X.509 v3扩展，因为它必须能够工作，即使对于版本1证书也是如此。KeyIdentifier扩展的存在将有助于提高效率。
Note 2. While the scheme could be generalized to cover cases where the CA updates its key pair more than once during the validity period of one of its end entities' certificates, this generalization seems of dubious value. Not having this generalization simply means that the validity period of a CA key pair must be greater than the validity period of any certificate issued by that CA using that key pair.
附注2。虽然该方案可以推广到CA在其一个终端实体的证书的有效期内多次更新其密钥对的情况，但这种推广似乎价值不大。没有这种泛化仅仅意味着CA密钥对的有效期必须大于使用该密钥对的CA颁发的任何证书的有效期。
Note 3.This scheme forces end entities to acquire the new CA public key on the expiry of the last certificate they owned that was signed with the old CA private key (via the "out-of-band" means). Certificate and/or key update operations occurring at other times do not necessarily require this (depending on the end entity's equipment).
注3.该方案强制终端实体在其拥有的最后一个证书到期时获得新的CA公钥，该证书是用旧CA私钥签署的（通过“带外”方式）。其他时间发生的证书和/或密钥更新操作不一定需要（取决于最终实体的设备）。
To change the key of the CA, the CA operator does the following:
要更改CA的密钥，CA操作员执行以下操作：
1. Generate a new key pair;
1. 生成新的密钥对；
2. Create a certificate containing the old CA public key signed with the new private key (the "old with new" certificate);
2. 创建包含使用新私钥签名的旧CA公钥的证书（“新旧”证书）；
3. Create a certificate containing the new CA public key signed with the old private key (the "new with old" certificate);
3. 创建一个包含使用旧私钥签名的新CA公钥的证书（“新旧证书”）；
4. Create a certificate containing the new CA public key signed with the new private key (the "new with new" certificate);
4. 创建一个证书，其中包含使用新私钥签名的新CA公钥（“new with new”证书）；
5. Publish these new certificates via the directory and/or other means (perhaps using a CAKeyUpdAnn message);
5. 通过目录和/或其他方式发布这些新证书（可能使用Cakeyupdan消息）；
6. Export the new CA public key so that end entities may acquire it using the "out-of-band" mechanism (if required).
6. 导出新的CA公钥，以便最终实体可以使用“带外”机制获取它（如果需要）。
The old CA private key is then no longer required. The old CA public key will however remain in use for some time. The time when the old CA public key is no longer required (other than for non-repudiation) will be when all end entities of this CA have securely acquired the new CA public key.
然后不再需要旧的CA私钥。但是，旧的CA公钥将继续使用一段时间。不再需要旧CA公钥的时间（不可抵赖性除外）将是此CA的所有终端实体安全获取新CA公钥的时间。
The "old with new" certificate must have a validity period starting at the generation time of the old key pair and ending at the expiry date of the old public key.
“新旧”证书的有效期必须从旧密钥对的生成时开始，到旧公钥的到期日结束。
The "new with old" certificate must have a validity period starting at the generation time of the new key pair and ending at the time by which all end entities of this CA will securely possess the new CA public key (at the latest, the expiry date of the old public key).
“新旧并存”证书的有效期必须从新密钥对的生成时开始，到该CA的所有终端实体将安全地拥有新CA公钥时结束（最迟为旧公钥的到期日）。
The "new with new" certificate must have a validity period starting at the generation time of the new key pair and ending at the time by which the CA will next update its key pair.
“new with new”证书的有效期必须从新密钥对的生成时开始，到CA下次更新其密钥对时结束。
2.4.2 Verifying Certificates.
2.4.2 验证证书。
Normally when verifying a signature, the verifier verifies (among other things) the certificate containing the public key of the signer. However, once a CA is allowed to update its key there are a range of new possibilities. These are shown in the table below.
通常在验证签名时，验证者会验证（除其他外）包含签名者公钥的证书。然而，一旦CA被允许更新其密钥，就会有一系列新的可能性。如下表所示。
Repository contains NEW Repository contains only OLD and OLD public keys public key (due to, e.g., delay in publication)
存储库包含新存储库仅包含旧公钥和旧公钥公钥（例如，由于发布延迟）
PSE PSE Contains PSE Contains PSE Contains Contains OLD public NEW public OLD public NEW public key key key key
PSE包含PSE包含PSE包含PSE包含旧公钥新公钥旧公钥新公钥
Signer's Case 1: Case 3: Case 5: Case 7: certifi- This is In this case Although the In this case cate is the the verifier CA operator the CA protected standard must access has not operator has using NEW case where the updated the not updated public the directory in directory the the directory key verifier order to get verifier can and so the can the value of verify the verification directly the NEW certificate will FAIL verify the public key directly - certificate this is thus without the same as using the case 1. directory
签名者案例1：案例3：案例5：案例7：certifi-在这种情况下，尽管cate是验证器CA操作员，但CA保护标准必须访问的CA操作员没有使用新的案例，其中更新的未更新的公共目录在目录中，目录密钥验证器为了获得验证器can和can直接验证新证书的值将无法直接验证公钥-证书这与使用案例1的情况不同。目录
Signer's Case 2: Case 4: Case 6: Case 8: certifi- In this In this case The verifier Although the cate is case the the verifier thinks this CA operator protected verifier can directly is the has not using OLD must verify the situation of updated the public access the certificate case 2 and directory the key directory without will access verifier can in order using the the verify the to get the directory directory; certificate value of however, the directly - the OLD verification this is thus public key will FAIL the same as case 4.
签名者案例2：案例4：案例6：案例8：certifi-在这种情况下，验证器虽然是cate案例，但验证器认为此CA运营商保护的验证器可以直接是未使用旧的必须验证更新的公共访问证书的情况案例2和目录密钥目录没有将访问验证器可以按顺序使用验证获取目录；但是，直接验证这是公钥的旧验证的证书值将失败，与案例4相同。
2.4.2.1 Verification in cases 1, 4, 5 and 8.
2.4.2.1 案例1、4、5和8中的验证。
In these cases the verifier has a local copy of the CA public key which can be used to verify the certificate directly. This is the same as the situation where no key change has occurred.
在这些情况下，验证器具有CA公钥的本地副本，可用于直接验证证书。这与没有发生关键变化的情况相同。
Note that case 8 may arise between the time when the CA operator has generated the new key pair and the time when the CA operator stores the updated attributes in the directory. Case 5 can only arise if the CA operator has issued both the signer's and verifier's certificates during this "gap" (the CA operator SHOULD avoid this as it leads to the failure cases described below).
注意，情况8可能出现在CA操作员生成新密钥对的时间和CA操作员将更新的属性存储在目录中的时间之间。仅当CA运营商在此“间隙”期间同时颁发了签名者和验证者的证书时，才会出现情况5（CA运营商应避免这种情况，因为它会导致以下所述的失败情况）。
2.4.2.2 Verification in case 2.
2.4.2.2 案例2中的验证。
In case 2 the verifier must get access to the old public key of the CA. The verifier does the following:
在情况2中，验证器必须访问CA的旧公钥。验证器执行以下操作：
1. Look up the caCertificate attribute in the directory and pick the OldWithNew certificate (determined based on validity periods); 2. Verify that this is correct using the new CA key (which the verifier has locally); 3. If correct, check the signer's certificate using the old CA key.
1. 在目录中查找caCertificate属性，选择OldWithNew证书（根据有效期确定）；2.使用新的CA密钥（验证器在本地拥有）验证这是正确的；3.如果正确，请使用旧CA密钥检查签名者的证书。
Case 2 will arise when the CA operator has issued the signer's certificate, then changed key and then issued the verifier's certificate, so it is quite a typical case.
当CA操作员颁发签名者证书，然后更改密钥，然后颁发验证者证书时，会出现案例2，因此这是一个非常典型的案例。
2.4.2.3 Verification in case 3.
2.4.2.3 案例3中的验证。
In case 3 the verifier must get access to the new public key of the CA. The verifier does the following:
在情况3中，验证者必须访问CA的新公钥。验证者执行以下操作：
1. Look up the CACertificate attribute in the directory and pick the NewWithOld certificate (determined based on validity periods); 2. Verify that this is correct using the old CA key (which the verifier has stored locally); 3. If correct, check the signer's certificate using the new CA key.
1. 在目录中查找CACertificate属性，选择NewWithOld证书（根据有效期确定）；2.使用旧CA密钥（验证器已在本地存储）验证这一点是否正确；3.如果正确，请使用新CA密钥检查签名者的证书。
Case 3 will arise when the CA operator has issued the verifier's certificate, then changed key and then issued the signer's certificate, so it is also quite a typical case.
当CA运营商颁发了验证者的证书，然后更改了密钥，然后颁发了签名者的证书时，会出现第3种情况，因此这也是一个非常典型的情况。
2.4.2.4 Failure of verification in case 6.
2.4.2.4 案例6中的验证失败。
In this case the CA has issued the verifier's PSE containing the new key without updating the directory attributes. This means that the verifier has no means to get a trustworthy version of the CA's old key and so verification fails.
在这种情况下，CA已发出包含新密钥的验证器PSE，而不更新目录属性。这意味着验证器无法获得CA旧密钥的可信版本，因此验证失败。
Note that the failure is the CA operator's fault.
请注意，故障是CA操作员的故障。
2.4.2.5 Failure of verification in case 7.
2.4.2.5 案例7中的验证失败。
In this case the CA has issued the signer's certificate protected with the new key without updating the directory attributes. This means that the verifier has no means to get a trustworthy version of the CA's new key and so verification fails.
在这种情况下，CA已颁发由新密钥保护的签名者证书，而不更新目录属性。这意味着验证器无法获得CA新密钥的可信版本，因此验证失败。
Note that the failure is again the CA operator's fault.
请注意，故障再次是CA操作员的故障。
As we saw above the verification of a certificate becomes more complex once the CA is allowed to change its key. This is also true for revocation checks as the CA may have signed the CRL using a newer private key than the one that is within the user's PSE.
如上所述，一旦CA被允许更改其密钥，证书的验证就变得更加复杂。对于撤销检查也是如此，因为CA可能已使用比用户PSE中的私钥更新的私钥签署CRL。
The analysis of the alternatives is as for certificate verification.
对替代方案的分析与证书验证相同。
This section contains descriptions of the data structures required for PKI management messages. Section 4 describes constraints on their values and the sequence of events for each of the various PKI management operations. Section 5 describes how these may be encapsulated in various transport mechanisms.
本节介绍PKI管理消息所需的数据结构。第4节描述了对其值的约束以及各种PKI管理操作的事件顺序。第5节描述了如何将其封装在各种传输机制中。
All of the messages used in this specification for the purposes of PKI management use the following structure:
本规范中用于PKI管理的所有消息都使用以下结构：
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
The PKIHeader contains information which is common to many PKI messages.
PKI标头包含许多PKI消息所共有的信息。
The PKIBody contains message-specific information.
正文包含特定于消息的信息。
The PKIProtection, when used, contains bits that protect the PKI message.
使用PKI保护时，包含保护PKI消息的位。
The extraCerts field can contain certificates that may be useful to the recipient. For example, this can be used by a CA or RA to present an end entity with certificates that it needs to verify its own new certificate (if, for example, the CA that issued the end entity's certificate is not a root CA for the end entity). Note that this field does not necessarily contain a certification path - the recipient may have to sort, select from, or otherwise process the extra certificates in order to use them.
extraCerts字段可以包含可能对收件人有用的证书。例如，CA或RA可以使用此功能向终端实体提供其需要验证自己的新证书的证书（例如，如果颁发终端实体证书的CA不是终端实体的根CA）。请注意，此字段不一定包含证书路径-收件人可能必须对额外的证书进行排序、选择或以其他方式处理才能使用这些证书。
All PKI messages require some header information for addressing and transaction identification. Some of this information will also be present in a transport-specific envelope; however, if the PKI message is protected then this information is also protected (i.e., we make no assumption about secure transport).
所有PKI消息都需要一些头信息来寻址和事务标识。其中一些信息也将出现在运输专用信封中；但是，如果PKI消息受到保护，则该信息也会受到保护（即，我们不假设安全传输）。
The following data structure is used to contain this information:
以下数据结构用于包含此信息：
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable"; i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response and confirmation messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable"; i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response and confirmation messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field not primarily intended for human consumption)
}
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field not primarily intended for human consumption)
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String (note: each UTF8String SHOULD
-- include an RFC 1766 language tag to indicate the language
-- of the contained text)
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String (note: each UTF8String SHOULD
-- include an RFC 1766 language tag to indicate the language
-- of the contained text)
The pvno field is fixed (at one) for this version of this specification.
对于本规范的此版本，pvno字段是固定的（在一处）。
The sender field contains the name of the sender of the PKIMessage. This name (in conjunction with senderKID, if supplied) should be usable to verify the protection on the message. If nothing about the sender is known to the sending entity (e.g., in the init. req. message, where the end entity may not know its own Distinguished Name (DN), e-mail name, IP address, etc.), then the "sender" field MUST contain a "NULL" value; that is, the SEQUENCE OF relative distinguished names is of zero length. In such a case the senderKID field MUST hold an identifier (i.e., a reference number) which indicates to the receiver the appropriate shared secret information to use to verify the message.
发件人字段包含PKI消息的发件人的名称。此名称（与senderKID一起，如果提供）应可用于验证消息的保护。如果发送实体对发送者一无所知（例如，在初始请求消息中，终端实体可能不知道自己的可分辨名称（DN）、电子邮件名称、IP地址等），则“发送者”字段必须包含“NULL”值；也就是说，相对可分辨名称的序列长度为零。在这种情况下，senderKID字段必须包含一个标识符（即参考号），该标识符向接收方指示用于验证消息的适当共享机密信息。
The recipient field contains the name of the recipient of the PKIMessage. This name (in conjunction with recipKID, if supplied) should be usable to verify the protection on the message.
收件人字段包含PKI邮件收件人的名称。此名称（与recipKID一起使用，如果提供）应可用于验证消息上的保护。
The protectionAlg field specifies the algorithm used to protect the message. If no protection bits are supplied (note that PKIProtection is OPTIONAL) then this field MUST be omitted; if protection bits are supplied then this field MUST be supplied.
protectionAlg字段指定用于保护消息的算法。如果未提供保护位（请注意，PKI保护是可选的），则必须忽略此字段；如果提供了保护位，则必须提供此字段。
senderKID and recipKID are usable to indicate which keys have been used to protect the message (recipKID will normally only be required where protection of the message uses Diffie-Hellman (DH) keys).
senderKID和recipKID可用于指示已使用哪些密钥来保护消息（通常仅当消息保护使用Diffie-Hellman（DH）密钥时才需要recipKID）。
The transactionID field within the message header MAY be used to allow the recipient of a response message to correlate this with a previously issued request. For example, in the case of an RA there may be many requests "outstanding" at a given moment.
消息头中的transactionID字段可用于允许响应消息的收件人将其与先前发出的请求关联起来。例如，在RA的情况下，在给定时刻可能有许多“未完成”的请求。
The senderNonce and recipNonce fields protect the PKIMessage against replay attacks.
SenderOnce和RecipOnce字段保护PKI消息免受重播攻击。
The messageTime field contains the time at which the sender created the message. This may be useful to allow end entities to correct their local time to be consistent with the time on a central system.
messageTime字段包含发件人创建邮件的时间。这可能有助于允许终端实体将其本地时间更正为与中央系统上的时间一致。
The freeText field may be used to send a human-readable message to the recipient (in any number of languages). The first language used in this sequence indicates the desired language for replies.
freeText字段可用于向接收者发送人类可读的消息（任何语言）。此序列中使用的第一种语言表示所需的答复语言。
The generalInfo field may be used to send machine-processable additional data to the recipient.
generalInfo字段可用于向收件人发送机器可处理的附加数据。
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --Initialization Request
ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
-- the PKCS #10 certification request (see [PKCS10])
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Request
krp [10] KeyRecRepContent, --Key Recovery Response
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Response
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
conf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent --Error Message
}
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --Initialization Request
ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
-- the PKCS #10 certification request (see [PKCS10])
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Request
krp [10] KeyRecRepContent, --Key Recovery Response
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Response
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
conf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent --Error Message
}
The specific types are described in Section 3.3 below.
具体类型见下文第3.3节。
Some PKI messages will be protected for integrity. (Note that if an asymmetric algorithm is used to protect a message and the relevant public component has been certified already, then the origin of message can also be authenticated. On the other hand, if the public component is uncertified then the message origin cannot be automatically authenticated, but may be authenticated via out-of-band means.)
某些PKI消息将受到完整性保护。（请注意，如果使用非对称算法来保护消息，并且相关的公共组件已经过认证，则也可以对消息源进行身份验证。另一方面，如果公共组件未经认证，则消息源无法自动进行身份验证，但可以通过带外平均值进行身份验证。）s、 )
When protection is applied the following structure is used:
当应用保护时，使用以下结构：
PKIProtection ::= BIT STRING
PKIProtection ::= BIT STRING
The input to the calculation of PKIProtection is the DER encoding of the following data structure:
PKI保护计算的输入是以下数据结构的DER编码：
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
There MAY be cases in which the PKIProtection BIT STRING is deliberately not used to protect a message (i.e., this OPTIONAL field is omitted) because other protection, external to PKIX, will instead be applied. Such a choice is explicitly allowed in this specification. Examples of such external protection include PKCS #7 [PKCS7] and Security Multiparts [RFC1847] encapsulation of the PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the relevant PKIHeader information is securely carried in the external mechanism); specification of external protection using PKCS #7 will be provided in a separate document. It is noted, however, that many such external mechanisms require that the end entity already possesses a public-key certificate, and/or a unique Distinguished Name, and/or other such infrastructure-related information. Thus, they may not be appropriate for initial registration, key-recovery, or any other process with "boot-strapping" characteristics. For those cases it may be necessary that the PKIProtection parameter be used. In the future, if/when external mechanisms are modified to accommodate boot-strapping scenarios, the use of PKIProtection may become rare or non-existent.
可能存在故意不使用PKIX保护位字符串来保护消息的情况（即，省略此可选字段），因为将应用PKIX之外的其他保护。本规范明确允许这样的选择。此类外部保护的示例包括PKCS#7[PKCS7]和PKI消息的安全多部分[RFC1847]封装（或者简单地说，如果相关的PKI头信息在外部机制中安全地携带，则PKI主体（省略选择标记））；使用PKCS#7的外部保护规范将在单独的文件中提供。然而，需要注意的是，许多这样的外部机制要求最终实体已经拥有公钥证书和/或唯一的可分辨名称和/或其他这样的基础设施相关信息。因此，它们可能不适用于初始注册、密钥恢复或具有“引导”特性的任何其他过程。对于这些情况，可能需要使用PKI保护参数。将来，如果/当修改外部机制以适应引导方案时，PKI保护的使用可能会变得很少或不存在。
Depending on the circumstances the PKIProtection bits may contain a Message Authentication Code (MAC) or signature. Only the following cases can occur:
根据具体情况，PKI保护位可能包含消息认证码（MAC）或签名。只有以下情况才能发生：
- shared secret information
- 共享秘密信息
In this case the sender and recipient share secret information (established via out-of-band means or from a previous PKI management operation). PKIProtection will contain a MAC value and the protectionAlg will be the following:
在这种情况下，发送方和接收方共享秘密信息（通过带外方式或以前的PKI管理操作建立）。PKI保护将包含一个MAC值，并且protectionAlg将如下所示：
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
In the above protectionAlg the salt value is appended to the shared secret input. The OWF is then applied iterationCount times, where the salted secret is the input to the first iteration and, for each successive iteration, the input is set to be the output of the previous iteration. The output of the final iteration (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]
在上面的protectionag中，salt值被附加到共享秘密输入中。然后在迭代次数中应用OWF，其中salt secret是第一次迭代的输入，对于每个后续迭代，输入设置为前一次迭代的输出。最终迭代的输出（为便于参考，称为“BASEKEY”，大小为“H”）是用来形成对称密钥的。如果MAC算法需要K位密钥且K<=H，则使用BASEKEY的最高有效K位。如果K>H，则所有BASEKEY用于密钥的最高有效H位，OWF（“1”| | BASEKEY）用于密钥的下一个最高有效H位，OWF（“2”| | BASEKEY）用于密钥的下一个最高有效H位，依此类推，直到导出所有K位。[此处“N”是编码数字N的ASCII字节，“| |”表示串联。]
- DH key pairs
- DH密钥对
Where the sender and receiver possess Diffie-Hellman certificates with compatible DH parameters, then in order to protect the message the end entity must generate a symmetric key based on its private DH key value and the DH public key of the recipient of the PKI message. PKIProtection will contain a MAC value keyed with this derived symmetric key and the protectionAlg will be the following:
如果发送方和接收方拥有具有兼容DH参数的Diffie-Hellman证书，则为了保护消息，终端实体必须基于其私有DH密钥值和PKI消息接收方的DH公钥生成对称密钥。PKI保护将包含一个MAC值，该MAC值由该派生对称密钥加密，并且protectionAlg将如下所示：
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
In the above protectionAlg OWF is applied to the result of the Diffie-Hellman computation. The OWF output (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]
在上述保护中，将OWF应用于Diffie-Hellman计算的结果。OWF输出（为便于参考，称为“BASEKEY”，大小为“H”）是用来形成对称密钥的。如果MAC算法需要K位密钥且K<=H，则使用BASEKEY的最高有效K位。如果K>H，则所有BASEKEY用于密钥的最高有效H位，OWF（“1”| | BASEKEY）用于密钥的下一个最高有效H位，OWF（“2”| | BASEKEY）用于密钥的下一个最高有效H位，依此类推，直到导出所有K位。[此处“N”是编码数字N的ASCII字节，“| |”表示串联。]
- signature
- 签名
Where the sender possesses a signature key pair it may simply sign the PKI message. PKIProtection will contain the signature value and the protectionAlg will be an AlgorithmIdentifier for a digital signature (e.g., md5WithRSAEncryption or dsaWithSha-1).
如果发送方拥有签名密钥对，它可以简单地对PKI消息进行签名。PKI保护将包含签名值，protectionAlg将是数字签名的算法标识符（例如，MD5WithRSA加密或dsaWithSha-1）。
- multiple protection
- 多重保护
In cases where an end entity sends a protected PKI message to an RA, the RA MAY forward that message to a CA, attaching its own protection (which MAY be a MAC or a signature, depending on the information and certificates shared between the RA and the CA). This is accomplished by nesting the entire message sent by the end entity within a new PKI message. The structure used is as follows.
在终端实体向RA发送受保护的PKI消息的情况下，RA可以将该消息转发给CA，附加其自身的保护（可以是MAC或签名，取决于RA和CA之间共享的信息和证书）。这是通过将终端实体发送的整个消息嵌套在新的PKI消息中来实现的。使用的结构如下。
NestedMessageContent ::= PKIMessage
NestedMessageContent ::= PKIMessage
Before specifying the specific types that may be placed in a PKIBody we define some data structures that are used in more than one case.
在指定可能放置在PKI主体中的特定类型之前，我们定义了一些在多种情况下使用的数据结构。
Various PKI management messages require that the originator of the message indicate some of the fields that are required to be present in a certificate. The CertTemplate structure allows an end entity or RA to specify as much as it wishes about the certificate it requires. CertTemplate is identical to a Certificate but with all fields optional.
各种PKI管理消息要求消息的发起人指示证书中需要存在的某些字段。CertTemplate结构允许终端实体或RA根据自己的意愿指定所需的证书。CertTemplate与证书相同，但所有字段都是可选的。
Note that even if the originator completely specifies the contents of a certificate it requires, a CA is free to modify fields within the certificate actually issued. If the modified certificate is unacceptable to the requester, the Confirmation message may be withheld, or an Error Message may be sent (with a PKIStatus of "rejection").
请注意，即使发起人完全指定了它所需的证书的内容，CA也可以自由修改实际颁发的证书中的字段。如果修改后的证书对请求者不可接受，则可拒绝确认消息，或发送错误消息（PKI状态为“拒绝”）。
See [CRMF] for CertTemplate syntax.
有关CertTemplate语法，请参见[CRMF]。
Where encrypted values (restricted, in this specification, to be either private keys or certificates) are sent in PKI messages the EncryptedValue data structure is used.
如果在PKI消息中发送加密值（在本规范中限制为私钥或证书），则使用EncryptedValue数据结构。
See [CRMF] for EncryptedValue syntax.
有关EncryptedValue语法，请参见[CRMF]。
Use of this data structure requires that the creator and intended recipient respectively be able to encrypt and decrypt. Typically, this will mean that the sender and recipient have, or are able to generate, a shared secret key.
使用此数据结构要求创建者和预期接收者分别能够加密和解密。通常，这意味着发送方和接收方拥有或能够生成共享密钥。
If the recipient of the PKIMessage already possesses a private key usable for decryption, then the encSymmKey field MAY contain a session key encrypted using the recipient's public key.
如果PKI消息的接收者已经拥有可用于解密的私钥，则encSymmKey字段可能包含使用接收者的公钥加密的会话密钥。
All response messages will include some status information. The following values are defined.
所有响应消息都将包含一些状态信息。定义了以下值。
PKIStatus ::= INTEGER {
granted (0),
-- you got exactly what you asked for
grantedWithMods (1),
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
rejection (2),
-- you don't get it, more information elsewhere in the message
PKIStatus ::= INTEGER {
granted (0),
-- you got exactly what you asked for
grantedWithMods (1),
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
rejection (2),
-- you don't get it, more information elsewhere in the message
waiting (3),
-- the request body part has not yet been processed,
-- expect to hear more later
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- the key update request message
}
waiting (3),
-- the request body part has not yet been processed,
-- expect to hear more later
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- the key update request message
}
Responders may use the following syntax to provide more information about failure cases.
响应者可以使用以下语法提供有关故障案例的更多信息。
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (used for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (used for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
In order to identify particular certificates the CertId data structure is used.
为了识别特定证书，使用CertId数据结构。
See [CRMF] for CertId syntax.
有关CertId语法，请参见[CRMF]。
Each root CA must be able to publish its current public key via some "out-of-band" means. While such mechanisms are beyond the scope of this document, we define data structures which can support such mechanisms.
每个根CA必须能够通过一些“带外”方式发布其当前公钥。虽然这些机制超出了本文的范围，但我们定义了支持这些机制的数据结构。
There are generally two methods available: either the CA directly publishes its self-signed certificate; or this information is available via the Directory (or equivalent) and the CA publishes a hash of this value to allow verification of its integrity before use.
通常有两种方法可用：CA直接发布其自签名证书；或者，此信息可通过目录（或等效目录）获得，CA发布此值的哈希，以便在使用前验证其完整性。
OOBCert ::= Certificate
OOBCert ::= Certificate
The fields within this certificate are restricted as follows:
此证书中的字段限制如下：
- The certificate MUST be self-signed (i.e., the signature must be verifiable using the SubjectPublicKeyInfo field); - The subject and issuer fields MUST be identical; - If the subject field is NULL then both subjectAltNames and issuerAltNames extensions MUST be present and have exactly the same value; - The values of all other extensions must be suitable for a self-signed certificate (e.g., key identifiers for subject and issuer must be the same).
- 证书必须是自签名的（即，签名必须可以使用SubjectPublicKeyInfo字段进行验证）；-“主题”和“颁发者”字段必须相同；-如果subject字段为空，则SubjectAltName和issuerAltNames扩展名都必须存在并且具有完全相同的值；-所有其他扩展的值必须适用于自签名证书（例如，主体和颁发者的密钥标识符必须相同）。
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over the self-signed
-- certificate with the identifier certID.
}
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over the self-signed
-- certificate with the identifier certID.
}
The intention of the hash value is that anyone who has securely received the hash value (via the out-of-band means) can verify a self- signed certificate for that CA.
散列值的目的是任何安全地接收到散列值（通过带外方式）的人都可以验证该CA的自签名证书。
Requesters may indicate that they wish the PKI to archive a private key value using the PKIArchiveOptions structure
请求者可能表示他们希望PKI使用PKIArchiveOptions结构归档私钥值
See [CRMF] for PKIArchiveOptions syntax.
请参阅[CRMF]了解PKIArchiveOptions语法。
Requesters may indicate that they wish the PKI to publish a certificate using the PKIPublicationInfo structure.
请求者可能表示他们希望PKI使用PKIPublicationInfo结构发布证书。
See [CRMF] for PKIPublicationInfo syntax.
请参阅[CRMF]了解PKIProductionInfo语法。
If the certification request is for a signing key pair (i.e., a request for a verification certificate), then the proof of possession of the private signing key is demonstrated through use of the POPOSigningKey structure.
如果认证请求是针对签名密钥对的（即，对验证证书的请求），则通过使用POPOSigningKey结构来证明私有签名密钥的占有证明。
See [CRMF] for POPOSigningKey syntax, but note that POPOSigningKeyInput has the following semantic stipulations in this specification.
请参阅[CRMF]了解POPOSigningKey语法，但请注意，POPOSigningKeyInput在本规范中具有以下语义规定。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- from PKIHeader (used only if an authenticated identity
-- has been established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate))
publicKeyMAC [1] PKMACValue
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- (using the protectionAlg AlgId from PKIHeader) on the
-- DER-encoded value of publicKey
},
publicKey SubjectPublicKeyInfo -- from CertTemplate
}
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- from PKIHeader (used only if an authenticated identity
-- has been established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate))
publicKeyMAC [1] PKMACValue
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- (using the protectionAlg AlgId from PKIHeader) on the
-- DER-encoded value of publicKey
},
publicKey SubjectPublicKeyInfo -- from CertTemplate
}
On the other hand, if the certification request is for an encryption key pair (i.e., a request for an encryption certificate), then the proof of possession of the private decryption key may be demonstrated in one of three ways.
另一方面，如果认证请求是针对加密密钥对的（即，针对加密证书的请求），则可以通过三种方式之一来证明私有解密密钥的占有证明。
1) By the inclusion of the private key (encrypted) in the CertRequest (in the PKIArchiveOptions control structure).
1) 通过在CertRequest（PKIArchiveOptions控制结构）中包含私钥（加密）。
2) By having the CA return not the certificate, but an encrypted certificate (i.e., the certificate encrypted under a randomly-generated symmetric key, and the symmetric key encrypted under the public key for which the certification request is being made) -- this is the "indirect" method mentioned previously in Section 2.3.2. The end entity proves knowledge of the private decryption key to the CA by MACing the PKIConfirm message using a key derived from this symmetric key. [Note that if more than one CertReqMsg is included in the PKIMessage, then the CA uses a different symmetric key for each CertReqMsg and the MAC uses a key derived from the concatenation of all these keys.] The MACing procedure uses the PasswordBasedMac AlgId defined in Section 3.1.
2) 通过让CA返回的不是证书，而是加密的证书（即，根据随机生成的对称密钥加密的证书，以及根据公钥加密的对称密钥，对其进行认证请求）——这是前面第2.3.2节中提到的“间接”方法。终端实体通过使用从该对称密钥派生的密钥对PKIConfirm消息进行MACing来向CA证明私有解密密钥的知识。[请注意，如果PKI消息中包含多个CertReqMsg，则CA对每个CertReqMsg使用不同的对称密钥，MAC使用从所有这些密钥串联而来的密钥。]MAC过程使用第3.1节中定义的基于密码的DMAC AlgId。
3) By having the end entity engage in a challenge-response protocol (using the messages POPODecKeyChall and POPODecKeyResp; see below) between CertReqMessages and CertRepMessage -- this is the "direct" method mentioned previously in Section 2.3.2. [This method would typically be used in an environment in which an RA verifies POP and then makes a certification request to the CA on behalf of the end entity. In such a scenario, the CA trusts the RA to have done POP correctly before the RA requests a certificate for the end entity.] The complete protocol then looks as follows (note that req' does not necessarily encapsulate req as a nested message):
3) 通过让终端实体参与CertReqMessages和CertRepMessage之间的质询-响应协议（使用消息POPODecKeyChall和POPODecKeyResp；见下文），这是前面第2.3.2节提到的“直接”方法。[此方法通常用于RA验证POP，然后代表最终实体向CA发出认证请求的环境中。在这种情况下，CA相信RA在为最终实体请求证书之前已正确执行POP。]完整协议如下所示（请注意，req’不一定将req封装为嵌套消息）：
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- rep -----
---- conf --->
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- rep -----
---- conf --->
This protocol is obviously much longer than the 3-way exchange given in choice (2) above, but allows a local Registration Authority to be involved and has the property that the certificate itself is not actually created until the proof of possession is complete.
该协议显然比上述选择（2）中给出的三方交换长得多，但允许当地注册机构参与，并具有在完成占有证明之前证书本身不会实际创建的属性。
If the cert. request is for a key agreement key (KAK) pair, then the POP can use any of the 3 ways described above for enc. key pairs, with the following changes: (1) the parenthetical text of bullet 2) is replaced with "(i.e., the certificate encrypted under the symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)"; (2) the first
如果证书请求是针对密钥协议密钥（KAK）对的，则POP可以使用上述3种方式中的任何一种来处理加密密钥对，并进行以下更改：（1）项目符号2的插入文本替换为“（即，根据从CA的私有KAK派生的对称密钥加密的证书和正在进行认证请求的公钥）；（2）第一个
parenthetical text of the challenge field of "Challenge" below is replaced with "(using PreferredSymmAlg (see Appendix B6) and a symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)". Alternatively, the POP can use the POPOSigningKey structure given in [CRMF] (where the alg field is DHBasedMAC and the signature field is the MAC) as a fourth alternative for demonstrating POP if the CA already has a D-H certificate that is known to the EE.
下面“challenge”质询字段的括号文本替换为“（使用PreferredSymmAlg（见附录B6）和从CA的私有KAK派生的对称密钥以及为其发出认证请求的公钥）”。或者，如果CA已经具有EE已知的D-H证书，则POP可以使用[CRMF]中给出的POPOSigningKey结构（其中alg字段是DHBasedMAC，签名字段是MAC）作为证明POP的第四备选方案。
The challenge-response messages for proof of possession of a private decryption key are specified as follows (see [MvOV97, p.404] for details). Note that this challenge-response exchange is associated with the preceding cert. request message (and subsequent cert. response and confirmation messages) by the nonces used in the PKIHeader and by the protection (MACing or signing) applied to the PKIMessage.
用于证明拥有私有解密密钥的质询响应消息指定如下（有关详细信息，请参见[MvOV97，p.404]）。请注意，此质询-响应交换通过PKI标头中使用的nonce和应用于PKI消息的保护（标记或签名）与前面的证书请求消息（以及后续的证书响应和确认消息）相关联。
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- MUST be present in the first Challenge; MAY be omitted in any
-- subsequent Challenge in POPODecKeyChallContent (if omitted,
-- then the owf used in the immediately preceding Challenge is
-- to be used).
witness OCTET STRING,
-- the result of applying the one-way function (owf) to a
-- randomly-generated INTEGER, A. [Note that a different
-- INTEGER MUST be used for each Challenge.]
challenge OCTET STRING
-- the encryption (under the public key for which the cert.
-- request is being made) of Rand, where Rand is specified as
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - the randomly-generated INTEGER A (above)
-- sender GeneralName
-- - the sender's name (as included in PKIHeader)
-- }
}
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- MUST be present in the first Challenge; MAY be omitted in any
-- subsequent Challenge in POPODecKeyChallContent (if omitted,
-- then the owf used in the immediately preceding Challenge is
-- to be used).
witness OCTET STRING,
-- the result of applying the one-way function (owf) to a
-- randomly-generated INTEGER, A. [Note that a different
-- INTEGER MUST be used for each Challenge.]
challenge OCTET STRING
-- the encryption (under the public key for which the cert.
-- request is being made) of Rand, where Rand is specified as
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - the randomly-generated INTEGER A (above)
-- sender GeneralName
-- - the sender's name (as included in PKIHeader)
-- }
}
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.
An Initialization request message contains as the PKIBody an CertReqMessages data structure which specifies the requested certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields which may be supplied for each certificate requested (see Appendix B profiles for further information). This message is intended to be used for entities first initializing into the PKI.
初始化请求消息包含指定所请求证书的CertReqMessages数据结构作为PKI主体。通常，SubjectPublicKeyInfo、KeyId和Validity是可为请求的每个证书提供的模板字段（有关更多信息，请参阅附录B配置文件）。此消息用于首次初始化到PKI的实体。
See [CRMF] for CertReqMessages syntax.
有关CertReqMessages语法，请参阅[CRMF]。
An Initialization response message contains as the PKIBody an CertRepMessage data structure which has for each certificate requested a PKIStatusInfo field, a subject certificate, and possibly a private key (normally encrypted with a session key, which is itself encrypted with the protocolEncKey).
初始化响应消息包含一个CertRepMessage数据结构作为PKIBody，该结构为每个请求的证书提供一个PKIStatusInfo字段、一个主题证书，可能还有一个私钥（通常使用会话密钥加密，而会话密钥本身使用protocolEncKey加密）。
See Section 3.3.4 for CertRepMessage syntax. Note that if the PKI Message Protection is "shared secret information" (see Section 3.1.3), then any certificate transported in the caPubs field may be directly trusted as a root CA certificate by the initiator.
有关CertRepMessage语法，请参见第3.3.4节。请注意，如果PKI消息保护是“共享机密信息”（请参阅第3.1.3节），则在caPubs字段中传输的任何证书都可以被启动器直接信任为根CA证书。
A Registration/Certification request message contains as the PKIBody a CertReqMessages data structure which specifies the requested certificates. This message is intended to be used for existing PKI entities who wish to obtain additional certificates.
注册/认证请求消息包含指定所请求证书的CertReqMessages数据结构作为PKI主体。此消息旨在用于希望获得其他证书的现有PKI实体。
See [CRMF] for CertReqMessages syntax.
有关CertReqMessages语法，请参阅[CRMF]。
Alternatively, the PKIBody MAY be a CertificationRequest (this structure is fully specified by the ASN.1 structure CertificationRequest given in [PKCS10]). This structure may be required for certificate requests for signing key pairs when interoperation with legacy systems is desired, but its use is strongly discouraged whenever not absolutely necessary.
或者，PKI主体可以是CertificationRequest（此结构由[PKCS10]中给出的ASN.1结构CertificationRequest完全指定）。当需要与遗留系统进行互操作时，签名密钥对的证书请求可能需要此结构，但如果不是绝对必要，强烈建议不要使用此结构。
A registration response message contains as the PKIBody a CertRepMessage data structure which has a status value for each certificate requested, and optionally has a CA public key, failure information, a subject certificate, and an encrypted private key.
注册响应消息包含一个CertRepMessage数据结构作为PKI主体，该数据结构具有请求的每个证书的状态值，并且可选地具有CA公钥、故障信息、主题证书和加密私钥。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-asciiPairs OCTET STRING defined
-- for regInfo in CertReqMsg [CRMF]
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-asciiPairs OCTET STRING defined
-- for regInfo in CertReqMsg [CRMF]
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
Only one of the failInfo (in PKIStatusInfo) and certificate (in CertifiedKeyPair) fields can be present in each CertResponse (depending on the status). For some status values (e.g., waiting) neither of the optional fields will be present.
每个CertResponse中只能有一个failInfo（在PKI状态信息中）和CertifiedKeyPair（在CertifiedKeyPair中）字段（取决于状态）。对于某些状态值（例如等待），两个可选字段均不存在。
Given an EncryptedCert and the relevant decryption key the certificate may be obtained. The purpose of this is to allow a CA to return the value of a certificate, but with the constraint that only the intended recipient can obtain the actual certificate. The benefit of this approach is that a CA may reply with a certificate even in the absence of a proof that the requester is the end entity which can use the relevant private key (note that the proof is not obtained
提供加密证书和相关解密密钥，即可获得证书。这样做的目的是允许CA返回证书的值，但有一个限制，即只有预期的收件人才能获得实际的证书。这种方法的好处是，即使在没有证明请求者是可以使用相关私钥的最终实体的情况下，CA也可以使用证书进行回复（请注意，没有获得证明）
until the PKIConfirm message is received by the CA). Thus the CA will not have to revoke that certificate in the event that something goes wrong with the proof of possession.
直到CA收到PKI确认消息）。因此，如果占有证明出现问题，CA将不必撤销该证书。
For key update requests the CertReqMessages syntax is used. Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields which may be supplied for each key to be updated. This message is intended to be used to request updates to existing (non-revoked and non-expired) certificates.
对于密钥更新请求，使用CertReqMessages语法。通常，SubjectPublicKeyInfo、KeyId和Validity是模板字段，可以为每个要更新的密钥提供这些字段。此消息用于请求更新现有（未吊销和未过期）证书。
See [CRMF] for CertReqMessages syntax.
有关CertReqMessages语法，请参阅[CRMF]。
For key update responses the CertRepMessage syntax is used. The response is identical to the initialization response.
对于密钥更新响应，使用CertRepMessage语法。该响应与初始化响应相同。
See Section 3.3.4 for CertRepMessage syntax.
有关CertRepMessage语法，请参见第3.3.4节。
For key recovery requests the syntax used is identical to the initialization request CertReqMessages. Typically, SubjectPublicKeyInfo and KeyId are the template fields which may be used to supply a signature public key for which a certificate is required (see Appendix B profiles for further information).
对于密钥恢复请求，使用的语法与初始化请求CertReqMessages相同。通常，SubjectPublicKeyInfo和KeyId是模板字段，可用于提供需要证书的签名公钥（有关更多信息，请参阅附录B配置文件）。
See [CRMF] for CertReqMessages syntax. Note that if a key history is required, the requester must supply a Protocol Encryption Key control in the request message.
有关CertReqMessages语法，请参阅[CRMF]。请注意，如果需要密钥历史记录，请求者必须在请求消息中提供协议加密密钥控制。
For key recovery responses the following syntax is used. For some status values (e.g., waiting) none of the optional fields will be present.
对于密钥恢复响应，使用以下语法。对于某些状态值（例如等待），将不存在任何可选字段。
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
When requesting revocation of a certificate (or several certificates) the following data structure is used. The name of the requester is present in the PKIHeader structure.
当请求撤销一个证书（或多个证书）时，将使用以下数据结构。请求者的名称出现在PKI标头结构中。
RevReqContent ::= SEQUENCE OF RevDetails
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
revocationReason ReasonFlags OPTIONAL,
-- the reason that revocation is requested
badSinceDate GeneralizedTime OPTIONAL,
-- indicates best knowledge of sender
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
revocationReason ReasonFlags OPTIONAL,
-- the reason that revocation is requested
badSinceDate GeneralizedTime OPTIONAL,
-- indicates best knowledge of sender
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
The response to the above message. If produced, this is sent to the requester of the revocation. (A separate revocation announcement message MAY be sent to the subject of the certificate for which revocation was requested.)
对上述消息的响应。如果生成，则发送给撤销请求者。（可向请求撤销的证书主体发送单独的撤销公告消息。）
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- IDs for which revocation was requested (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- IDs for which revocation was requested (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
Cross certification requests use the same syntax (CertReqMessages) as for normal certification requests with the restriction that the key pair MUST have been generated by the requesting CA and the private key MUST NOT be sent to the responding CA.
交叉认证请求使用与普通认证请求相同的语法（CertReqMessages），但有一个限制，即密钥对必须由请求CA生成，并且私钥不得发送到响应CA。
See [CRMF] for CertReqMessages syntax.
有关CertReqMessages语法，请参阅[CRMF]。
Cross certification responses use the same syntax (CertRepMessage) as for normal certification responses with the restriction that no encrypted private key can be sent.
交叉认证响应使用与普通认证响应相同的语法（CertRepMessage），但限制不能发送加密的私钥。
See Section 3.3.4 for CertRepMessage syntax.
有关CertRepMessage语法，请参见第3.3.4节。
When a CA updates its own key pair the following data structure MAY be used to announce this event.
当CA更新其自己的密钥对时，可以使用以下数据结构来宣布此事件。
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
This structure MAY be used to announce the existence of certificates.
此结构可用于宣布证书的存在。
Note that this message is intended to be used for those cases (if any) where there is no pre-existing method for publication of certificates; it is not intended to be used where, for example, X.500 is the method for publication of certificates.
请注意，此消息旨在用于没有预先存在的证书发布方法的情况（如有）；例如，如果X.500是发布证书的方法，则不打算使用该方法。
CertAnnContent ::= Certificate
CertAnnContent ::= Certificate
When a CA has revoked, or is about to revoke, a particular certificate it MAY issue an announcement of this (possibly upcoming) event.
当CA已撤销或即将撤销特定证书时，它可能会发布此（可能即将发生的）事件的公告。
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- extra CRL details(e.g., crl number, reason, location, etc.)
}
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- extra CRL details(e.g., crl number, reason, location, etc.)
}
A CA MAY use such an announcement to warn (or notify) a subject that its certificate is about to be (or has been) revoked. This would typically be used where the request for revocation did not come from the subject concerned.
CA可以使用此类公告警告（或通知）主体其证书即将（或已）被吊销。这通常用于撤销请求并非来自相关主体的情况。
The willBeRevokedAt field contains the time at which a new entry will be added to the relevant CRLs.
willBeRevokedAt字段包含将新条目添加到相关CRL的时间。
When a CA issues a new CRL (or set of CRLs) the following data structure MAY be used to announce this event.
当CA发布新的CRL（或一组CRL）时，可以使用以下数据结构来宣布此事件。
CRLAnnContent ::= SEQUENCE OF CertificateList
CRLAnnContent ::= SEQUENCE OF CertificateList
This data structure is used in three-way protocols as the final PKIMessage. Its content is the same in all cases - actually there is no content since the PKIHeader carries all the required information.
此数据结构在三方协议中用作最终的PKI消息。它的内容在所有情况下都是相同的-实际上没有内容，因为PKI头包含所有必需的信息。
PKIConfirmContent ::= NULL
PKIConfirmContent ::= NULL
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages, or general-
-- purpose (e.g., announcement) messages for future needs or for
-- specific environments.
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages, or general-
-- purpose (e.g., announcement) messages for future needs or for
-- specific environments.
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
-- May be sent by EE, RA, or CA (depending on message content).
-- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically
-- be omitted for some of the examples given above. The receiver is
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
-- May be sent by EE, RA, or CA (depending on message content).
-- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically
-- be omitted for some of the examples given above. The receiver is
-- free to ignore any contained OBJ. IDs that it does not recognize.
-- If sent from EE to CA, the empty set indicates that the CA may send
-- any/all information that it wishes.
-- free to ignore any contained OBJ. IDs that it does not recognize.
-- If sent from EE to CA, the empty set indicates that the CA may send
-- any/all information that it wishes.
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- The receiver is free to ignore any contained OBJ. IDs that it does
-- not recognize.
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- The receiver is free to ignore any contained OBJ. IDs that it does
-- not recognize.
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
The PKI management functions outlined in Section 1 above are described in this section.
本节介绍了上文第1节概述的PKI管理功能。
This section deals with functions that are "mandatory" in the sense that all end entity and CA/RA implementations MUST be able to provide the functionality described (perhaps via one of the transport mechanisms defined in Section 5). This part is effectively the profile of the PKI management functionality that MUST be supported.
本节讨论“强制性”功能，即所有终端实体和CA/RA实现必须能够提供所述功能（可能通过第5节中定义的一种传输机制）。这一部分实际上是必须支持的PKI管理功能的概要。
Note that not all PKI management functions result in the creation of a PKI message.
请注意，并非所有PKI管理功能都会导致创建PKI消息。
[See Section 1.2.2 for this document's definition of "root CA".]
[本文件中“根CA”的定义见第1.2.2节。]
A newly created root CA must produce a "self-certificate" which is a Certificate structure with the profile defined for the "newWithNew" certificate issued following a root CA key update.
新创建的根CA必须生成一个“自证书”，它是一个证书结构，具有为根CA密钥更新后颁发的“newWithNew”证书定义的配置文件。
In order to make the CA's self certificate useful to end entities that do not acquire the self certificate via "out-of-band" means, the CA must also produce a fingerprint for its public key. End entities that acquire this fingerprint securely via some "out-of-band" means can then verify the CA's self-certificate and hence the other attributes contained therein.
为了使CA的自证书对未通过“带外”方式获取自证书的终端实体有用，CA还必须为其公钥生成指纹。通过一些“带外”方式安全获取该指纹的终端实体随后可以验证CA的自证书，从而验证其中包含的其他属性。
The data structure used to carry the fingerprint is the OOBCertHash.
用于携带指纹的数据结构是OOBCertHash。
CA keys (as all other keys) have a finite lifetime and will have to be updated on a periodic basis. The certificates NewWithNew, NewWithOld, and OldWithNew (see Section 2.4.1) are issued by the CA to aid existing end entities who hold the current self-signed CA certificate (OldWithOld) to transition securely to the new self-signed CA certificate (NewWithNew), and to aid new end entities who will hold NewWithNew to acquire OldWithOld securely for verification of existing data.
CA密钥（与所有其他密钥一样）具有有限的生存期，必须定期更新。CA颁发证书NewWithNew、NewWithOld和OldWithNew（见第2.4.1节），以帮助持有当前自签名CA证书（OldWithOld）的现有终端实体安全地过渡到新自签名CA证书（NewWithNew），并帮助持有NewWithNew的新终端实体安全地获取OldWithOld，以验证现有数据。
[See Section 1.2.2 for this document's definition of "subordinate CA".]
[参见第1.2.2节了解本文件对“下属CA”的定义。]
From the perspective of PKI management protocols the initialization of a subordinate CA is the same as the initialization of an end entity. The only difference is that the subordinate CA must also produce an initial revocation list.
从PKI管理协议的角度来看，从属CA的初始化与终端实体的初始化相同。唯一的区别是从属CA还必须生成初始吊销列表。
Before issuing any certificates a newly established CA (which issues CRLs) must produce "empty" versions of each CRL which is to be periodically produced.
在颁发任何证书之前，新建立的CA（颁发CRL）必须生成定期生成的每个CRL的“空”版本。
When a PKI entity (CA, RA, or EE) wishes to acquire information about the current status of a CA it MAY send that CA a request for such information.
当PKI实体（CA、RA或EE）希望获取有关CA当前状态的信息时，它可以向该CA发送获取此类信息的请求。
The CA must respond to the request by providing (at least) all of the information requested by the requester. If some of the information cannot be provided then an error must be conveyed to the requester.
CA必须通过提供（至少）请求者请求的所有信息来响应请求。如果无法提供某些信息，则必须向请求者传达错误。
If PKIMessages are used to request and supply this PKI information, then the request must be the GenMsg message, the response must be the GenRep message, and the error must be the Error message. These messages are protected using a MAC based on shared secret information (i.e., PasswordBasedMAC) or any other authenticated means (if the end entity has an existing certificate).
如果使用PKI消息请求和提供此PKI信息，则请求必须是GenMsg消息，响应必须是GenRep消息，错误必须是错误消息。这些消息使用基于共享秘密信息（即PasswordBasedMAC）的MAC或任何其他经过身份验证的方式（如果终端实体具有现有证书）进行保护。
The requester CA is the CA that will become the subject of the cross-certificate; the responder CA will become the issuer of the cross-certificate.
请求者CA是将成为交叉证书主体的CA；响应者CA将成为交叉证书的颁发者。
The requester CA must be "up and running" before initiating the cross-certification operation.
在启动交叉认证操作之前，请求者CA必须“启动并运行”。
4.6.1 One-way request-response scheme:
4.6.1 单向请求-响应方案：
The cross-certification scheme is essentially a one way operation; that is, when successful, this operation results in the creation of one new cross-certificate. If the requirement is that cross-certificates be created in "both directions" then each CA in turn must initiate a cross-certification operation (or use another scheme).
交叉认证计划本质上是一种单向操作；也就是说，如果成功，此操作将导致创建一个新的交叉证书。如果要求在“两个方向”上创建交叉证书，则每个CA必须依次启动交叉证书操作（或使用其他方案）。
This scheme is suitable where the two CAs in question can already verify each other's signatures (they have some common points of trust) or where there is an out-of-band verification of the origin of the certification request.
该方案适用于两个CA已经可以验证彼此的签名（它们有一些共同的信任点）或者存在对认证请求来源的带外验证的情况。
Detailed Description:
详细说明：
Cross certification is initiated at one CA known as the responder. The CA administrator for the responder identifies the CA it wants to cross certify and the responder CA equipment generates an authorization code. The responder CA administrator passes this authorization code by out-of-band means to the requester CA administrator. The requester CA administrator enters the authorization code at the requester CA in order to initiate the on-line exchange.
交叉认证在一个称为响应者的CA处启动。响应者的CA管理员识别其想要交叉认证的CA，响应者CA设备生成授权代码。响应者CA管理员通过带外方式将此授权代码传递给请求者CA管理员。请求者CA管理员在请求者CA处输入授权代码，以启动在线交换。
The authorization code is used for authentication and integrity purposes. This is done by generating a symmetric key based on the authorization code and using the symmetric key for generating Message Authentication Codes (MACs) on all messages exchanged.
授权代码用于身份验证和完整性目的。这是通过基于授权码生成对称密钥并使用对称密钥在所有交换的消息上生成消息身份验证码（MAC）来实现的。
The requester CA initiates the exchange by generating a random number (requester random number). The requester CA then sends to the responder CA the cross certification request (ccr) message. The fields in this message are protected from modification with a MAC based on the authorization code.
请求者CA通过生成一个随机数（请求者随机数）来启动交换。然后，请求者CA向响应者CA发送交叉认证请求（ccr）消息。此消息中的字段受保护，不受基于授权代码的MAC的修改。
Upon receipt of the ccr message, the responder CA checks the protocol version, saves the requester random number, generates its own random number (responder random number) and validates the MAC. It then
收到ccr消息后，响应者CA检查协议版本，保存请求者随机数，生成自己的随机数（响应者随机数），并验证MAC。那么
generates (and archives, if desired) a new requester certificate that contains the requester CA public key and is signed with the responder CA signature private key. The responder CA responds with the cross certification response (ccp) message. The fields in this message are protected from modification with a MAC based on the authorization code.
生成（并存档，如果需要）包含请求者CA公钥并使用响应者CA签名私钥签名的新请求者证书。响应者CA使用交叉认证响应（ccp）消息进行响应。此消息中的字段受保护，不受基于授权代码的MAC的修改。
Upon receipt of the ccp message, the requester CA checks that its own system time is close to the responder CA system time, checks the received random numbers and validates the MAC. The requester CA responds with the PKIConfirm message. The fields in this message are protected from modification with a MAC based on the authorization code. The requester CA writes the requester certificate to the Repository.
收到ccp消息后，请求者CA检查其自身的系统时间是否接近响应者CA系统时间，检查接收到的随机数并验证MAC。请求者CA使用PKIConfirm消息进行响应。此消息中的字段受保护，不受基于授权代码的MAC的修改。请求者CA将请求者证书写入存储库。
Upon receipt of the PKIConfirm message, the responder CA checks the random numbers and validates the MAC.
收到PKIConfirm消息后，响应者CA检查随机数并验证MAC。
Notes:
笔记：
1. The ccr message must contain a "complete" certification request, that is, all fields (including, e.g., a BasicConstraints extension) must be specified by the requester CA. 2. The ccp message SHOULD contain the verification certificate of the responder CA - if present, the requester CA must then verify this certificate (for example, via the "out-of-band" mechanism).
1. ccr消息必须包含“完整”的认证请求，即所有字段（包括，例如，基本约束扩展）必须由请求者CA.2指定。ccp消息应包含响应者CA的验证证书-如果存在，请求者CA必须验证该证书（例如，通过“带外”机制）。
As with CAs, end entities must be initialized. Initialization of end entities requires at least two steps:
与CAs一样，必须初始化终端实体。终端实体的初始化至少需要两个步骤：
- acquisition of PKI information - out-of-band verification of one root-CA public key
- 获取PKI信息-一个根CA公钥的带外验证
(other possible steps include the retrieval of trust condition information and/or out-of-band verification of other CA public keys).
（其他可能的步骤包括检索信任条件信息和/或其他CA公钥的带外验证）。
The information REQUIRED is:
所需资料如下：
- the current root-CA public key - (if the certifying CA is not a root-CA) the certification path from the root CA to the certifying CA together with appropriate revocation lists - the algorithms and algorithm parameters which the certifying CA supports for each relevant usage
- 当前根CA公钥-（如果认证CA不是根CA）从根CA到认证CA的认证路径以及适当的吊销列表-认证CA为每个相关用途支持的算法和算法参数
Additional information could be required (e.g., supported extensions or CA policy information) in order to produce a certification request which will be successful. However, for simplicity we do not mandate that the end entity acquires this information via the PKI messages. The end result is simply that some certification requests may fail (e.g., if the end entity wants to generate its own encryption key but the CA doesn't allow that).
可能需要额外的信息（例如，支持的扩展或CA策略信息），以生成将成功的认证请求。但是，为简单起见，我们不要求最终实体通过PKI消息获取此信息。最终的结果只是一些认证请求可能会失败（例如，如果最终实体想要生成自己的加密密钥，但CA不允许）。
The required information MAY be acquired as described in Section 4.5.
可按照第4.5节所述获取所需信息。
An end entity must securely possess the public key of its root CA. One method to achieve this is to provide the end entity with the CA's self-certificate fingerprint via some secure "out-of-band" means. The end entity can then securely use the CA's self-certificate.
终端实体必须安全地拥有其根CA的公钥。实现这一点的一种方法是通过一些安全的“带外”方式向终端实体提供CA的自证书指纹。然后，终端实体可以安全地使用CA的自证书。
See Section 4.1 for further details.
详见第4.1节。
An initialized end entity MAY request a certificate at any time (as part of an update procedure, or for any other purpose). This request will be made using the certification request (cr) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this cr message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a CertRepMessage.
初始化的最终实体可以随时请求证书（作为更新过程的一部分，或用于任何其他目的）。此请求将使用认证请求（cr）消息发出。如果终端实体已经拥有签名密钥对（具有相应的验证证书），则该cr消息通常将受到实体数字签名的保护。CA在CertRepMessage中返回新证书（如果请求成功）。
When a key pair is due to expire the relevant end entity MAY request a key update - that is, it MAY request that the CA issue a new certificate for a new key pair. The request is made using a key update request (kur) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a key update response (kup) message, which is syntactically identical to a CertRepMessage.
当密钥对到期时，相关终端实体可能会请求密钥更新，也就是说，它可能会请求CA为新密钥对颁发新证书。使用密钥更新请求（kur）消息发出请求。如果终端实体已经拥有签名密钥对（具有相应的验证证书），则该消息通常将受到实体数字签名的保护。CA在密钥更新响应（kup）消息中返回新证书（如果请求成功），该消息在语法上与CertRepMessage相同。
The transport protocols specified below allow end entities, RAs and CAs to pass PKI messages between them. There is no requirement for specific security mechanisms to be applied at this level if the PKI messages are suitably protected (that is, if the OPTIONAL PKIProtection parameter is used as specified for each message).
下面指定的传输协议允许终端实体、RAs和CA在它们之间传递PKI消息。如果PKI消息得到适当保护（即，如果为每条消息指定了可选的PKI保护参数），则不需要在此级别应用特定的安全机制。
A file containing a PKI message MUST contain only the DER encoding of one PKI message, i.e., there MUST be no extraneous header or trailer information in the file.
包含PKI消息的文件必须仅包含一个PKI消息的DER编码，即文件中不得有任何无关的头或尾信息。
Such files can be used to transport PKI messages using, e.g., FTP.
此类文件可用于使用FTP等传输PKI消息。
The following simple TCP-based protocol is to be used for transport of PKI messages. This protocol is suitable for cases where an end entity (or an RA) initiates a transaction and can poll to pick up the results.
以下简单的基于TCP的协议将用于PKI消息的传输。此协议适用于终端实体（或RA）启动事务并可以轮询以获取结果的情况。
If a transaction is initiated by a PKI entity (RA or CA) then an end entity must either supply a listener process or be supplied with a polling reference (see below) in order to allow it to pick up the PKI message from the PKI management component.
如果事务由PKI实体（RA或CA）发起，则终端实体必须提供侦听器进程或轮询引用（见下文），以便允许其从PKI管理组件拾取PKI消息。
The protocol basically assumes a listener process on an RA or CA which can accept PKI messages on a well-defined port (port number 829). Typically an initiator binds to this port and submits the initial PKI message for a given transaction ID. The responder replies with a PKI message and/or with a reference number to be used later when polling for the actual PKI message response.
该协议基本上假设RA或CA上有一个侦听器进程，可以在定义良好的端口（端口号829）上接受PKI消息。通常，发起者绑定到此端口并提交给定事务ID的初始PKI消息。响应者使用PKI消息和/或参考号进行响应，以便稍后轮询实际的PKI消息响应时使用。
If a number of PKI response messages are to be produced for a given request (say if some part of the request is handled more quickly than another) then a new polling reference is also returned.
如果要为给定的请求生成大量PKI响应消息（例如，如果请求的某些部分处理得比另一部分快），则还将返回一个新的轮询引用。
When the final PKI response message has been picked up by the initiator then no new polling reference is supplied.
当启动器拾取最终PKI响应消息时，不会提供新的轮询引用。
The initiator of a transaction sends a "direct TCP-based PKI message" to the recipient. The recipient responds with a similar message.
事务的发起人向收件人发送“基于TCP的直接PKI消息”。接收者也会回复类似的消息。
A "direct TCP-based PKI message" consists of:
“基于TCP的直接PKI消息”包括：
length (32-bits), flag (8-bits), value (defined below)
长度（32位）、标志（8位）、值（定义如下）
The length field contains the number of octets of the remainder of the message (i.e., number of octets of "value" plus one). All 32-bit values in this protocol are specified to be in network byte order.
“长度”字段包含消息其余部分的八位字节数（即“值”加一的八位字节数）。此协议中的所有32位值都指定为网络字节顺序。
Message name flag value
消息名称标志值
pkiMsg '00'H DER-encoded PKI message
PKIMG'00'H DER编码的PKI消息
-- PKI message
pollRep '01'H polling reference (32 bits),
time-to-check-back (32 bits)
-- poll response where no PKI message response ready; use polling
-- reference value (and estimated time value) for later polling
pollReq '02'H polling reference (32 bits)
-- request for a PKI message response to initial message
negPollRep '03'H '00'H
-- no further polling responses (i.e., transaction complete)
partialMsgRep '04'H next polling reference (32 bits),
time-to-check-back (32 bits),
DER-encoded PKI message
-- partial response to initial message plus new polling reference
-- (and estimated time value) to use to get next part of response
finalMsgRep '05'H DER-encoded PKI message
-- final (and possibly sole) response to initial message
errorMsgRep '06'H human readable error message
-- produced when an error is detected (e.g., a polling reference is
-- received which doesn't exist or is finished with)
-- PKI message
pollRep '01'H polling reference (32 bits),
time-to-check-back (32 bits)
-- poll response where no PKI message response ready; use polling
-- reference value (and estimated time value) for later polling
pollReq '02'H polling reference (32 bits)
-- request for a PKI message response to initial message
negPollRep '03'H '00'H
-- no further polling responses (i.e., transaction complete)
partialMsgRep '04'H next polling reference (32 bits),
time-to-check-back (32 bits),
DER-encoded PKI message
-- partial response to initial message plus new polling reference
-- (and estimated time value) to use to get next part of response
finalMsgRep '05'H DER-encoded PKI message
-- final (and possibly sole) response to initial message
errorMsgRep '06'H human readable error message
-- produced when an error is detected (e.g., a polling reference is
-- received which doesn't exist or is finished with)
Where a PKIConfirm message is to be transported (always from the initiator to the responder) then a pkiMsg message is sent and a negPollRep is returned.
如果要传输PKIConfirm消息（始终从发起方传输到响应方），则会发送pkiMsg消息并返回negPollRep。
The sequence of messages which can occur is then:
然后，可能出现的消息序列为：
a) end entity sends pkiMsg and receives one of pollRep, negPollRep, partialMsgRep or finalMsgRep in response. b) end entity sends pollReq message and receives one of negPollRep, partialMsgRep, finalMsgRep or errorMsgRep in response.
a) 终端实体发送pkiMsg并接收pollRep、negPollRep、partialMsgRep或finalMsgRep中的一个作为响应。b） 终端实体发送pollReq消息并接收negPollRep、partialMsgRep、finalMsgRep或errorMsgRep中的一个作为响应。
The "time-to-check-back" parameter is a 32-bit integer, defined to be the number of seconds which have elapsed since midnight, January 1, 1970, coordinated universal time. It provides an estimate of the time that the end entity should send its next pollReq.
“检查时间”参数是一个32位整数，定义为自协调世界时1970年1月1日午夜以来经过的秒数。它提供了终端实体应该发送下一个pollReq的时间估计。
This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 via Internet mail.
本小节规定了通过互联网邮件为第4节所述协议交换传输ASN.1编码消息的方法。
A simple MIME object is specified as follows.
下面指定了一个简单的MIME对象。
Content-Type: application/pkixcmp
Content-Transfer-Encoding: base64
Content-Type: application/pkixcmp
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded PKIX-CMP message, base64-encoded>>
<<the ASN.1 DER-encoded PKIX-CMP message, base64-encoded>>
This MIME object can be sent and received using common MIME processing engines and provides a simple Internet mail transport for PKIX-CMP messages. Implementations MAY wish to also recognize and use the "application/x-pkixcmp" MIME type (specified in earlier versions of this document) in order to support backward compatibility wherever applicable.
此MIME对象可以使用通用MIME处理引擎发送和接收，并为PKIX-CMP消息提供简单的Internet邮件传输。实现可能还希望识别并使用“application/x-pkixcmp”MIME类型（在本文档的早期版本中指定），以便在适用的情况下支持向后兼容性。
This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 via the HyperText Transfer Protocol.
本小节规定了通过超文本传输协议为第4节所述协议交换传输ASN.1编码消息的方法。
A simple MIME object is specified as follows.
下面指定了一个简单的MIME对象。
Content-Type: application/pkixcmp
Content-Type: application/pkixcmp
<<the ASN.1 DER-encoded PKIX-CMP message>>
<<the ASN.1 DER-encoded PKIX-CMP message>>
This MIME object can be sent and received using common HTTP processing engines over WWW links and provides a simple browser-server transport for PKIX-CMP messages. Implementations MAY wish to also recognize and use the "application/x-pkixcmp" MIME type (specified in earlier versions of this document) in order to support backward compatibility wherever applicable.
此MIME对象可以使用通用HTTP处理引擎通过WWW链接发送和接收，并为PKIX-CMP消息提供简单的浏览器服务器传输。实现可能还希望识别并使用“application/x-pkixcmp”MIME类型（在本文档的早期版本中指定），以便在适用的情况下支持向后兼容性。
SECURITY CONSIDERATIONS
安全考虑
This entire memo is about security mechanisms.
整个备忘录都是关于安全机制的。
One cryptographic consideration is worth explicitly spelling out. In the protocols specified above, when an end entity is required to prove possession of a decryption key, it is effectively challenged to decrypt something (its own certificate). This scheme (and many others!) could be vulnerable to an attack if the possessor of the decryption key in question could be fooled into decrypting an arbitrary challenge and returning the cleartext to an attacker. Although in this specification a number of other failures in security are required in order for this attack to succeed, it is conceivable that some future services (e.g., notary, trusted time) could potentially be vulnerable to such attacks. For this reason we re-iterate the general rule that implementations should be very careful about decrypting arbitrary "ciphertext" and revealing recovered "plaintext" since such a practice can lead to serious security vulnerabilities.
有一个密码学方面的考虑值得明确说明。在上面指定的协议中，当一个终端实体需要证明拥有一个解密密钥时，它被有效地挑战解密某个东西（它自己的证书）。如果有问题的解密密钥的拥有者可能被欺骗解密任意挑战并将明文返回给攻击者，则此方案（以及其他许多方案！）可能容易受到攻击。尽管在本规范中，为了使该攻击成功，还需要许多其他安全故障，但可以想象，某些未来服务（例如公证人、可信时间）可能会受到此类攻击的攻击。出于这个原因，我们重申了一般规则，即实现在解密任意“密文”和揭示恢复的“明文”时应非常小心，因为这种做法可能导致严重的安全漏洞。
Note also that exposing a private key to the CA/RA as a proof-of-possession technique can carry some security risks (depending upon whether or not the CA/RA can be trusted to handle such material appropriately). Implementers are advised to exercise caution in selecting and using this particular POP mechanism.
还请注意，将私钥公开给CA/RA作为占有证明技术可能会带来一些安全风险（取决于CA/RA是否可以被信任来适当处理此类材料）。建议实施者在选择和使用这个特定的POP机制时要谨慎。
References
工具书类
[COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC 9594-8: 1990 & 1993 (1995:E), July 1995.
[COR95]ISO/IEC JTC 1/SC 21，ISO/IEC 9594-8:1990和1993（1995:E）的技术勘误表2，1995年7月。
[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Certificate Request Message Format", RFC 2511, March 1999.
[CRMF]迈尔斯，M.，亚当斯，C.，索洛，D.和D.肯普，“证书请求消息格式”，RFC25111999年3月。
[MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997.
[MvOV97]A.Menezes，P.van Oorschot，S.Vanstone，“应用密码学手册”，CRC出版社，1997年。
[PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release.
[PKCS7]RSA实验室，“公钥加密标准（PKCS）”，RSA数据安全公司，加利福尼亚州红木市，1993年11月发布。
[PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release.
[PKCS10]RSA实验室，“公钥加密标准（PKCS）”，RSA数据安全公司，加利福尼亚州红木市，1993年11月发布。
[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - PKCS #11: Cryptographic token interface standard", RSA Data Security Inc., Redwood City, California, April 28, 1995.
[PKCS11]RSA实验室，“公钥加密标准-PKCS#11：加密令牌接口标准”，RSA数据安全公司，加利福尼亚州红木市，1995年4月28日。
[RFC1847] Galvin, J., Murphy, S. Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/ Encrypted", RFC 1847, October 1995.
[RFC1847]Galvin，J.，Murphy，S.Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, September 1997.
[RFC2202]Cheng，P.和R.Glenn，“HMAC-MD5和HMAC-SHA-1的测试案例”，RFC 2202，1997年9月。
[X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1 December, 1996.
[X509-AM]ISO/IEC JTC1/SC 21，关于证书延期的ISO/IEC 9594-2 DAM 4、ISO/IEC 9594-6 DAM 2、ISO/IEC 9594-7 DAM 1和ISO/IEC 9594-8 DAM 1修订草案，1996年12月1日。
Acknowledgements
致谢
The authors gratefully acknowledge the contributions of various members of the PKIX Working Group. Many of these contributions significantly clarified and improved the utility of this specification.
作者衷心感谢PKIX工作组各成员的贡献。这些贡献中的许多极大地澄清和改进了本规范的实用性。
Authors' Addresses
作者地址
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08, Ottawa, Ontario Canada K1V 1A7
加拿大安大略省渥太华Heron路750号E08室卡莱尔亚当斯信托科技公司K1V 1A7
EMail: cadams@entrust.com
EMail: cadams@entrust.com
Stephen Farrell Software and Systems Engineering Ltd. Fitzwilliam Court Leeson Close Dublin 2 IRELAND
Stephen Farrell软件和系统工程有限公司Fitzwilliam Court Leeson Close都柏林2号爱尔兰
EMail: stephen.farrell@sse.ie
EMail: stephen.farrell@sse.ie
APPENDIX A: Reasons for the presence of RAs
附录A：存在RAs的原因
The reasons which justify the presence of an RA can be split into those which are due to technical factors and those which are organizational in nature. Technical reasons include the following.
证明存在风险评估的原因可分为技术因素和组织因素。技术原因包括以下几点。
-If hardware tokens are in use, then not all end entities will have the equipment needed to initialize these; the RA equipment can include the necessary functionality (this may also be a matter of policy).
-如果正在使用硬件令牌，则并非所有终端实体都将拥有初始化这些令牌所需的设备；RA设备可包括必要的功能（这也可能是政策问题）。
-Some end entities may not have the capability to publish certificates; again, the RA may be suitably placed for this.
-某些终端实体可能没有发布证书的能力；同样，可以为此适当地放置RA。
-The RA will be able to issue signed revocation requests on behalf of end entities associated with it, whereas the end entity may not be able to do this (if the key pair is completely lost).
-RA将能够代表与其关联的终端实体发出签名撤销请求，而终端实体可能无法这样做（如果密钥对完全丢失）。
Some of the organizational reasons which argue for the presence of an RA are the following.
支持RA存在的一些组织原因如下。
-It may be more cost effective to concentrate functionality in the RA equipment than to supply functionality to all end entities (especially if special token initialization equipment is to be used).
-将功能集中在RA设备中可能比向所有终端实体提供功能更具成本效益（特别是在使用特殊令牌初始化设备的情况下）。
-Establishing RAs within an organization can reduce the number of CAs required, which is sometimes desirable.
-在组织内建立RAs可以减少所需的CA数量，这有时是可取的。
-RAs may be better placed to identify people with their "electronic" names, especially if the CA is physically remote from the end entity.
-RAs可能更适合于用其“电子”名称来识别人，尤其是当CA与最终实体的物理距离较远时。
-For many applications there will already be in place some administrative structure so that candidates for the role of RA are easy to find (which may not be true of the CA).
-对于许多应用程序，已经有了一些管理结构，以便很容易找到RA角色的候选人（CA可能不是这样）。
Appendix B. PKI Management Message Profiles.
附录B.PKI管理消息配置文件。
This appendix contains detailed profiles for those PKIMessages which MUST be supported by conforming implementations (see Section 4).
本附录包含必须由一致性实施支持的PKI消息的详细配置文件（见第4节）。
Profiles for the PKIMessages used in the following PKI management operations are provided:
提供了用于以下PKI管理操作的PKI消息的配置文件：
- root CA key update - information request/response - cross-certification request/response (1-way) - initial registration/certification - basic authenticated scheme - certificate request - key update
- 根CA密钥更新-信息请求/响应-交叉认证请求/响应（单向）-初始注册/认证-基本认证方案-证书请求-密钥更新
<<Later versions of this document may extend the above to include profiles for the operations listed below (along with other operations, if desired).>>
<<本文档的更高版本可能会扩展上述内容，以包括下面列出的操作的配置文件（以及其他操作，如果需要）。>>
- revocation request - certificate publication - CRL publication
- 吊销请求-证书发布-CRL发布
B1. General Rules for interpretation of these profiles.
B1。解释这些剖面的一般规则。
1. Where OPTIONAL or DEFAULT fields are not mentioned in individual profiles, they SHOULD be absent from the relevant message (i.e., a receiver can validly reject a message containing such fields as being syntactically incorrect). Mandatory fields are not mentioned if they have an obvious value (e.g., pvno). 2. Where structures occur in more than one message, they are separately profiled as appropriate. 3. The algorithmIdentifiers from PKIMessage structures are profiled separately. 4. A "special" X.500 DN is called the "NULL-DN"; this means a DN containing a zero-length SEQUENCE OF RelativeDistinguishedNames (its DER encoding is then '3000'H). 5. Where a GeneralName is required for a field but no suitable value is available (e.g., an end entity produces a request before knowing its name) then the GeneralName is to be an X.500 NULL-DN (i.e., the Name field of the CHOICE is to contain a NULL-DN). This special value can be called a "NULL-GeneralName". 6. Where a profile omits to specify the value for a GeneralName then the NULL-GeneralName value is to be present in the relevant PKIMessage field. This occurs with the sender field of the PKIHeader for some messages.
1. 如果个别概要文件中未提及可选或默认字段，则相关消息中应不包含这些字段（即，接收方可以有效地拒绝包含语法不正确字段的消息）。如果必填字段具有明显的值（例如，pvno），则不会提及它们。2.如果结构出现在多条消息中，则会根据需要单独分析它们。3.PKI消息结构中的算法标识符分别进行了分析。4.“特殊”X.500 DN称为“空DN”；这意味着一个DN包含一个长度为零的RelativeDistinguishedNames序列（其DER编码为'3000'H）。5.如果字段需要GeneralName，但没有合适的值可用（例如，终端实体在知道其名称之前生成请求），则GeneralName应为X.500 NULL-DN（即，选择的名称字段包含NULL-DN）。此特殊值可以称为“NULL GeneralName”。6.如果配置文件忽略指定GeneralName的值，则相关PKI消息字段中将出现空GeneralName值。某些消息的PKI标头的发件人字段会出现这种情况。
7. Where any ambiguity arises due to naming of fields, the profile names these using a "dot" notation (e.g., "certTemplate.subject" means the subject field within a field called certTemplate). 8. Where a "SEQUENCE OF types" is part of a message, a zero-based array notation is used to describe fields within the SEQUENCE OF (e.g., crm[0].certReq.certTemplate.subject refers to a subfield of the first CertReqMsg contained in a request message). 9. All PKI message exchanges in Sections B7-B10 require a PKIConfirm message to be sent by the initiating entity. This message is not included in some of the profiles given since its body is NULL and its header contents are clear from the context. Any authenticated means can be used for the protectionAlg (e.g., password-based MAC, if shared secret information is known, or signature).
7. 如果由于字段命名而产生任何歧义，配置文件将使用“点”符号命名这些字段（例如，“certTemplate.subject”表示名为certTemplate的字段中的主题字段）。8.如果“类型序列”是消息的一部分，则使用基于零的数组表示法来描述序列中的字段（例如，crm[0]。certReq.certTemplate.subject指请求消息中包含的第一个CertReqMsg的子字段）。9B7-B10节中的所有PKI消息交换都要求发起实体发送PKI确认消息。此消息不包含在某些给定的配置文件中，因为其正文为NULL，并且其标题内容从上下文中清除。任何经过身份验证的方法都可以用于protectionAlg（例如，如果共享秘密信息已知，则基于密码的MAC，或签名）。
B2. Algorithm Use Profile
B2。算法使用配置文件
The following table contains definitions of algorithm uses within PKI management protocols.
下表包含PKI管理协议中使用的算法定义。
The columns in the table are:
表中的列为：
Name: an identifier used for message profiles Use: description of where and for what the algorithm is used Mandatory: an AlgorithmIdentifier which MUST be supported by conforming implementations Others: alternatives to the mandatory AlgorithmIdentifier
名称：用于消息配置文件的标识符使用：算法使用位置和用途的说明强制性：必须由一致性实现支持的算法标识符其他：强制性算法标识符的替代方案
Name Use Mandatory Others
名称必须使用其他名称
MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5... messages using signature MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC, messages using MACing X9.9... SYM_PENC_ALG symmetric encryption of 3-DES (3-key- RC5, an end entity's private EDE, CBC mode) CAST-128... key where symmetric key is distributed out-of-band PROT_ENC_ALG asymmetric algorithm D-H RSA used for encryption of (symmetric keys for encryption of) private keys transported in PKIMessages PROT_SYM_ALG symmetric encryption 3-DES (3-key- RC5, algorithm used for EDE, CBC mode) CAST-128... encryption of private key bits (a key of this
MSG_SIG_ALG保护PKI DSA/SHA-1 RSA/MD5。。。消息使用签名MSG_MAC_ALG保护PKI PasswordBasedMac HMAC，消息使用MACing X9.9。。。对称加密3-DES（3-key-RC5，终端实体的私有EDE，CBC模式）CAST-128。。。密钥，其中对称密钥分布在带外保护加密ALG非对称算法D-H RSA用于加密PKI中传输的私钥消息保护加密ALG对称加密3-DES（3-key-RC5，用于EDE的算法，CBC模式）CAST-128。。。私钥位加密（此密钥的密钥）
type is encrypted using PROT_ENC_ALG)
类型使用PROT_ENC_ALG加密）
Mandatory AlgorithmIdentifiers and Specifications:
强制性算法标识符和规范：
DSA/SHA-1:
AlgId: {1 2 840 10040 4 3};
NIST, FIPS PUB 186: Digital Signature Standard, 1994;
Public Modulus size: 1024 bits.
DSA/SHA-1:
AlgId: {1 2 840 10040 4 3};
NIST, FIPS PUB 186: Digital Signature Standard, 1994;
Public Modulus size: 1024 bits.
PasswordBasedMac:
{1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the owf
parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter;
(this specification), along with
NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995;
H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message
Authentication", Internet Request for Comments 2104, February 1997.
PasswordBasedMac:
{1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the owf
parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter;
(this specification), along with
NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995;
H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message
Authentication", Internet Request for Comments 2104, February 1997.
3-DES: {1 2 840 113549 3 7}; (used in RSA's BSAFE and in S/MIME).
3-DES:{1 2 840 113549 3 7}；（在RSA的BSAFE和s/MIME中使用）。
D-H:
AlgId: {1 2 840 10046 2 1};
ANSI X9.42;
Public Modulus Size: 1024 bits.
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER -- g
}
D-H:
AlgId: {1 2 840 10046 2 1};
ANSI X9.42;
Public Modulus Size: 1024 bits.
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER -- g
}
B3. "Self-signed" certificates
B3。“自签名”证书
Profile of how a Certificate structure may be "self-signed". These structures are used for distribution of "root" CA public keys. This can occur in one of three ways (see Section 2.4 above for a description of the use of these structures):
证书结构如何“自签名”的配置文件。这些结构用于分发“根”CA公钥。这可以通过以下三种方式之一实现（有关这些结构的使用说明，请参见上文第2.4节）：
Type Function
类型函数
newWithNew a true "self-signed" certificate; the contained public key MUST be usable to verify the signature (though this provides only integrity and no authentication whatsoever) oldWithNew previous root CA public key signed with new private key newWithOld new root CA public key signed with previous private key
newWithNew具有真实的“自签名”证书；包含的公钥必须可用于验证签名（尽管这仅提供完整性，不提供任何身份验证）oldWithNew previous根CA公钥（使用新私钥签名）newWithOld新根CA公钥（使用旧私钥签名）
<<Such certificates (including relevant extensions) must contain "sensible" values for all fields. For example, when present subjectAltName MUST be identical to issuerAltName, and when present keyIdentifiers must contain appropriate values, et cetera.>>
<<此类证书（包括相关扩展名）必须包含所有字段的“合理”值。例如，when present subjectAltName必须与issueratName相同，when present keyIdentifiers必须包含适当的值，等等。>>
B4. Proof of Possession Profile
B4。管有证明文件
POP fields for use (in signature field of pop field of ProofOfPossession structure) when proving possession of a private signing key which corresponds to a public verification key for which a certificate has been requested.
证明拥有与已请求证书的公共验证密钥相对应的私人签名密钥时使用的POP字段（在认证结构的POP字段的签名字段中）。
Field Value Comment
字段值注释
algorithmIdentifier MSG_SIG_ALG only signature protection is allowed for this proof signature present bits calculated using MSG_SIG_ALG
算法标识符MSG_SIG_ALG仅允许对使用MSG_SIG_ALG计算的验证签名呈现位进行签名保护
<<Proof of possession of a private decryption key which corresponds to a public encryption key for which a certificate has been requested does not use this profile; instead the method given in protectionAlg for PKIConfirm in Section B8 is used.>>
<<拥有与已请求证书的公共加密密钥相对应的私有解密密钥的证明不使用此配置文件；而是使用第B8节中PKI确认的Protectional G中给出的方法。>>
Not every CA/RA will do Proof-of-Possession (of signing key, decryption key, or key agreement key) in the PKIX-CMP in-band certification request protocol (how POP is done MAY ultimately be a policy issue which is made explicit for any given CA in its publicized Policy OID and Certification Practice Statement). However, this specification MANDATES that CA/RA entities MUST do POP (by some means) as part of the certification process. All end entities MUST be prepared to provide POP (i.e., these components of the PKIX-CMP protocol MUST be supported).
并非每个CA/RA都会在PKIX-CMP带内认证请求协议中提供占有证明（签名密钥、解密密钥或密钥协议密钥）（POP的实现方式最终可能是一个政策问题，在其公开的政策OID和认证实践声明中明确了任何给定CA的政策问题）。但是，本规范要求CA/RA实体必须（通过某种方式）执行POP，作为认证过程的一部分。所有终端实体必须准备好提供POP（即，必须支持PKIX-CMP协议的这些组件）。
B5. Root CA Key Update
B5。根CA密钥更新
A root CA updates its key pair. It then produces a CA key update announcement message which can be made available (via one of the transport mechanisms) to the relevant end entities. A PKIConfirm message is NOT REQUIRED from the end entities.
根CA更新其密钥对。然后，它生成一条CA密钥更新公告消息，该消息可（通过一种传输机制）提供给相关的终端实体。不需要来自终端实体的PKI确认消息。
ckuann message:
ckuann消息：
Field Value Comment
字段值注释
sender CA name responding CA name body ckuann(CAKeyUpdAnnContent) oldWithNew present see Section B3 above
发送方CA名称响应CA名称正文ckuann（CAKeyUpdAnnContent）旧带新当前见上文B3节
newWithOld present see Section B3 above newWithNew present see Section B3 above extraCerts optionally present can be used to "publish" certificates (e.g., certificates signed using the new private key)
newWithOld present见上文B3节newWithNew present见上文B3节可选的Extercert可用于“发布”证书（例如，使用新私钥签名的证书）
B6. PKI Information request/response
B6。PKI信息请求/响应
The end entity sends general message to the PKI requesting details which will be required for later PKI management operations. RA/CA responds with general response. If an RA generates the response then it will simply forward the equivalent message which it previously received from the CA, with the possible addition of the certificates to the extraCerts fields of the PKIMessage. A PKIConfirm message is NOT REQUIRED from the end entity.
最终实体向PKI发送一般消息，请求后续PKI管理操作所需的详细信息。RA/CA以一般响应作出响应。如果RA生成响应，那么它将简单地转发它以前从CA接收到的等效消息，并可能将证书添加到PKI消息的ExterCerts字段中。不需要来自最终实体的PKI确认消息。
Message Flows:
消息流：
Step# End entity PKI
步骤#结束实体PKI
1 format genm 2 -> genm -> 3 handle genm 4 produce genp 5 <- genp <- 6 handle genp
1格式genm 2->genm->3句柄genm 4生成genp 5<-genp<-6句柄genp
genm:
genm：
Field Value
字段值
recipient CA name
-- the name of the CA as contained in issuerAltName extensions or
-- issuer fields within certificates
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
SenderKID present if required
-- must be present if required for verification of message protection
freeText any valid value
body genr (GenReqContent)
GenMsgContent empty SEQUENCE
-- all relevant information requested
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
recipient CA name
-- the name of the CA as contained in issuerAltName extensions or
-- issuer fields within certificates
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
SenderKID present if required
-- must be present if required for verification of message protection
freeText any valid value
body genr (GenReqContent)
GenMsgContent empty SEQUENCE
-- all relevant information requested
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
genp:
genp：
Field Value
字段值
sender CA name
-- name of the CA which produced the message
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
senderKID present if required
-- must be present if required for verification of message protection
body genp (GenRepContent)
CAProtEncCert present (object identifier one
of PROT_ENC_ALG), with relevant
value
-- to be used if end entity needs to encrypt information for the CA
-- (e.g., private key for recovery purposes)
SignKeyPairTypes present, with relevant value
-- the set of signature algorithm identifiers which this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption/key agreement algorithm identifiers which
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm which this CA expects to be used in later
-- PKI messages (for encryption)
CAKeyUpdateInfo optionally present, with
relevant value
-- the CA MAY provide information about a relevant root CA key pair
-- using this field (note that this does not imply that the responding
-- CA is the root CA in question)
CurrentCRL optionally present, with relevant value
-- the CA MAY provide a copy of a complete CRL (i.e., fullest possible
-- one)
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
extraCerts optionally present
-- can be used to send some certificates to the end entity. An RA MAY
-- add its certificate here.
sender CA name
-- name of the CA which produced the message
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
senderKID present if required
-- must be present if required for verification of message protection
body genp (GenRepContent)
CAProtEncCert present (object identifier one
of PROT_ENC_ALG), with relevant
value
-- to be used if end entity needs to encrypt information for the CA
-- (e.g., private key for recovery purposes)
SignKeyPairTypes present, with relevant value
-- the set of signature algorithm identifiers which this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption/key agreement algorithm identifiers which
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm which this CA expects to be used in later
-- PKI messages (for encryption)
CAKeyUpdateInfo optionally present, with
relevant value
-- the CA MAY provide information about a relevant root CA key pair
-- using this field (note that this does not imply that the responding
-- CA is the root CA in question)
CurrentCRL optionally present, with relevant value
-- the CA MAY provide a copy of a complete CRL (i.e., fullest possible
-- one)
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
extraCerts optionally present
-- can be used to send some certificates to the end entity. An RA MAY
-- add its certificate here.
B7. Cross certification request/response (1-way)
B7。交叉认证请求/响应（单向）
Creation of a single cross-certificate (i.e., not two at once). The requesting CA MAY choose who is responsible for publication of the cross-certificate created by the responding CA through use of the PKIPublicationInfo control.
创建单个交叉证书（即，不是同时创建两个）。请求CA可以选择谁负责通过使用PKIPublicationInfo控件发布由响应CA创建的交叉证书。
Preconditions:
先决条件：
1. Responding CA can verify the origin of the request (possibly requiring out-of-band means) before processing the request. 2. Requesting CA can authenticate the authenticity of the origin of the response (possibly requiring out-of-band means) before processing the response
1. 响应CA可以在处理请求之前验证请求的来源（可能需要带外方式）。2.请求CA可以在处理响应之前验证响应来源的真实性（可能需要带外方式）
Message Flows:
消息流：
Step# Requesting CA Responding CA 1 format ccr 2 -> ccr -> 3 handle ccr 4 produce ccp 5 <- ccp <- 6 handle ccp 7 format conf 8 -> conf -> 9 handle conf
步骤#请求CA响应CA 1格式ccr 2->ccr->3处理ccr 4生成ccp 5<-ccp<-6处理ccp 7格式配置8->配置->9处理配置
ccr: Field Value
ccr：字段值
sender Requesting CA name
-- the name of the CA who produced the message
recipient Responding CA name
-- the name of the CA who is being asked to produce a certificate
messageTime time of production of message
-- current time at requesting CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this request
senderKID present if required
-- must be present if required for verification of message protection
transactionID present
-- implementation-specific value, meaningful to requesting CA.
-- [If already in use at responding CA then a rejection message
-- MUST be produced by responding CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ccr (CertReqMessages)
only one CertReqMsg
allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
certTemplate present
sender Requesting CA name
-- the name of the CA who produced the message
recipient Responding CA name
-- the name of the CA who is being asked to produce a certificate
messageTime time of production of message
-- current time at requesting CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this request
senderKID present if required
-- must be present if required for verification of message protection
transactionID present
-- implementation-specific value, meaningful to requesting CA.
-- [If already in use at responding CA then a rejection message
-- MUST be produced by responding CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ccr (CertReqMessages)
only one CertReqMsg
allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
certTemplate present
-- details follow
version v1 or v3
-- <<v3 STRONGLY RECOMMENDED>>
signingAlg present
-- the requesting CA must know in advance with which algorithm it
-- wishes the certificate to be signed
subject present
-- may be NULL-DN only if subjectAltNames extension value proposed
validity present
-- MUST be completely specified (i.e., both fields present)
issuer present
-- may be NULL-DN only if issuerAltNames extension value proposed
publicKey present
-- the key to be certified (which must be for a signing algorithm)
extensions optionally present
-- a requesting CA must propose values for all extensions which it
-- requires to be in the cross-certificate
-- details follow
version v1 or v3
-- <<v3 STRONGLY RECOMMENDED>>
signingAlg present
-- the requesting CA must know in advance with which algorithm it
-- wishes the certificate to be signed
subject present
-- may be NULL-DN only if subjectAltNames extension value proposed
validity present
-- MUST be completely specified (i.e., both fields present)
issuer present
-- may be NULL-DN only if issuerAltNames extension value proposed
publicKey present
-- the key to be certified (which must be for a signing algorithm)
extensions optionally present
-- a requesting CA must propose values for all extensions which it
-- requires to be in the cross-certificate
POPOSigningKey present -- see "Proof of possession profile" (Section B4)
POPOSigningKey存在——参见“占有证明档案”（第B4节）
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
ccp: Field Value
ccp：字段值
sender Responding CA name
-- the name of the CA who produced the message
recipient Requesting CA name
-- the name of the CA who asked for production of a certificate
messageTime time of production of message
-- current time at responding CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this message
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
transactionID present
-- value from corresponding ccr message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
sender Responding CA name
-- the name of the CA who produced the message
recipient Requesting CA name
-- the name of the CA who asked for production of a certificate
messageTime time of production of message
-- current time at responding CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this message
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
transactionID present
-- value from corresponding ccr message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- senderNonce from corresponding ccr message
freeText any valid value
body ccp (CertRepMessage)
only one CertResponse allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
response present
status present
PKIStatusInfo.status present
-- if PKIStatusInfo.status is one of:
-- granted, or
-- grantedWithMods,
-- then certifiedKeyPair MUST be present and failInfo MUST be absent
failInfo present depending on
PKIStatusInfo.status
-- if PKIStatusInfo.status is:
-- rejection
-- then certifiedKeyPair MUST be absent and failInfo MUST be present
-- and contain appropriate bit settings
-- senderNonce from corresponding ccr message
freeText any valid value
body ccp (CertRepMessage)
only one CertResponse allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
response present
status present
PKIStatusInfo.status present
-- if PKIStatusInfo.status is one of:
-- granted, or
-- grantedWithMods,
-- then certifiedKeyPair MUST be present and failInfo MUST be absent
failInfo present depending on
PKIStatusInfo.status
-- if PKIStatusInfo.status is:
-- rejection
-- then certifiedKeyPair MUST be absent and failInfo MUST be present
-- and contain appropriate bit settings
certifiedKeyPair present depending on
PKIStatusInfo.status
certificate present depending on
certifiedKeyPair
-- content of actual certificate must be examined by requesting CA
-- before publication
certifiedKeyPair present depending on
PKIStatusInfo.status
certificate present depending on
certifiedKeyPair
-- content of actual certificate must be examined by requesting CA
-- before publication
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that responder wishes
-- to include
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that responder wishes
-- to include
B8. Initial Registration/Certification (Basic Authenticated Scheme)
B8。初始注册/认证（基本认证方案）
An (uninitialized) end entity requests a (first) certificate from a CA. When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
（未初始化的）终端实体从CA请求（第一个）证书。当CA用包含证书的消息进行响应时，终端实体用确认进行响应。所有消息都经过身份验证。
This scheme allows the end entity to request certification of a locally-generated public key (typically a signature key). The end entity MAY also choose to request the centralized generation and certification of another key pair (typically an encryption key pair).
该方案允许终端实体请求本地生成的公钥（通常是签名密钥）的认证。终端实体还可以选择请求集中生成和认证另一密钥对（通常是加密密钥对）。
Certification may only be requested for one locally generated public key (for more, use separate PKIMessages).
只能为一个本地生成的公钥请求认证（更多信息，请使用单独的PKI消息）。
The end entity MUST support proof-of-possession of the private key associated with the locally-generated public key.
终端实体必须支持拥有与本地生成的公钥相关联的私钥的证明。
Preconditions:
先决条件：
1. The end entity can authenticate the CA's signature based on out-of-band means 2. The end entity and the CA share a symmetric MACing key
1. 终端实体可以基于带外手段2认证CA的签名。终端实体和CA共享一个对称的MACing密钥
Message flow:
消息流：
Step# End entity PKI 1 format ir 2 -> ir -> 3 handle ir 4 format ip 5 <- ip <- 6 handle ip 7 format conf 8 -> conf -> 9 handle conf
步骤#结束实体PKI 1格式ir 2->ir->3处理ir 4格式ip 5<-ip<-6处理ip 7格式配置8->配置->9处理配置
For this profile, we mandate that the end entity MUST include all (i.e., one or two) CertReqMsg in a single PKIMessage and that the PKI (CA) MUST produce a single response PKIMessage which contains the complete response (i.e., including the OPTIONAL second key pair, if it was requested and if centralized key generation is supported). For simplicity, we also mandate that this message MUST be the final one (i.e., no use of "waiting" status value).
对于此配置文件，我们要求最终实体必须在单个PKI消息中包含所有（即一个或两个）CertReqMsg，并且PKI（CA）必须生成包含完整响应的单个响应PKI消息（即，如果请求并支持集中密钥生成，则包括可选的第二个密钥对）。为简单起见，我们还要求此消息必须是最终消息（即，不使用“等待”状态值）。
ir: Field Value
ir：字段值
recipient CA name
-- the name of the CA who is being asked to produce a certificate
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this request, based on
-- initial authentication key
senderKID referenceNum
-- the reference number which the CA has previously issued to
-- the end entity (together with the MACing key)
transactionID present
-- implementation-specific value, meaningful to end entity.
-- [If already in use at the CA then a rejection message MUST be
-- produced by the CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
recipient CA name
-- the name of the CA who is being asked to produce a certificate
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this request, based on
-- initial authentication key
senderKID referenceNum
-- the reference number which the CA has previously issued to
-- the end entity (together with the MACing key)
transactionID present
-- implementation-specific value, meaningful to end entity.
-- [If already in use at the CA then a rejection message MUST be
-- produced by the CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ir (CertReqMessages)
only one or two CertReqMsg
are allowed
-- if more certificates are required requests MUST be packaged in
-- separate PKIMessages
CertReqMsg one or two present
-- see below for details, note: crm[0] means the first (which MUST
-- be present), crm[1] means the second (which is OPTIONAL, and used
-- to ask for a centrally-generated key)
body ir (CertReqMessages)
only one or two CertReqMsg
are allowed
-- if more certificates are required requests MUST be packaged in
-- separate PKIMessages
CertReqMsg one or two present
-- see below for details, note: crm[0] means the first (which MUST
-- be present), crm[1] means the second (which is OPTIONAL, and used
-- to ask for a centrally-generated key)
crm[0].certReq. fixed value of zero
certReqId
-- this is the index of the template within the message
crm[0].certReq present
certTemplate
-- MUST include subject public key value, otherwise unconstrained
crm[0].pop... optionally present if public key
POPOSigningKey from crm[0].certReq.certTemplate is
a signing key
-- proof of possession MAY be required in this exchange (see Section
-- B4 for details)
crm[0].certReq. optionally present
controls.archiveOptions
-- the end entity MAY request that the locally-generated private key
-- be archived
crm[0].certReq. optionally present
controls.publicationInfo
-- the end entity MAY ask for publication of resulting cert.
crm[0].certReq. fixed value of zero
certReqId
-- this is the index of the template within the message
crm[0].certReq present
certTemplate
-- MUST include subject public key value, otherwise unconstrained
crm[0].pop... optionally present if public key
POPOSigningKey from crm[0].certReq.certTemplate is
a signing key
-- proof of possession MAY be required in this exchange (see Section
-- B4 for details)
crm[0].certReq. optionally present
controls.archiveOptions
-- the end entity MAY request that the locally-generated private key
-- be archived
crm[0].certReq. optionally present
controls.publicationInfo
-- the end entity MAY ask for publication of resulting cert.
crm[1].certReq fixed value of one
certReqId
-- the index of the template within the message
crm[1].certReq present
certTemplate
-- MUST NOT include actual public key bits, otherwise unconstrained
-- (e.g., the names need not be the same as in crm[0])
crm[0].certReq. present [object identifier MUST be PROT_ENC_ALG]
controls.protocolEncKey
-- if centralized key generation is supported by this CA, this
-- short-term asymmetric encryption key (generated by the end entity)
-- will be used by the CA to encrypt (a symmetric key used to encrypt)
-- a private key generated by the CA on behalf of the end entity
crm[1].certReq. optionally present
controls.archiveOptions
crm[1].certReq. optionally present
controls.publicationInfo
protection present
-- bits calculated using MSG_MAC_ALG
crm[1].certReq fixed value of one
certReqId
-- the index of the template within the message
crm[1].certReq present
certTemplate
-- MUST NOT include actual public key bits, otherwise unconstrained
-- (e.g., the names need not be the same as in crm[0])
crm[0].certReq. present [object identifier MUST be PROT_ENC_ALG]
controls.protocolEncKey
-- if centralized key generation is supported by this CA, this
-- short-term asymmetric encryption key (generated by the end entity)
-- will be used by the CA to encrypt (a symmetric key used to encrypt)
-- a private key generated by the CA on behalf of the end entity
crm[1].certReq. optionally present
controls.archiveOptions
crm[1].certReq. optionally present
controls.publicationInfo
protection present
-- bits calculated using MSG_MAC_ALG
ip: Field Value
ip：字段值
sender CA name
-- the name of the CA who produced the message
messageTime present
-- time at which CA produced message
protectionAlg MS_MAC_ALG
-- only MAC protection is allowed for this response
recipKID referenceNum
-- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key)
transactionID present
-- value from corresponding ir message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce in corresponding ir message
freeText any valid value
body ir (CertRepMessage)
contains exactly one response
for each request
-- The PKI (CA) responds to either one or two requests as appropriate.
-- crc[0] denotes the first (always present); crc[1] denotes the
-- second (only present if the ir message contained two requests and
-- if the CA supports centralized key generation).
crc[0]. fixed value of zero
certReqId
-- MUST contain the response to the first request in the corresponding
-- ir message
crc[0].status. present, positive values allowed:
status "granted", "grantedWithMods"
negative values allowed:
"rejection"
crc[0].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is
"granted" or "grantedWithMods"
certificate present unless end entity's public
key is an encryption key and POP
is done in this in-band exchange
encryptedCert present if and only if end entity's
public key is an encryption key and
POP done in this in-band exchange
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
sender CA name
-- the name of the CA who produced the message
messageTime present
-- time at which CA produced message
protectionAlg MS_MAC_ALG
-- only MAC protection is allowed for this response
recipKID referenceNum
-- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key)
transactionID present
-- value from corresponding ir message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce in corresponding ir message
freeText any valid value
body ir (CertRepMessage)
contains exactly one response
for each request
-- The PKI (CA) responds to either one or two requests as appropriate.
-- crc[0] denotes the first (always present); crc[1] denotes the
-- second (only present if the ir message contained two requests and
-- if the CA supports centralized key generation).
crc[0]. fixed value of zero
certReqId
-- MUST contain the response to the first request in the corresponding
-- ir message
crc[0].status. present, positive values allowed:
status "granted", "grantedWithMods"
negative values allowed:
"rejection"
crc[0].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is
"granted" or "grantedWithMods"
certificate present unless end entity's public
key is an encryption key and POP
is done in this in-band exchange
encryptedCert present if and only if end entity's
public key is an encryption key and
POP done in this in-band exchange
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
crc[1]. fixed value of one
certReqId
-- MUST contain the response to the second request in the
-- corresponding ir message
crc[1].status. present, positive values allowed:
status "granted", "grantedWithMods"
negative values allowed:
"rejection"
crc[1].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[1]. present if and only if
certifiedKeyPair crc[0].status.status is "granted"
or "grantedWithMods"
certificate present
privateKey present
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
protection present
-- bits calculated using MSG_MAC_ALG
extraCerts optionally present
-- the CA MAY provide additional certificates to the end entity
crc[1]. fixed value of one
certReqId
-- MUST contain the response to the second request in the
-- corresponding ir message
crc[1].status. present, positive values allowed:
status "granted", "grantedWithMods"
negative values allowed:
"rejection"
crc[1].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[1]. present if and only if
certifiedKeyPair crc[0].status.status is "granted"
or "grantedWithMods"
certificate present
privateKey present
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
protection present
-- bits calculated using MSG_MAC_ALG
extraCerts optionally present
-- the CA MAY provide additional certificates to the end entity
conf: Field Value
conf：字段值
recipient CA name
-- the name of the CA who was asked to produce a certificate
transactionID present
-- value from corresponding ir and ip messages
senderNonce present
-- value from recipNonce in corresponding ip message
recipNonce present
-- value from senderNonce in corresponding ip message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message. The MAC is
-- based on the initial authentication key if only a signing key
-- pair has been sent in ir for certification, or if POP is not
-- done in this in-band exchange. Otherwise, the MAC is based on
-- a key derived from the symmetric key used to decrypt the
-- returned encryptedCert.
senderKID referenceNum
-- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key)
body conf (PKIConfirmContent)
-- this is an ASN.1 NULL
protection present
-- bits calculated using MSG_MAC_ALG
recipient CA name
-- the name of the CA who was asked to produce a certificate
transactionID present
-- value from corresponding ir and ip messages
senderNonce present
-- value from recipNonce in corresponding ip message
recipNonce present
-- value from senderNonce in corresponding ip message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message. The MAC is
-- based on the initial authentication key if only a signing key
-- pair has been sent in ir for certification, or if POP is not
-- done in this in-band exchange. Otherwise, the MAC is based on
-- a key derived from the symmetric key used to decrypt the
-- returned encryptedCert.
senderKID referenceNum
-- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key)
body conf (PKIConfirmContent)
-- this is an ASN.1 NULL
protection present
-- bits calculated using MSG_MAC_ALG
B9. Certificate Request
B9。证书申请
An (initialized) end entity requests a certificate from a CA (for any reason). When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
An (initialized) end entity requests a certificate from a CA (for any reason). When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.translate error, please retry
The profile for this exchange is identical to that given in Section B8 with the following exceptions:
此交换的配置文件与第B8节中给出的配置文件相同，但以下情况除外：
- protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request, response, and confirm messages (the determination in the confirm message being dependent upon POP considerations for key-encipherment and key- agreement certificate requests); - senderKID and recipKID are only present if required for message verification; - body is cr or cp; - protocolEncKey is not present; - protection bits are calculated according to the protectionAlg field.
- protectionAlg在请求、响应和确认消息中可以是MSG_MAC_ALG或MSG_SIG_ALG（确认消息中的确定取决于密钥加密和密钥协议证书请求的POP考虑）；-senderKID和recipKID仅在需要验证消息时出现；-主体为cr或cp；-protocolEncKey不存在；-根据protectionAlg字段计算保护位。
B10. Key Update Request
B10。密钥更新请求
An (initialized) end entity requests a certificate from a CA (to update the key pair and corresponding certificate that it already possesses). When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
（初始化的）终端实体从CA请求证书（以更新密钥对和它已经拥有的相应证书）。当CA以包含证书的消息进行响应时，最终实体以确认进行响应。所有消息都经过身份验证。
The profile for this exchange is identical to that given in Section B8 with the following exceptions:
此交换的配置文件与第B8节中给出的配置文件相同，但以下情况除外：
- protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request, response, and confirm messages (the determination in the confirm message being dependent upon POP considerations for key-encipherment and key- agreement certificate requests); - senderKID and recipKID are only present if required for message verification; - body is kur or kup; - protection bits are calculated according to the protectionAlg field.
- protectionAlg在请求、响应和确认消息中可以是MSG_MAC_ALG或MSG_SIG_ALG（确认消息中的确定取决于密钥加密和密钥协议证书请求的POP考虑）；-senderKID和recipKID仅在需要验证消息时出现；-身体是kur或kup；-根据protectionAlg字段计算保护位。
Appendix C: "Compilable" ASN.1 Module using 1988 Syntax
附录C：使用1988语法的“可编译”ASN.1模块
PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)}
PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)}
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
Certificate, CertificateList, Extensions, AlgorithmIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}}
Certificate, CertificateList, Extensions, AlgorithmIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}}
GeneralName, KeyIdentifier, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
GeneralName, KeyIdentifier, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId,
CertReqMessages
FROM PKIXCRMF {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-crmf(5)}}
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId,
CertReqMessages
FROM PKIXCRMF {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-crmf(5)}}
-- CertificationRequest
-- FROM PKCS10 {no standard ASN.1 module defined;
-- implementers need to create their own module to import
-- from, or directly include the PKCS10 syntax in this module}
-- CertificationRequest
-- FROM PKCS10 {no standard ASN.1 module defined;
-- implementers need to create their own module to import
-- from, or directly include the PKCS10 syntax in this module}
-- Locally defined OIDs --
--局部定义的OID--
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable"; i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response and confirmation messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field not primarily intended for human consumption)
}
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable"; i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response and confirmation messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field not primarily intended for human consumption)
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String (note: each UTF8String SHOULD
-- include an RFC 1766 language tag to indicate the language
-- of the contained text)
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String (note: each UTF8String SHOULD
-- include an RFC 1766 language tag to indicate the language
-- of the contained text)
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --Initialization Request
ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --imported from [PKCS10]
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Request
krp [10] KeyRecRepContent, --Key Recovery Response
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --Initialization Request
ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --imported from [PKCS10]
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Request
krp [10] KeyRecRepContent, --Key Recovery Response
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request ccp [14] CertRepMessage, --Cross-Cert. Response ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. cann [16] CertAnnContent, --Certificate Ann. rann [17] RevAnnContent, --Revocation Ann. crlann [18] CRLAnnContent, --CRL Announcement conf [19] PKIConfirmContent, --Confirmation nested [20] NestedMessageContent, --Nested Message genm [21] GenMsgContent, --General Message genp [22] GenRepContent, --General Response error [23] ErrorMsgContent --Error Message }
ccr[13]CertReqMessages，--Cross-Cert.Request ccp[14]CertRepMessage，--Cross-Cert.Response ckuann[15]CAKeyUpdAnnContent，--CA密钥更新Ann。cann[16]CertAnnContent，--证书Ann。rann[17]RevAnnContent，--Ann。crlann[18]CRLAnnContent，--CRL公告配置[19]PKIConfirmContent，--确认嵌套[20]嵌套消息内容，--嵌套消息genm[21]GenMsgContent，--一般消息genp[22]GenRepContent，--一般响应错误[23]ErrorMsgContent--错误消息}
PKIProtection ::= BIT STRING
PKIProtection ::= BIT STRING
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
NestedMessageContent ::= PKIMessage
NestedMessageContent ::= PKIMessage
PKIStatus ::= INTEGER {
granted (0),
-- you got exactly what you asked for
grantedWithMods (1),
PKIStatus ::= INTEGER {
granted (0),
-- you got exactly what you asked for
grantedWithMods (1),
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
rejection (2),
-- you don't get it, more information elsewhere in the message
waiting (3),
-- the request body part has not yet been processed,
-- expect to hear more later
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- CertReqMsg
}
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
rejection (2),
-- you don't get it, more information elsewhere in the message
waiting (3),
-- the request body part has not yet been processed,
-- expect to hear more later
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- CertReqMsg
}
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
}
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
}
OOBCert ::= Certificate
OOBCert ::= Certificate
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over DER encoding of the
-- subjectPublicKey field of the corresponding cert.
}
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over DER encoding of the
-- subjectPublicKey field of the corresponding cert.
}
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- MUST be present in the first Challenge; MAY be omitted in any
-- subsequent Challenge in POPODecKeyChallContent (if omitted,
-- then the owf used in the immediately preceding Challenge is
-- to be used).
witness OCTET STRING,
-- the result of applying the one-way function (owf) to a
-- randomly-generated INTEGER, A. [Note that a different
-- INTEGER MUST be used for each Challenge.]
challenge OCTET STRING
-- the encryption (under the public key for which the cert.
-- request is being made) of Rand, where Rand is specified as
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - the randomly-generated INTEGER A (above)
-- sender GeneralName
-- - the sender's name (as included in PKIHeader)
-- }
}
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- MUST be present in the first Challenge; MAY be omitted in any
-- subsequent Challenge in POPODecKeyChallContent (if omitted,
-- then the owf used in the immediately preceding Challenge is
-- to be used).
witness OCTET STRING,
-- the result of applying the one-way function (owf) to a
-- randomly-generated INTEGER, A. [Note that a different
-- INTEGER MUST be used for each Challenge.]
challenge OCTET STRING
-- the encryption (under the public key for which the cert.
-- request is being made) of Rand, where Rand is specified as
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - the randomly-generated INTEGER A (above)
-- sender GeneralName
-- - the sender's name (as included in PKIHeader)
-- }
}
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-asciiPairs OCTET STRING defined
-- for regInfo in CertReqMsg [CRMF]
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-asciiPairs OCTET STRING defined
-- for regInfo in CertReqMsg [CRMF]
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
RevReqContent ::= SEQUENCE OF RevDetails
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
revocationReason ReasonFlags OPTIONAL,
-- the reason that revocation is requested
badSinceDate GeneralizedTime OPTIONAL,
-- indicates best knowledge of sender
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
revocationReason ReasonFlags OPTIONAL,
-- the reason that revocation is requested
badSinceDate GeneralizedTime OPTIONAL,
-- indicates best knowledge of sender
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
RevRepContent ::= SEQUENCE {
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- IDs for which revocation was requested (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- IDs for which revocation was requested (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
CertAnnContent ::= Certificate
CertAnnContent ::= Certificate
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- extra CRL details(e.g., crl number, reason, location, etc.)
}
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- extra CRL details(e.g., crl number, reason, location, etc.)
}
CRLAnnContent ::= SEQUENCE OF CertificateList
CRLAnnContent ::= SEQUENCE OF CertificateList
PKIConfirmContent ::= NULL
PKIConfirmContent ::= NULL
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages, or general-
-- purpose (e.g., announcement) messages for future needs or for
-- specific environments.
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages, or general-
-- purpose (e.g., announcement) messages for future needs or for
-- specific environments.
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
-- May be sent by EE, RA, or CA (depending on message content).
-- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically
-- be omitted for some of the examples given above. The receiver is
-- free to ignore any contained OBJ. IDs that it does not recognize.
-- If sent from EE to CA, the empty set indicates that the CA may send
-- any/all information that it wishes.
-- May be sent by EE, RA, or CA (depending on message content).
-- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically
-- be omitted for some of the examples given above. The receiver is
-- free to ignore any contained OBJ. IDs that it does not recognize.
-- If sent from EE to CA, the empty set indicates that the CA may send
-- any/all information that it wishes.
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- The receiver is free to ignore any contained OBJ. IDs that it does
-- not recognize.
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- The receiver is free to ignore any contained OBJ. IDs that it does
-- not recognize.
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
-- The following definition is provided for compatibility reasons with
-- 1988 and 1993 ASN.1 compilers which allow the use of UNIVERSAL class
-- tags (not a part of formal ASN.1); 1997 and subsequent compilers
-- SHOULD comment out this line.
-- The following definition is provided for compatibility reasons with
-- 1988 and 1993 ASN.1 compilers which allow the use of UNIVERSAL class
-- tags (not a part of formal ASN.1); 1997 and subsequent compilers
-- SHOULD comment out this line.
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
END
终止
Appendix D: Registration of MIME Type for Section 5
附录D：第5节MIME类型的注册
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkixcmp
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkixcmp
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: pkixcmp
MIME子类型名称：pkixcmp
Required parameters: -
所需参数：-
Optional parameters: -
可选参数：-
Encoding considerations: Content may contain arbitrary octet values (the ASN.1 DER encoding of a PKI message, as defined in the IETF PKIX Working Group specifications). base64 encoding is required for MIME e-mail; no encoding is necessary for HTTP.
编码注意事项：内容可能包含任意八位字节值（如IETF PKIX工作组规范中定义的，PKI消息的ASN.1 DER编码）。MIME电子邮件需要base64编码；HTTP不需要编码。
Security considerations: This MIME type may be used to transport Public-Key Infrastructure (PKI) messages between PKI entities. These messages are defined by the IETF PKIX Working Group and are used to establish and maintain an Internet X.509 PKI. There is no requirement for specific security mechanisms to be applied at this level if the PKI messages themselves are protected as defined in the PKIX specifications.
安全注意事项：此MIME类型可用于在PKI实体之间传输公钥基础设施（PKI）消息。这些消息由IETF PKIX工作组定义，用于建立和维护Internet X.509 PKI。如果PKI消息本身按照PKIX规范中的定义受到保护，则不需要在此级别应用特定的安全机制。
Interoperability considerations: -
互操作性注意事项：-
Published specification: this document
已发布规范：本文件
Applications which use this media type: Applications using certificate management, operational, or ancillary protocols (as defined by the IETF PKIX Working Group) to send PKI messages via E-Mail or HTTP.
使用此媒体类型的应用程序：使用证书管理、操作或辅助协议（由IETF PKIX工作组定义）通过电子邮件或HTTP发送PKI消息的应用程序。
Additional information:
其他信息：
Magic number (s): -
File extension (s): ".PKI"
Macintosh File Type Code (s): -
Magic number (s): -
File extension (s): ".PKI"
Macintosh File Type Code (s): -
Person and email address to contact for further information: Carlisle Adams, cadams@entrust.com
联系人和电子邮件地址，以获取更多信息：Carlisle Adams，cadams@entrust.com
Intended usage: COMMON
预期用途：普通
Author/Change controller: Carlisle Adams
作者/变更控制员：卡莱尔·亚当斯
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。