Network Working Group C. Adams
Request for Comments: 4210 University of Ottawa
Obsoletes: 2510 S. Farrell
Category: Standards Track Trinity College Dublin
T. Kause
SSH
T. Mononen
SafeNet
September 2005
Network Working Group C. Adams
Request for Comments: 4210 University of Ottawa
Obsoletes: 2510 S. Farrell
Category: Standards Track Trinity College Dublin
T. Kause
SSH
T. Mononen
SafeNet
September 2005
Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
Internet X.509公钥基础设施证书管理协议（CMP）
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system.
本文档介绍Internet X.509公钥基础设施（PKI）证书管理协议（CMP）。为X.509v3证书的创建和管理定义了协议消息。CMP提供PKI组件之间的在线交互，包括证书颁发机构（CA）和客户端系统之间的交换。
Table of Contents
目录
1. Introduction ....................................................5
2. Requirements ....................................................5
3. PKI Management Overview .........................................5
3.1. PKI Management Model .......................................6
3.1.1. Definitions of PKI Entities .........................6
3.1.1.1. Subjects and End Entities ..................6
3.1.1.2. Certification Authority ....................7
3.1.1.3. Registration Authority .....................7
3.1.2. PKI Management Requirements .........................8
3.1.3. PKI Management Operations ..........................10
4. Assumptions and Restrictions ...................................14
4.1. End Entity Initialization .................................14
1. Introduction ....................................................5
2. Requirements ....................................................5
3. PKI Management Overview .........................................5
3.1. PKI Management Model .......................................6
3.1.1. Definitions of PKI Entities .........................6
3.1.1.1. Subjects and End Entities ..................6
3.1.1.2. Certification Authority ....................7
3.1.1.3. Registration Authority .....................7
3.1.2. PKI Management Requirements .........................8
3.1.3. PKI Management Operations ..........................10
4. Assumptions and Restrictions ...................................14
4.1. End Entity Initialization .................................14
4.2. Initial Registration/Certification ........................14
4.2.1. Criteria Used ......................................15
4.2.1.1. Initiation of Registration/Certification ..15
4.2.1.2. End Entity Message Origin Authentication ..15
4.2.1.3. Location of Key Generation ................15
4.2.1.4. Confirmation of Successful Certification ..16
4.2.2. Mandatory Schemes ..................................16
4.2.2.1. Centralized Scheme ........................16
4.2.2.2. Basic Authenticated Scheme ................17
4.3. Proof-of-Possession (POP) of Private Key ..................17
4.3.1. Signature Keys .....................................18
4.3.2. Encryption Keys ....................................18
4.3.3. Key Agreement Keys .................................19
4.4. Root CA Key Update ........................................19
4.4.1. CA Operator Actions ................................20
4.4.2. Verifying Certificates .............................21
4.4.2.1. Verification in Cases 1, 4, 5, and 8 ......22
4.4.2.2. Verification in Case 2 ....................22
4.4.2.3. Verification in Case 3 ....................23
4.4.2.4. Failure of Verification in Case 6 .........23
4.4.2.5. Failure of Verification in Case 7 .........23
4.4.3. Revocation - Change of CA Key ......................23
5. Data Structures ................................................24
5.1. Overall PKI Message .......................................24
5.1.1. PKI Message Header .................................24
5.1.1.1. ImplicitConfirm ...........................27
5.1.1.2. ConfirmWaitTime ...........................27
5.1.2. PKI Message Body ...................................27
5.1.3. PKI Message Protection .............................28
5.1.3.1. Shared Secret Information .................29
5.1.3.2. DH Key Pairs ..............................30
5.1.3.3. Signature .................................30
5.1.3.4. Multiple Protection .......................30
5.2. Common Data Structures ....................................31
5.2.1. Requested Certificate Contents .....................31
5.2.2. Encrypted Values ...................................31
5.2.3. Status codes and Failure Information for
PKI Messages .......................................32
5.2.4. Certificate Identification .........................33
5.2.5. Out-of-band root CA Public Key .....................33
5.2.6. Archive Options ....................................34
5.2.7. Publication Information ............................34
5.2.8. Proof-of-Possession Structures .....................34
5.2.8.1. Inclusion of the Private Key ..............35
5.2.8.2. Indirect Method ...........................35
5.2.8.3. Challenge-Response Protocol ...............35
5.2.8.4. Summary of PoP Options ....................37
4.2. Initial Registration/Certification ........................14
4.2.1. Criteria Used ......................................15
4.2.1.1. Initiation of Registration/Certification ..15
4.2.1.2. End Entity Message Origin Authentication ..15
4.2.1.3. Location of Key Generation ................15
4.2.1.4. Confirmation of Successful Certification ..16
4.2.2. Mandatory Schemes ..................................16
4.2.2.1. Centralized Scheme ........................16
4.2.2.2. Basic Authenticated Scheme ................17
4.3. Proof-of-Possession (POP) of Private Key ..................17
4.3.1. Signature Keys .....................................18
4.3.2. Encryption Keys ....................................18
4.3.3. Key Agreement Keys .................................19
4.4. Root CA Key Update ........................................19
4.4.1. CA Operator Actions ................................20
4.4.2. Verifying Certificates .............................21
4.4.2.1. Verification in Cases 1, 4, 5, and 8 ......22
4.4.2.2. Verification in Case 2 ....................22
4.4.2.3. Verification in Case 3 ....................23
4.4.2.4. Failure of Verification in Case 6 .........23
4.4.2.5. Failure of Verification in Case 7 .........23
4.4.3. Revocation - Change of CA Key ......................23
5. Data Structures ................................................24
5.1. Overall PKI Message .......................................24
5.1.1. PKI Message Header .................................24
5.1.1.1. ImplicitConfirm ...........................27
5.1.1.2. ConfirmWaitTime ...........................27
5.1.2. PKI Message Body ...................................27
5.1.3. PKI Message Protection .............................28
5.1.3.1. Shared Secret Information .................29
5.1.3.2. DH Key Pairs ..............................30
5.1.3.3. Signature .................................30
5.1.3.4. Multiple Protection .......................30
5.2. Common Data Structures ....................................31
5.2.1. Requested Certificate Contents .....................31
5.2.2. Encrypted Values ...................................31
5.2.3. Status codes and Failure Information for
PKI Messages .......................................32
5.2.4. Certificate Identification .........................33
5.2.5. Out-of-band root CA Public Key .....................33
5.2.6. Archive Options ....................................34
5.2.7. Publication Information ............................34
5.2.8. Proof-of-Possession Structures .....................34
5.2.8.1. Inclusion of the Private Key ..............35
5.2.8.2. Indirect Method ...........................35
5.2.8.3. Challenge-Response Protocol ...............35
5.2.8.4. Summary of PoP Options ....................37
5.3. Operation-Specific Data Structures ........................38
5.3.1. Initialization Request .............................38
5.3.2. Initialization Response ............................39
5.3.3. Certification Request ..............................39
5.3.4. Certification Response .............................39
5.3.5. Key Update Request Content .........................40
5.3.6. Key Update Response Content ........................41
5.3.7. Key Recovery Request Content .......................41
5.3.8. Key Recovery Response Content ......................41
5.3.9. Revocation Request Content .........................41
5.3.10. Revocation Response Content .......................42
5.3.11. Cross Certification Request Content ...............42
5.3.12. Cross Certification Response Content ..............42
5.3.13. CA Key Update Announcement Content ................42
5.3.14. Certificate Announcement ..........................43
5.3.15. Revocation Announcement ...........................43
5.3.16. CRL Announcement ..................................43
5.3.17. PKI Confirmation Content ..........................43
5.3.18. Certificate Confirmation Content ..................44
5.3.19. PKI General Message Content .......................44
5.3.19.1. CA Protocol Encryption Certificate .......44
5.3.19.2. Signing Key Pair Types ...................45
5.3.19.3. Encryption/Key Agreement Key Pair Types ..45
5.3.19.4. Preferred Symmetric Algorithm ............45
5.3.19.5. Updated CA Key Pair ......................45
5.3.19.6. CRL ......................................46
5.3.19.7. Unsupported Object Identifiers ...........46
5.3.19.8. Key Pair Parameters ......................46
5.3.19.9. Revocation Passphrase ....................46
5.3.19.10. ImplicitConfirm .........................46
5.3.19.11. ConfirmWaitTime .........................47
5.3.19.12. Original PKIMessage .....................47
5.3.19.13. Supported Language Tags .................47
5.3.20. PKI General Response Content ......................47
5.3.21. Error Message Content .............................47
5.3.22. Polling Request and Response ......................48
6. Mandatory PKI Management Functions .............................51
6.1. Root CA Initialization ....................................51
6.2. Root CA Key Update ........................................51
6.3. Subordinate CA Initialization .............................51
6.4. CRL production ............................................52
6.5. PKI Information Request ...................................52
6.6. Cross Certification .......................................52
6.6.1. One-Way Request-Response Scheme: ...................52
6.7. End Entity Initialization .................................54
6.7.1. Acquisition of PKI Information .....................54
6.7.2. Out-of-Band Verification of Root-CA Key ............55
6.8. Certificate Request .......................................55
5.3. Operation-Specific Data Structures ........................38
5.3.1. Initialization Request .............................38
5.3.2. Initialization Response ............................39
5.3.3. Certification Request ..............................39
5.3.4. Certification Response .............................39
5.3.5. Key Update Request Content .........................40
5.3.6. Key Update Response Content ........................41
5.3.7. Key Recovery Request Content .......................41
5.3.8. Key Recovery Response Content ......................41
5.3.9. Revocation Request Content .........................41
5.3.10. Revocation Response Content .......................42
5.3.11. Cross Certification Request Content ...............42
5.3.12. Cross Certification Response Content ..............42
5.3.13. CA Key Update Announcement Content ................42
5.3.14. Certificate Announcement ..........................43
5.3.15. Revocation Announcement ...........................43
5.3.16. CRL Announcement ..................................43
5.3.17. PKI Confirmation Content ..........................43
5.3.18. Certificate Confirmation Content ..................44
5.3.19. PKI General Message Content .......................44
5.3.19.1. CA Protocol Encryption Certificate .......44
5.3.19.2. Signing Key Pair Types ...................45
5.3.19.3. Encryption/Key Agreement Key Pair Types ..45
5.3.19.4. Preferred Symmetric Algorithm ............45
5.3.19.5. Updated CA Key Pair ......................45
5.3.19.6. CRL ......................................46
5.3.19.7. Unsupported Object Identifiers ...........46
5.3.19.8. Key Pair Parameters ......................46
5.3.19.9. Revocation Passphrase ....................46
5.3.19.10. ImplicitConfirm .........................46
5.3.19.11. ConfirmWaitTime .........................47
5.3.19.12. Original PKIMessage .....................47
5.3.19.13. Supported Language Tags .................47
5.3.20. PKI General Response Content ......................47
5.3.21. Error Message Content .............................47
5.3.22. Polling Request and Response ......................48
6. Mandatory PKI Management Functions .............................51
6.1. Root CA Initialization ....................................51
6.2. Root CA Key Update ........................................51
6.3. Subordinate CA Initialization .............................51
6.4. CRL production ............................................52
6.5. PKI Information Request ...................................52
6.6. Cross Certification .......................................52
6.6.1. One-Way Request-Response Scheme: ...................52
6.7. End Entity Initialization .................................54
6.7.1. Acquisition of PKI Information .....................54
6.7.2. Out-of-Band Verification of Root-CA Key ............55
6.8. Certificate Request .......................................55
6.9. Key Update ................................................55
7. Version Negotiation ............................................56
7.1. Supporting RFC 2510 Implementations .......................56
7.1.1. Clients Talking to RFC 2510 Servers ................56
7.1.2. Servers Receiving Version cmp1999 PKIMessages ......57
8. Security Considerations ........................................57
8.1. Proof-Of-Possession with a Decryption Key .................57
8.2. Proof-Of-Possession by Exposing the Private Key ...........57
8.3. Attack Against Diffie-Hellman Key Exchange ................57
9. IANA Considerations ............................................58
Normative References ..............................................58
Informative References ............................................59
A. Reasons for the Presence of RAs ................................61
B. The Use of Revocation Passphrase ...............................61
C. Request Message Behavioral Clarifications ......................63
D. PKI Management Message Profiles (REQUIRED) .....................65
D.1. General Rules for Interpretation of These Profiles ........65
D.2. Algorithm Use Profile .....................................66
D.3. Proof-of-Possession Profile ...............................68
D.4. Initial Registration/Certification (Basic
Authenticated Scheme) .....................................68
D.5. Certificate Request .......................................74
D.6. Key Update Request ........................................75
E. PKI Management Message Profiles (OPTIONAL) .....................75
E.1. General Rules for Interpretation of These Profiles ........76
E.2. Algorithm Use Profile .....................................76
E.3. Self-Signed Certificates ..................................76
E.4. Root CA Key Update ........................................77
E.5. PKI Information Request/Response ..........................77
E.6. Cross Certification Request/Response (1-way) ..............79
E.7. In-Band Initialization Using External Identity
Certificate ..............................................82
F. Compilable ASN.1 Definitions ...................................83
G. Acknowledgements ...............................................93
6.9. Key Update ................................................55
7. Version Negotiation ............................................56
7.1. Supporting RFC 2510 Implementations .......................56
7.1.1. Clients Talking to RFC 2510 Servers ................56
7.1.2. Servers Receiving Version cmp1999 PKIMessages ......57
8. Security Considerations ........................................57
8.1. Proof-Of-Possession with a Decryption Key .................57
8.2. Proof-Of-Possession by Exposing the Private Key ...........57
8.3. Attack Against Diffie-Hellman Key Exchange ................57
9. IANA Considerations ............................................58
Normative References ..............................................58
Informative References ............................................59
A. Reasons for the Presence of RAs ................................61
B. The Use of Revocation Passphrase ...............................61
C. Request Message Behavioral Clarifications ......................63
D. PKI Management Message Profiles (REQUIRED) .....................65
D.1. General Rules for Interpretation of These Profiles ........65
D.2. Algorithm Use Profile .....................................66
D.3. Proof-of-Possession Profile ...............................68
D.4. Initial Registration/Certification (Basic
Authenticated Scheme) .....................................68
D.5. Certificate Request .......................................74
D.6. Key Update Request ........................................75
E. PKI Management Message Profiles (OPTIONAL) .....................75
E.1. General Rules for Interpretation of These Profiles ........76
E.2. Algorithm Use Profile .....................................76
E.3. Self-Signed Certificates ..................................76
E.4. Root CA Key Update ........................................77
E.5. PKI Information Request/Response ..........................77
E.6. Cross Certification Request/Response (1-way) ..............79
E.7. In-Band Initialization Using External Identity
Certificate ..............................................82
F. Compilable ASN.1 Definitions ...................................83
G. Acknowledgements ...............................................93
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for certificate creation and management. The term "certificate" in this document refers to an X.509v3 Certificate as defined in [X509].
本文档介绍Internet X.509公钥基础设施（PKI）证书管理协议（CMP）。协议消息是为证书创建和管理而定义的。本文件中的术语“证书”是指[X509]中定义的X.509v3证书。
This specification obsoletes RFC 2510. This specification differs from RFC 2510 in the following areas:
本规范淘汰RFC 2510。本规范与RFC 2510在以下方面有所不同：
The PKI management message profile section is split to two appendices: the required profile and the optional profile. Some of the formerly mandatory functionality is moved to the optional profile.
PKI管理消息配置文件部分分为两个附录：必需配置文件和可选配置文件。一些以前必须的功能被移动到可选配置文件中。
The message confirmation mechanism has changed substantially.
消息确认机制已发生重大变化。
A new polling mechanism is introduced, deprecating the old polling method at the CMP transport level.
引入了一种新的轮询机制，在CMP传输级别弃用了旧的轮询方法。
The CMP transport protocol issues are handled in a separate document [CMPtrans], thus the Transports section is removed.
CMP传输协议问题在单独的文档[CMPtrans]中处理，因此传输部分被删除。
A new implicit confirmation method is introduced to reduce the number of protocol messages exchanged in a transaction.
引入了一种新的隐式确认方法来减少事务中交换的协议消息数量。
The new specification contains some less prominent protocol enhancements and improved explanatory text on several issues.
新规范包含一些不太突出的协议增强功能，并改进了关于几个问题的解释性文本。
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]中所述进行解释。
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 whom the certificate is issued) and the certification authority (i.e., the entity that issues the certificate). A registration authority MAY also be involved in PKI management.
参与PKI管理的实体包括最终实体（即向其颁发证书的实体）和证书颁发机构（即颁发证书的实体）。注册机构也可能参与PKI管理。
The term "subject" is used here to refer to the entity to whom the certificate is issued, typically named in the subject or subjectAltName 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. 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 that 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 or subjectAltName 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.
此处使用术语“主体”指的是向其颁发证书的实体，通常在证书的主体或主体名称字段中命名。当我们希望区分受试者使用的工具和/或软件（例如，本地证书管理模块）时，我们将使用术语“受试者设备”。通常，为了避免与字段名混淆，首选术语“终端实体”（EE）而不是“主体”。需要注意的是，此处的终端实体不仅包括应用程序的人工用户，还包括应用程序本身（例如，用于IP安全）。该因素影响PKI管理操作使用的协议；例如，应用程序软件比人类用户更可能准确地知道需要哪些证书扩展。PKI管理实体也是终端实体，因为它们有时在证书或交叉证书的subject或subjectAltName字段中命名。在适当情况下，“最终实体”一词将用于指非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 that 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
所有终端实体都需要对某些信息进行安全的本地访问——至少是他们自己的名称和私钥、该实体直接信任的CA的名称以及该CA的公钥（或者在其他地方可以获得自认证版本的公钥指纹）。实现可能会使用安全本地存储超过此最小值（例如，终端实体自己的证书或
application-specific information). The form of storage will also vary -- from files to tamper-resistant cryptographic tokens. The information stored in such local, trusted storage is referred to here as the end entity's Personal Security Environment (PSE).
特定于应用程序的信息）。存储的形式也会有所不同——从文件到防篡改的加密令牌。存储在这种本地可信存储中的信息在这里称为终端实体的个人安全环境（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 that 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/IEC 9594-8/ITU-T X.509 standards.
1. PKI管理必须符合ISO/IEC 9594-8/ITU-T X.509标准。
2. It must be possible to regularly update any key pair without affecting any other key pair.
2. 必须能够在不影响任何其他密钥对的情况下定期更新任何密钥对。
3. The use of confidentiality in PKI management protocols must be kept to a minimum in order to ease acceptance in environments where strong confidentiality might cause regulatory problems.
3. PKI管理协议中保密性的使用必须保持在最低限度，以便在保密性强可能导致监管问题的环境中易于接受。
4. PKI management protocols must allow the use of different industry-standard cryptographic algorithms (specifically including RSA, DSA, MD5, and 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).
4. PKI管理协议必须允许使用不同的行业标准加密算法（特别是RSA、DSA、MD5和SHA-1）。这意味着任何给定的CA、RA或终端实体原则上可以使用适合其自身密钥对的算法。
5. 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.
5. PKI管理协议不得阻止相关终端实体、RA或CA生成密钥对。密钥生成也可能发生在其他地方，但出于PKI管理的目的，我们可以将密钥生成视为发生在密钥首先出现在终端实体、RA或CA的任何地方。
6. 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.
6. PKI管理协议必须支持相关终端实体、RA或CA发布证书。不同的实现和不同的环境可能会选择上述任何一种方法。
7. 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.
7. PKI管理协议必须支持证书撤销列表（CRL）的生成，允许经认证的最终实体发出证书撤销请求。这必须以这样的方式进行，即拒绝服务攻击（这是可能的）不会变得更简单。
8. PKI management protocols must be usable over a variety of "transport" mechanisms, specifically including mail, http, TCP/IP and ftp.
8. PKI管理协议必须能够通过各种“传输”机制使用，特别是邮件、http、TCP/IP和ftp。
9. 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 certConf message).
9. 证书创建的最终权限由CA负责。任何RA或最终实体设备都不能假定CA颁发的任何证书将包含所请求的内容；CA可以根据其操作策略更改证书字段值或添加、删除或更改扩展。换句话说，所有PKI实体（终端实体、RAs和CA）必须能够处理对证书请求的响应，其中实际颁发的证书与请求的证书不同（例如，CA可能缩短请求的有效期）。请注意，策略可能规定，在请求实体审查并接受新创建的证书之前（通常通过使用certConf消息），CA不得发布或以其他方式分发证书。
10. 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 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).
10. 必须支持从一个未泄露的CA密钥对到下一个（CA密钥更新）的优雅、计划的转换（注意，如果CA密钥泄露，则必须对该CA域中的所有实体执行重新初始化）。其PSE包含新CA公钥（CA密钥更新后）的最终实体还必须能够验证可使用旧公钥验证的证书。直接信任旧CA密钥对的终端实体还必须能够验证使用新CA私钥签署的证书（旧CA公钥“硬连线”到终端实体的加密设备的情况下需要）。
11. 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 regardless of whether the communication is with an RA or CA. Naturally, the end entity must use the correct RA of CA public key to protect the communication.
11. 在某些实现或环境中，RA的功能可能由CA本身执行。协议的设计必须确保终端实体将使用相同的协议，无论通信是与RA还是CA。自然，终端实体必须使用CA公钥的正确RA来保护通信。
12. 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 4.3 for details of the in-band methods defined for the PKIX-CMP (i.e., Certificate Management Protocol) messages.
12. 当终端实体请求包含给定公钥值的证书时，终端实体必须准备好证明拥有相应的私钥值。根据认证请求的类型，这可以通过各种方式实现。有关为PKIX-CMP（即证书管理协议）消息定义的带内方法的详细信息，请参见第4.3节。
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"
| e | | ^ loading
| r | | | initial
| t | a | | b registration/
| | | | certification
| / | | | key pair recovery
| | | | key pair update
| C | | | certificate update
| R | PKI "USERS" V | revocation request
| L | -------------------+-+-----+-+------+-+-------------------
| | PKI MANAGEMENT | ^ | ^
| | ENTITIES a | | b a | | b
| R | V | | |
| e | g +------+ d | |
| p | <------------ | RA | <-----+ | |
| o | cert. | | ----+ | | |
| s | publish +------+ c | | | |
| i | | | | |
| t | V | V |
| o | g +------------+ i
| r | <------------------------| CA |------->
| y | h +------------+ "out-of-band"
| | 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"
| e | | ^ loading
| r | | | initial
| t | a | | b registration/
| | | | certification
| / | | | key pair recovery
| | | | key pair update
| C | | | certificate update
| R | PKI "USERS" V | revocation request
| L | -------------------+-+-----+-+------+-+-------------------
| | PKI MANAGEMENT | ^ | ^
| | ENTITIES a | | b a | | b
| R | V | | |
| e | g +------+ d | |
| p | <------------ | RA | <-----+ | |
| o | cert. | | ----+ | | |
| s | publish +------+ c | | | |
| i | | | | |
| t | V | V |
| o | g +------------+ i
| r | <------------------------| CA |------->
| y | h +------------+ "out-of-band"
| | 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. 认证：各种操作导致创建新证书：
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).
1. 初始注册/认证：这是在CA为最终实体颁发一个或多个证书之前，最终实体首先向CA或RA表明自己的过程。此过程的最终结果（成功时）是CA为最终实体的公钥颁发证书，并将该证书返回给最终实体和/或将该证书发布到公共存储库中。该过程可能，并且通常将涉及多个“步骤”，可能包括最终实体设备的初始化。例如，终端实体的设备必须使用CA的公钥进行安全初始化，以用于验证证书路径。此外，终端实体通常需要使用自己的密钥对进行初始化。
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.
2. 密钥对更新：每个密钥对都需要定期更新（即用新密钥对替换），并且需要颁发新证书。
3. certificate update: As certificates expire, they may be "refreshed" if nothing relevant in the environment has changed.
3. 证书更新：当证书过期时，如果环境中没有任何相关内容发生更改，则可能会“刷新”证书。
4. CA key pair update: As with end entities, CA key pairs need to be updated regularly; however, different mechanisms are required.
4. CA密钥对更新：与终端实体一样，CA密钥对需要定期更新；然而，需要不同的机制。
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.
5. 交叉认证请求：一个CA请求从另一个CA颁发交叉证书。在本标准中，定义了以下术语。“交叉证书”是一种证书，其中主体CA和颁发者CA是不同的，并且主体PublicKeyInfo包含验证密钥（即，已为主体CA的签名密钥对颁发证书）。当需要更精细地区分时，可以使用以下术语：如果主体和颁发者CA属于不同的管理域，则交叉证书称为“域间交叉证书”；否则称为“域内交叉证书”。
1. 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. 注1。上述“交叉证书”的定义与X.509中定义的术语“CA证书”一致。请注意，不要将此术语与X.500“cACertificate”属性类型混淆，后者是不相关的。
2. 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. 附注2。在许多环境中，除非进一步限定，否则术语“交叉证书”将被理解为上文定义的“域间交叉证书”的同义词。
3. 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. 附注3。交叉证书的签发可能是相互的，但不一定是相互的；也就是说，两个CA可以相互颁发交叉证书。
6. cross-certificate update: Similar to a normal certificate update, but involving a cross-certificate.
6. 交叉证书更新：与普通证书更新类似，但涉及交叉证书。
4. Certificate/CRL discovery operations: some PKI management operations result in the publication of certificates or CRLs:
4. 证书/CRL发现操作：某些PKI管理操作导致证书或CRL的发布：
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 5.3.13 to 5.3.16, or MAY involve other methods (LDAP, for example) as described in [RFC2559], [RFC2585] (the "Operational Protocols" documents of the PKIX series of specifications).
1. 证书发布：遇到了生成证书的麻烦之后，需要一些发布证书的方法。PKIX中定义的“方法”可能涉及第5.3.13节至第5.3.16节中规定的消息，或者可能涉及[RFC2559]、[RFC2585]（PKIX系列规范的“操作协议”文件）中所述的其他方法（例如LDAP）。
2. CRL publication: As for certificate publication.
2. CRL发布：与证书发布一样。
5. Recovery operations: some PKI management operations are used when an end entity has "lost" its PSE:
5. 恢复操作：当终端实体“丢失”其PSE时，使用一些PKI管理操作：
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.
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：
1. revocation request: An authorized person advises a CA of an abnormal situation requiring certificate revocation.
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) that can form the basis of such operations.
7. PSE操作：虽然PSE操作的定义（例如，移动PSE、更改PIN等）超出了本规范的范围，但我们确实定义了可构成此类操作基础的PKI消息（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. Transport protocols for conveying these exchanges in different environments (file-based, on-line, E-mail, and WWW) are beyond the scope of this document and are specified separately.
后面的部分定义了一组支持上述操作的标准消息。用于在不同环境（基于文件、在线、电子邮件和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 that a CA may implement and the variation in the types of end entity which can occur.
有许多方案可用于实现最终实体的初始注册和认证。由于CA可能实施的策略范围以及可能发生的终端实体类型的变化，没有一种方法适用于所有情况。
However, we can 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 that will arise in real use, whilst the optional schemes are available for special cases that 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 that 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 secret value) via some out-of-band means. The initial authentication key can then be used to protect relevant PKI messages.
在本规范中，这种认证是通过PKI（CA/RA）通过一些带外手段向终端实体发布秘密值（初始认证密钥）和参考值（用于识别秘密值）来实现的。然后，可以使用初始身份验证密钥来保护相关的PKI消息。
Thus, we can 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 centralized key generation service; the actual key pair MAY have been
在本规范中，“密钥生成”被视为发生在密钥对的公共或私有组件首次出现在PKI消息中的任何地方。注意，这并不排除集中密钥生成服务；实际的密钥对可能已被删除
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。
Thus, there are 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 (Section 4.2.2.2). Any entity MAY additionally support other schemes, if desired.
上述标准允许大量初始注册/认证计划。本规范要求合格的CA设备、RA设备和EE设备必须支持下面列出的第二个方案（第4.2.2.2节）。如果需要，任何实体都可以额外支持其他方案。
In terms of the classification above, this scheme is, in some ways, the simplest possible, where:
就上述分类而言，该方案在某些方面是最简单的，其中：
o initiation occurs at the certifying CA;
o 启动发生在认证CA处；
o no on-line message authentication is required;
o 不需要在线消息验证；
o "key generation" occurs at the certifying CA (see Section 4.2.1.3);
o “密钥生成”发生在认证CA（见第4.2.1.3节）；
o no confirmation message is required.
o 不需要确认信息。
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 to decrypt any encrypted values.
在消息流方面，该方案意味着唯一需要的消息是从CA发送到终端实体。消息必须包含终端实体的整个PSE。必须提供一些带外手段，以允许终端实体对接收到的消息进行身份验证并解密任何加密值。
In terms of the classification above, this scheme is where:
就上述分类而言，本方案包括：
o initiation occurs at the end entity;
o 起始发生在实体的末端；
o message authentication is REQUIRED;
o 需要消息认证；
o "key generation" occurs at the end entity (see Section 4.2.1.3);
o “密钥生成”发生在终端实体（见第4.2.1.3节）；
o a confirmation message is REQUIRED.
o 需要确认信息。
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
-->>-- cert conf message -->>--
verify confirmation
create response
--<<-- conf ack (optional) --<<--
handle response
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
-->>-- cert conf message -->>--
verify confirmation
create response
--<<-- conf ack (optional) --<<--
handle response
(Where verification of the cert 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
为了防止某些攻击并允许CA/RA正确检查终端实体和密钥对之间绑定的有效性，此处指定的PKI管理操作使终端实体能够证明其拥有（即能够使用）与请求证书的公钥相对应的私钥。给定的CA/RA可自由选择如何实施POP（例如，带外程序手段与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 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.
在其认证交换中（即，这可能是一个政策问题）。但是，要求CAs/RAs必须通过某种方式强制执行POP，因为目前使用的许多非PKIX操作协议（各种电子邮件协议就是一个例子）没有明确检查终端实体和私钥之间的绑定。在验证绑定（用于签名、加密和密钥协议密钥对）的操作协议存在并普遍存在之前，只能假设该绑定已由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
根据请求证书的密钥类型，POP以不同的方式完成。如果一个密钥可以用于多种目的（例如RSA密钥），则可以使用任何适当的方法
be used (e.g., a key that may be used for signing, as well as other purposes, SHOULD NOT be sent to the CA/RA in order to prove possession).
使用（例如，可能用于签名以及其他目的的密钥不应发送给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 5.2.8). Decrypting a value can be achieved either directly or indirectly.
对于加密密钥，终端实体可以向CA/RA提供私钥，或者需要解密一个值以证明拥有私钥（见第5.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 that 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 that can only be used by the intended end entity.
间接方法是颁发为最终实体加密的证书（并让最终实体在确认消息中演示其解密该证书的能力）。这允许CA以只能由预期的最终实体使用的形式颁发证书。
This specification encourages use of the indirect method because it 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 directly trusted by some end entities. Self-signed CAs SHALL be considered as directly trusted CAs. Recognizing whether a non-self-signed CA is supposed to be directly trusted for some end entities is a matter of CA policy and is thus beyond the scope of this document.
本讨论仅适用于某些终端实体直接信任的CA。自签名CA应视为直接受信任的CA。识别非自签名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目录提供证书（总共四个：OldWithOld、OldWithNew、NewWithOld和NewWithNew），则必须生成两个额外的cACertificate属性值。
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 periods of certificates issued with the old CA key pair cannot exceed the end of the OldWithNew validity period.
附注2。虽然该方案可以推广到CA在其一个终端实体的证书的有效期内多次更新其密钥对的情况，但这种推广似乎价值不大。没有这种通用性只是意味着使用旧CA密钥对颁发的证书的有效期不能超过OldWithNew有效期的末尾。
Note 3. This scheme ensures that end entities will acquire the new CA public key, at the latest by 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 repository 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. However, the old CA public key will remain in use for some time. The old CA public key is no longer required (other than for non-repudiation) 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 or before the time by which the CA will next update its key pair.
“new with new”证书的有效期必须从新密钥对的生成时间开始，并在CA下次更新其密钥对的时间或之前结束。
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 repository in repository the the repository 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. repository
签名者案例1：案例3：案例5：案例7：certifi-在这种情况下，尽管在这种情况下cate是验证者CA运营商CA受CA保护的标准必须访问未使用的运营商使用新案例，其中更新未更新的公共存储库存储库密钥验证者为了获得验证者可以可以直接验证验证的值新证书将无法直接验证公钥-证书这与使用案例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 repository the key repository without will access verifier can in order using the the verify the to get the repository repository; 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相同。
In these cases, the verifier has a local copy of the CA public key that 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 repository. Case 5 can only arise if
注意，情况8可能出现在CA操作员生成新密钥对和CA操作员在存储库中存储更新的属性之间。情况5只有在以下情况下才会出现：
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)
CA运营商在此“间隙”期间同时颁发了签名者和验证者的证书（CA运营商应避免这一情况，因为这会导致以下所述的失败案例）
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 repository and pick the OldWithNew certificate (determined based on validity periods; note that the subject and issuer fields must match);
1. 在存储库中查找caCertificate属性，并选择OldWithNew证书（根据有效期确定；请注意，subject和issuer字段必须匹配）；
2. Verify that this is correct using the new CA key (which the verifier has locally);
2. 使用新的CA密钥（验证器在本地拥有）验证这是正确的；
3. If correct, check the signer's certificate using the old CA key.
3. 如果正确，请使用旧CA密钥检查签名者的证书。
Case 2 will arise when the CA operator has issued the signer's certificate, then changed the key, and then issued the verifier's certificate; so it is quite a typical case.
当CA运营商颁发了签名者证书，然后更改了密钥，然后颁发了验证者证书时，会出现第2种情况；所以这是一个很典型的例子。
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 repository and pick the NewWithOld certificate (determined based on validity periods; note that the subject and issuer fields must match);
1. 在存储库中查找CACertificate属性，并选择NewWithOld证书（根据有效期确定；请注意，主题和颁发者字段必须匹配）；
2. Verify that this is correct using the old CA key (which the verifier has stored locally);
2. 使用旧CA密钥（验证器已在本地存储）验证这一点是否正确；
3. If correct, check the signer's certificate using the new CA key.
3. 如果正确，请使用新CA密钥检查签名者的证书。
Case 3 will arise when the CA operator has issued the verifier's certificate, then changed the key, and then issued the signer's certificate; so it is also quite a typical case.
当CA操作员颁发了验证者证书，然后更改了密钥，然后颁发了签名者证书时，会出现第3种情况；所以这也是一个很典型的例子。
In this case, the CA has issued the verifier's PSE, which contains the new key, without updating the repository 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操作员的故障。
In this case, the CA has issued the signer's certificate protected with the new key without updating the repository 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 within the user's PSE.
如上所述，一旦允许CA更改其密钥，证书的验证就变得更加复杂。撤销检查也是如此，因为CA可能已使用比用户PSE中的私钥更新的私钥签署CRL。
The analysis of the alternatives is the same as for certificate verification.
备选方案的分析与证书验证的分析相同。
This section contains descriptions of the data structures required for PKI management messages. Section 6 describes constraints on their values and the sequence of events for each of the various PKI management operations.
本节介绍PKI管理消息所需的数据结构。第6节描述了对其值的约束以及各种PKI管理操作的事件顺序。
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 CMPCertificate
OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
The PKIHeader contains information that 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 { cmp1999(1), cmp2000(2) },
sender GeneralName,
recipient GeneralName,
messageTime [0] GeneralizedTime OPTIONAL,
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
transactionID [4] OCTET STRING OPTIONAL,
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
freeText [7] PKIFreeText OPTIONAL,
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
sender GeneralName,
recipient GeneralName,
messageTime [0] GeneralizedTime OPTIONAL,
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
transactionID [4] OCTET STRING OPTIONAL,
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
freeText [7] PKIFreeText OPTIONAL,
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
The pvno field is fixed (at 2) for this version of this specification.
对于本规范的此版本，pvno字段是固定的（在2处）。
The sender field contains the name of the sender of the PKIMessage. This name (in conjunction with senderKID, if supplied) should be sufficient to indicate the key to use 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) that 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）。
These fields MUST be used if required to uniquely identify a key (e.g., if more than one key is associated with a given sender name) and SHOULD be omitted otherwise.
如果需要唯一标识密钥（例如，如果多个密钥与给定的发送方名称关联），则必须使用这些字段，否则应忽略这些字段。
The transactionID field within the message header is to be used to allow the recipient of a message to correlate this with an ongoing transaction. This is needed for all transactions that consist of more than just a single request/response pair. For transactions that consist of a single request/response pair, the rules are as follows. A client MAY populate the transactionID field of the request. If a server receives such a request that has the transactionID field set, then it MUST set the transactionID field of the response to the same value. If a server receives such request with a missing transactionID field, then it MAY set transactionID field of the response.
消息头中的transactionID字段用于允许消息的收件人将其与正在进行的事务相关联。这对于不仅仅由单个请求/响应对组成的所有事务都是必需的。对于由单个请求/响应对组成的事务，规则如下所示。客户端可以填充请求的transactionID字段。如果服务器收到设置了transactionID字段的请求，则必须将响应的transactionID字段设置为相同的值。若服务器接收到缺少transactionID字段的请求，则可能会设置响应的transactionID字段。
For transactions that consist of more than just a single request/response pair, the rules are as follows. Clients SHOULD generate a transactionID for the first request. If a server receives such a request that has the transactionID field set, then it MUST set the transactionID field of the response to the same value. If a server receives such request with a missing transactionID field, then it MUST populate the transactionID field of the response with a server-generated ID. Subsequent requests and responses MUST all set the transactionID field to the thus established value. In all cases where a transactionID is being used, a given client MUST NOT have more than one transaction with the same transactionID in progress at any time (to a given server). Servers are free to require uniqueness of the transactionID or not, as long as they are able to correctly associate messages with the corresponding transaction. Typically, this means that a server will require the {client, transactionID} tuple to be unique, or even the transactionID alone to be unique, if it cannot distinguish clients based on transport-level information. A server receiving the first message of a transaction (which requires more than a single request/response pair) that contains a transactionID that does not allow it to meet the above constraints (typically because the transactionID is already in use) MUST send back an ErrorMsgContent with a PKIFailureInfo of transactionIdInUse. It is RECOMMENDED that the clients fill the transactionID field with 128 bits of (pseudo-) random data for the start of a transaction to reduce the probability of having the transactionID in use at the server.
对于由多个请求/响应对组成的事务，规则如下所示。客户端应为第一个请求生成transactionID。如果服务器收到设置了transactionID字段的请求，则必须将响应的transactionID字段设置为相同的值。如果服务器接收到缺少transactionID字段的请求，则必须使用服务器生成的ID填充响应的transactionID字段。后续请求和响应都必须将transactionID字段设置为这样建立的值。在使用transactionID的所有情况下，给定的客户端在任何时候都不得有多个具有相同transactionID的事务（到给定的服务器）。服务器可以自由地要求transactionID的唯一性，只要它们能够正确地将消息和相应的事务关联起来。通常，这意味着服务器将要求{client，transactionID}元组是唯一的，甚至要求transactionID本身是唯一的，如果它不能根据传输级别信息区分客户端。接收包含transactionID的事务（需要多个请求/响应对）的第一条消息的服务器必须发回带有TransactionIdUse的PKIFailureInfo的ErrorMsgContent，该事务包含不允许其满足上述约束的transactionID（通常是因为transactionID已在使用中）。建议客户端在事务开始时使用128位（伪）随机数据填充transactionID字段，以降低服务器上使用transactionID的可能性。
The senderNonce and recipNonce fields protect the PKIMessage against replay attacks. The senderNonce will typically be 128 bits of (pseudo-) random data generated by the sender, whereas the recipNonce is copied from the senderNonce of the previous message in the transaction.
SenderOnce和RecipOnce字段保护PKI消息免受重播攻击。发送方一次通常是发送方生成的128位（伪）随机数据，而Reciponce是从事务中上一条消息的发送方一次复制的。
The messageTime field contains the time at which the sender created the message. This may be useful to allow end entities to correct/check their local time for consistency 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. The following generalInfo extensions are defined and MAY be supported.
generalInfo字段可用于向收件人发送机器可处理的附加数据。已定义并可能支持以下generalInfo扩展。
This is used by the EE to inform the CA that it does not wish to send a certificate confirmation for issued certificates.
这被EE用来通知CA它不希望发送已颁发证书的证书确认。
implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
ImplicitConfirmValue ::= NULL
implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
ImplicitConfirmValue ::= NULL
If the CA grants the request to the EE, it MUST put the same extension in the PKIHeader of the response. If the EE does not find the extension in the response, it MUST send the certificate confirmation.
如果CA将请求授予EE，则必须在响应的PKI头中放置相同的扩展名。如果EE在响应中找不到扩展，则必须发送证书确认。
This is used by the CA to inform the EE how long it intends to wait for the certificate confirmation before revoking the certificate and deleting the transaction.
CA使用它来通知EE在撤销证书和删除交易之前，它打算等待证书确认多长时间。
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime
PKIBody ::= CHOICE {
ir [0] CertReqMessages, --Initialization Req
ip [1] CertRepMessage, --Initialization Resp
cr [2] CertReqMessages, --Certification Req
cp [3] CertRepMessage, --Certification Resp
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
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 Req
PKIBody ::= CHOICE {
ir [0] CertReqMessages, --Initialization Req
ip [1] CertRepMessage, --Initialization Resp
cr [2] CertReqMessages, --Certification Req
cp [3] CertRepMessage, --Certification Resp
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
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 Req
krp [10] KeyRecRepContent, --Key Recovery Resp rr [11] RevReqContent, --Revocation Request rp [12] RevRepContent, --Revocation Response ccr [13] CertReqMessages, --Cross-Cert. Request ccp [14] CertRepMessage, --Cross-Cert. Resp ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. cann [16] CertAnnContent, --Certificate Ann. rann [17] RevAnnContent, --Revocation Ann. crlann [18] CRLAnnContent, --CRL Announcement pkiconf [19] PKIConfirmContent, --Confirmation nested [20] NestedMessageContent, --Nested Message genm [21] GenMsgContent, --General Message genp [22] GenRepContent, --General Response error [23] ErrorMsgContent, --Error Message certConf [24] CertConfirmContent, --Certificate confirm pollReq [25] PollReqContent, --Polling request pollRep [26] PollRepContent --Polling response }
krp[10]密钥恢复内容，-密钥恢复响应rr[11]RevReqContent，-撤销请求rp[12]RevReqContent，-撤销响应ccr[13]CertReqMessages，-交叉证书请求ccp[14]CertreqMessage，-交叉证书响应ckuann[15]CAKeyUpdAnnContent，-CA密钥更新Ann。cann[16]CertAnnContent，--证书Ann。rann[17]RevAnnContent，--Ann。crlann[18]CRLAnnContent，--CRL公告pkiconf[19]PKIConfirmContent，--确认嵌套[20]嵌套消息内容，--嵌套消息genm[21]GenMsgContent，--一般消息genp[22]GenRepContent，--一般响应错误[23]ErrorMsgContent，--错误消息certConf[24]CertConfirmContent，--证书确认pollReq[25]PollReqContent，--轮询请求pollRep[26]PollRepContent--轮询响应}
The specific types are described in Section 5.3 below.
具体类型见下文第5.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 the 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消息将受到完整性保护。（请注意，如果使用非对称算法来保护消息，并且相关的公共组件已经过认证，则还可以对消息的来源进行身份验证。另一方面，如果公共组件未经认证，则消息来源无法自动进行身份验证，但可以通过带外身份验证。）意思是。）
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 be applied instead. Such a choice is explicitly allowed in this specification. Examples of such external protection include PKCS #7
可能存在故意不使用PKIX保护位字符串来保护消息的情况（即，省略此可选字段），因为将应用PKIX之外的其他保护。本规范明确允许这样的选择。此类外部保护的示例包括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). 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.
[PKCS7]和安全性多部分[RFC1847]封装PKI消息（或者简单地封装PKI主体（省略选择标记），前提是相关PKI头信息在外部机制中安全携带）。然而，需要注意的是，许多这样的外部机制要求最终实体已经拥有公钥证书和/或唯一的可分辨名称和/或其他这样的基础设施相关信息。因此，它们可能不适用于初始注册、密钥恢复或具有“引导”特性的任何其他过程。对于这些情况，可能需要使用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）或签名。只有以下情况才能发生：
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 (see also Appendix D.2):
在这种情况下，发送方和接收方共享秘密信息（通过带外方式或先前的PKI管理操作建立）。PKI保护将包含MAC值，保护值如下（另见附录D.2）：
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
}
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
}
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.]
在上面的protectionAlg中，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字节，“| |”表示串联。]
Note: it is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) in order to reduce the overhead associated with PasswordBasedMac computation).
注意：建议在单个事务（例如，ir/ip/certConf/pkiConf）的整个消息中，PBMPParameter字段保持不变，以减少与基于PasswordBasedMac计算相关的开销）。
Where the sender and receiver possess Diffie-Hellman certificates with compatible DH parameters, 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将如下所示：
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
id-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字节，“| |”表示串联。]
In this case, the sender possesses a signature key pair and simply signs 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）。
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
在终端实体向RA发送受保护的PKI消息的情况下，RA可以将该消息转发给CA，附加其自身的保护（可以是MAC或签名，取决于RA和CA之间共享的信息和证书）。这已经完成了
by nesting the entire message sent by the end entity within a new PKI message. The structure used is as follows.
通过将终端实体发送的整个消息嵌套在新的PKI消息中。使用的结构如下。
NestedMessageContent ::= PKIMessages
NestedMessageContent ::= PKIMessages
(The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch the requests of several EEs in a single new message. For simplicity, all messages in the batch MUST be of the same type (e.g., ir).) If the RA wishes to modify the message(s) in some way (e.g., add particular field values or new extensions), then it MAY create its own desired PKIBody. The original PKIMessage from the EE MAY be included in the generalInfo field of PKIHeader (to accommodate, for example, cases in which the CA wishes to check POP or other information on the original EE message). The infoType to be used in this situation is {id-it 15} (see Section 5.3.19 for the value of id-it) and the infoValue is PKIMessages (contents MUST be in the same order as the requests in PKIBody).
（使用PKIMessage，即PKIMessage序列，可使RA在单个新消息中批处理多个EE的请求。为简单起见，批处理中的所有消息必须为相同类型（例如，ir）。）如果RA希望以某种方式修改消息（例如，添加特定字段值或新扩展名），然后，它可以创建自己想要的主体。来自EE的原始pki消息可以包括在pki消息头的generalInfo字段中（以适应例如CA希望检查原始EE消息上的POP或其他信息的情况）。在这种情况下使用的信息类型是{id it 15}（id it的值见第5.3.19节），信息值是PKIMessages（内容的顺序必须与PKIBody中的请求相同）。
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 requester MUST send back a certConf message that either does not include this certificate (via a CertHash), or does include this certificate (via a CertHash) along with a status of "rejected". See Section 5.3.18 for the definition and use of CertHash and the certConf message.
请注意，即使发起人完全指定了它所需的证书的内容，CA也可以自由修改实际颁发的证书中的字段。如果请求者无法接受修改后的证书，则请求者必须返回一条certConf消息，该消息要么不包含此证书（通过CertHash），要么包含此证书（通过CertHash），并且状态为“已拒绝”。有关CertHash和certConf消息的定义和使用，请参见第5.3.18节。
See Appendix C and [CRMF] for CertTemplate syntax.
有关CertTemplate语法，请参见附录C和[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 be able to encrypt and decrypt, respectively. 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 {
accepted (0),
grantedWithMods (1),
rejection (2),
waiting (3),
revocationWarning (4),
revocationNotification (5),
keyUpdateWarning (6)
}
PKIStatus ::= INTEGER {
accepted (0),
grantedWithMods (1),
rejection (2),
waiting (3),
revocationWarning (4),
revocationNotification (5),
keyUpdateWarning (6)
}
Responders may use the following syntax to provide more information about failure cases.
响应者可以使用以下语法提供有关故障案例的更多信息。
PKIFailureInfo ::= BIT STRING {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
badDataFormat (5),
wrongAuthority (6),
incorrectData (7),
missingTimeStamp (8),
badPOP (9),
certRevoked (10),
certConfirmed (11),
wrongIntegrity (12),
badRecipientNonce (13),
timeNotAvailable (14),
unacceptedPolicy (15),
unacceptedExtension (16),
addInfoNotAvailable (17),
PKIFailureInfo ::= BIT STRING {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
badDataFormat (5),
wrongAuthority (6),
incorrectData (7),
missingTimeStamp (8),
badPOP (9),
certRevoked (10),
certConfirmed (11),
wrongIntegrity (12),
badRecipientNonce (13),
timeNotAvailable (14),
unacceptedPolicy (15),
unacceptedExtension (16),
addInfoNotAvailable (17),
badSenderNonce (18), badCertTemplate (19), signerNotTrusted (20), transactionIdInUse (21), unsupportedVersion (22), notAuthorized (23), systemUnavail (24), systemFailure (25), duplicateCertReq (26) }
BadSenderOnce（18）、badCertTemplate（19）、signerNotTrusted（20）、TransactionIdUse（21）、unsupportedVersion（22）、notAuthorized（23）、systemUnavail（24）、systemFailure（25）、duplicateCertReq（26）}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
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 that 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:
此证书中的字段限制如下：
o The certificate MUST be self-signed (i.e., the signature must be verifiable using the SubjectPublicKeyInfo field);
o 证书必须是自签名的（即，签名必须可以使用SubjectPublicKeyInfo字段进行验证）；
o The subject and issuer fields MUST be identical;
o “主题”和“颁发者”字段必须相同；
o If the subject field is NULL, then both subjectAltNames and issuerAltNames extensions MUST be present and have exactly the same value;
o 如果subject字段为空，则SubjectAltName和issuerAltNames扩展名都必须存在，并且具有完全相同的值；
o 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).
o 所有其他扩展的值必须适用于自签名证书（例如，主体和颁发者的密钥标识符必须相同）。
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
}
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
}
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 Appendix C and [CRMF] for POPOSigningKey syntax, but note that POPOSigningKeyInput has the following semantic stipulations in this specification.
POPOSigningKey语法见附录C和[CRMF]，但请注意，POPOSigningKeyInput在本规范中有以下语义规定。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
publicKeyMAC PKMACValue
},
publicKey SubjectPublicKeyInfo
}
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
publicKeyMAC PKMACValue
},
publicKey SubjectPublicKeyInfo
}
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.
另一方面，如果认证请求是针对加密密钥对的（即，针对加密证书的请求），则可以通过三种方式之一来证明私有解密密钥的占有证明。
By the inclusion of the private key (encrypted) in the CertRequest (in the thisMessage field of POPOPrivKey (see Appendix C) or in the PKIArchiveOptions control structure, depending upon whether or not archival of the private key is also desired).
通过在CertRequest（POPOPrivKey的thisMessage字段（见附录C）或PKIArchiveOptions控制结构中包含私钥（加密），具体取决于是否需要私钥存档）。
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 4.3.2. The end entity proves knowledge of the private decryption key to the CA by providing the correct CertHash for this certificate in the certConf message. This demonstrates POP because the EE can only compute the correct CertHash if it is able to recover the certificate, and it can only recover the certificate if it is able to decrypt the symmetric key using the required private key. Clearly, for this to work, the CA MUST NOT publish the certificate until the certConf message arrives (when certHash is to be used to demonstrate POP). See Section 5.3.18 for further details.
通过让CA返回的不是证书，而是加密的证书（即，根据随机生成的对称密钥加密的证书，以及根据公钥加密的对称密钥，对其进行认证请求）——这是前面第4.3.2节提到的“间接”方法。最终实体通过在certConf消息中为该证书提供正确的CertHash来向CA证明私有解密密钥的知识。这演示了POP，因为EE只有在能够恢复证书时才能计算正确的CertHash，并且只有在能够使用所需的私钥解密对称密钥时才能恢复证书。显然，要使其工作，CA必须在certConf消息到达（当certHash用于演示POP时）之前发布证书。详见第5.3.18节。
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 4.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):
通过让终端实体参与CertReqMessages和CertRepMessage之间的质询-响应协议（使用消息POPODecKeyChall和POPODecKeyResp；见下文），这是前面第4.3.2节提到的“直接”方法。（此方法通常用于RA验证POP，然后代表最终实体向CA发出证书请求的环境。在这种情况下，CA相信RA在为最终实体请求证书之前已正确执行POP。）完整协议如下所示（请注意，req’不一定将req封装为嵌套消息）：
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- ack -----
<--- rep -----
---- conf --->
<--- ack -----
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- ack -----
<--- rep -----
---- conf --->
<--- ack -----
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. In some environments, a different order of the above messages may be required, such as the following (this may be determined by policy):
该协议显然比上述选择（2）中给出的三方交换长得多，但允许当地注册机构参与，并具有在完成占有证明之前证书本身不会实际创建的属性。在某些环境中，可能需要上述消息的不同顺序，例如以下消息（这可能由策略决定）：
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
<--- rep -----
---- conf --->
---- conf --->
<--- ack -----
<--- ack -----
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
<--- rep -----
---- conf --->
---- conf --->
<--- ack -----
<--- ack -----
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 parenthetical text of the challenge field of "Challenge" below is replaced with "(using PreferredSymmAlg (see Section 5.3.19.4 and Appendix E.5) 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.
如果证书请求是针对密钥协议密钥（KAK）对的，则POP可以使用上述3种方式中的任何一种来处理加密密钥对，并进行以下更改：（1）项目符号2的插入文本替换为“（即，使用从CA的私有KAK派生的对称密钥加密的证书和正在进行认证请求的公钥）；（2）以下“质询”质询字段的第一个括号文本替换为“（使用PreferredSymmAlg（见第5.3.19.4节和附录e.5）以及从CA的私有KAK派生的对称密钥和正在进行认证请求的公钥）”。或者，POP可以使用[CRMF]中给出的POPOSigningKey结构（其中alg字段为DHBasedMAC，签名字段为MAC）如果CA已经拥有EE已知的D-H证书，则作为演示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 transactionID used in the PKIHeader and by the protection (MACing or signing) applied to the PKIMessage.
用于证明拥有私有解密密钥的质询响应消息指定如下（有关详细信息，请参见[MvOV97]，第404页）。请注意，此质询-响应交换通过PKI标头中使用的transactionID和应用于PKI消息的保护（标记或签名）与前面的证书请求消息（以及后续的证书响应和确认消息）相关联。
POPODecKeyChallContent ::= SEQUENCE OF Challenge
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
witness OCTET STRING,
challenge OCTET STRING
}
POPODecKeyChallContent ::= SEQUENCE OF Challenge
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
witness OCTET STRING,
challenge OCTET STRING
}
Note that the size of Rand needs to be appropriate for encryption under the public key of the requester. Given that "int" will typically not be longer than 64 bits, this leaves well over 100 bytes of room for the "sender" field when the modulus is 1024 bits. If, in some environment, names are so long that they cannot fit (e.g., very long DNs), then whatever portion will fit should be used (as long as it includes at least the common name, and as long as the receiver is able to deal meaningfully with the abbreviation).
请注意，Rand的大小需要适合请求者公钥下的加密。考虑到“int”通常不超过64位，当模数为1024位时，这为“sender”字段留出了超过100字节的空间。如果在某些环境中，名称太长以至于无法匹配（例如，非常长的DNs），则应使用适合的任何部分（只要它至少包括通用名称，并且只要接收者能够有意义地处理缩写）。
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
The text in this section provides several options with respect to POP techniques. Using "SK" for "signing key", "EK" for "encryption key", and "KAK" for "key agreement key", the techniques may be summarized as follows:
本节中的文本提供了有关POP技术的几个选项。使用“SK”表示“签名密钥”，“EK”表示“加密密钥”，使用“KAK”表示“密钥协议密钥”，技术可总结如下：
RAVerified;
SKPOP;
EKPOPThisMessage;
KAKPOPThisMessage;
KAKPOPThisMessageDHMAC;
EKPOPEncryptedCert;
KAKPOPEncryptedCert;
EKPOPChallengeResp; and
KAKPOPChallengeResp.
RAVerified;
SKPOP;
EKPOPThisMessage;
KAKPOPThisMessage;
KAKPOPThisMessageDHMAC;
EKPOPEncryptedCert;
KAKPOPEncryptedCert;
EKPOPChallengeResp; and
KAKPOPChallengeResp.
Given this array of options, it is natural to ask how an end entity can know what is supported by the CA/RA (i.e., which options it may use when requesting certificates). The following guidelines should clarify this situation for EE implementers.
考虑到这一系列选项，自然会问终端实体如何知道CA/RA支持什么（即，在请求证书时可以使用哪些选项）。以下指南应该为EE实施者澄清这种情况。
RAVerified. This is not an EE decision; the RA uses this if and only if it has verified POP before forwarding the request on to the CA, so it is not possible for the EE to choose this technique.
贪婪的。这不是EE的决定；RA在将请求转发到CA之前验证了POP时才使用此方法，因此EE不可能选择此方法。
SKPOP. If the EE has a signing key pair, this is the only POP method specified for use in the request for a corresponding certificate.
斯科普。如果EE具有签名密钥对，则这是在请求相应证书时指定使用的唯一POP方法。
EKPOPThisMessage and KAKPOPThisMessage. Whether or not to give up its private key to the CA/RA is an EE decision. If the EE decides to reveal its key, then these are the only POP methods available in this specification to achieve this (and the key pair type will determine which of these two methods to use).
EKPOPThisMessage和KAKPOPThisMessage。是否向CA/RA放弃其私钥是EE的决定。如果EE决定公开其密钥，那么本规范中只有这些POP方法可以实现这一点（密钥对类型将决定使用这两种方法中的哪一种）。
KAKPOPThisMessageDHMAC. The EE can only use this method if (1) the CA has a DH certificate available for this purpose, and (2) the EE already has a copy of this certificate. If both these conditions hold, then this technique is clearly supported and may be used by the EE, if desired.
KAKPOPThisMessageDHMAC。仅当（1）CA有可用于此目的的DH证书，以及（2）EE已经有此证书的副本时，EE才能使用此方法。如果这两个条件都成立，那么这种技术就得到了明确的支持，如果需要的话，EE也可以使用这种技术。
EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp. The EE picks one of these (in the subsequentMessage field) in the request message, depending upon preference and key pair type. The EE is not doing POP at this point; it is simply indicating which method it wants to use. Therefore, if the CA/RA replies with a "badPOP" error, the EE can re-request using the other POP method chosen in subsequentMessage. Note, however, that this specification encourages the use of the EncryptedCert choice and, furthermore, says that the challenge-response would typically be used when an RA is involved and doing POP verification. Thus, the EE should be able to make an intelligent decision regarding which of these POP methods to choose in the request message.
EKPOPEncryptedCert，KAKPOPEncryptedCert，EKPOPChallengeResp，KAKPOPChallengeResp。EE在请求消息中选择其中一个（在subsequentMessage字段中），具体取决于首选项和密钥对类型。EE在这一点上没有做POP；它只是指示要使用哪种方法。因此，如果CA/RA回复“badPOP”错误，则EE可以使用在后续消息中选择的其他POP方法重新请求。但是，请注意，本规范鼓励使用EncryptedCert选项，并且还指出，当涉及RA并进行POP验证时，通常会使用质询响应。因此，EE应该能够智能地决定在请求消息中选择哪种POP方法。
An Initialization request message contains as the PKIBody a 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 D profiles for further information). This message is intended to be used for entities when first initializing into the PKI.
初始化请求消息包含CertReqMessages数据结构作为PKI主体，该数据结构指定请求的证书。通常，SubjectPublicKeyInfo、KeyId和Validity是可为请求的每个证书提供的模板字段（有关更多信息，请参阅附录D配置文件）。此消息用于首次初始化到PKI时的实体。
See Appendix C and [CRMF] for CertReqMessages syntax.
有关CertReqMessages语法，请参见附录C和[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 protocolEncrKey).
初始化响应消息包含一个CertRepMessage数据结构作为PKIBody，该数据结构为每个请求的证书提供一个PKIStatusInfo字段、一个主题证书，可能还有一个私钥（通常使用会话密钥加密，会话密钥本身使用ProtocolEncrey加密）。
See Section 5.3.4 for CertRepMessage syntax. Note that if the PKI Message Protection is "shared secret information" (see Section 5.1.3), then any certificate transported in the caPubs field may be directly trusted as a root CA certificate by the initiator.
有关CertRepMessage语法，请参见第5.3.4节。请注意，如果PKI消息保护是“共享机密信息”（参见第5.1.3节），则发起方可以直接将caPubs字段中传输的任何证书作为根CA证书进行信任。
A 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 Appendix C and [CRMF] for CertReqMessages syntax.
有关CertReqMessages语法，请参见附录C和[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 Certification 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,
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-utf8Pairs string defined
CertResponse ::= SEQUENCE {
certReqId INTEGER,
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-utf8Pairs string defined
-- for regInfo in CertReqMsg [CRMF] }
--对于CertReqMsg[CRMF]}中的regInfo
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- see [CRMF] for comment on encoding
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- see [CRMF] for comment on encoding
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 that can use the relevant private key (note that the proof is not obtained until the certConf 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 (but MAY do so anyway, depending upon policy).
提供加密证书和相关解密密钥，即可获得证书。这样做的目的是允许CA返回证书的值，但有一个限制，即只有预期的收件人才能获得实际的证书。这种方法的好处是，即使在没有证明请求者是可以使用相关私钥的最终实体的情况下，CA也可以使用证书进行回复（请注意，在CA收到certConf消息之前，不会获得证明）。因此，如果占有证明出现问题，CA将不必撤销该证书（但无论如何都可以撤销，具体取决于政策）。
For key update requests the CertReqMessages syntax is used. Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields that 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 (therefore, it is sometimes referred to as a "Certificate Update" operation). An update is a replacement certificate containing either a new subject public key or the current subject public key (although the latter practice may not be appropriate for some environments).
对于密钥更新请求，使用CertReqMessages语法。通常，SubjectPublicKeyInfo、KeyId和Validity是为每个要更新的密钥提供的模板字段。此消息用于请求对现有（未吊销和未过期）证书的更新（因此，有时称为“证书更新”操作）。更新是包含新主题公钥或当前主题公钥的替换证书（尽管后一种做法可能不适用于某些环境）。
See Appendix C and [CRMF] for CertReqMessages syntax.
有关CertReqMessages语法，请参见附录C和[CRMF]。
For key update responses, the CertRepMessage syntax is used. The response is identical to the initialization response.
对于密钥更新响应，使用CertRepMessage语法。该响应与初始化响应相同。
See Section 5.3.4 for CertRepMessage syntax.
有关CertRepMessage语法，请参见第5.3.4节。
For key recovery requests the syntax used is identical to the initialization request CertReqMessages. Typically, SubjectPublicKeyInfo and KeyId are the template fields that may be used to supply a signature public key for which a certificate is required (see Appendix D profiles for further information).
对于密钥恢复请求，使用的语法与初始化请求CertReqMessages相同。通常，SubjectPublicKeyInfo和KeyId是模板字段，可用于提供需要证书的签名公钥（有关更多信息，请参阅附录D配置文件）。
See Appendix C and [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语法，请参见附录C和[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,
crlEntryDetails Extensions OPTIONAL
}
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
crlEntryDetails Extensions OPTIONAL
}
The revocation response is 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,
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList
OPTIONAL
}
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList
OPTIONAL
}
Cross certification requests use the same syntax (CertReqMessages) as 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. This request MAY also be used by subordinate CAs to get their certificates signed by the parent CA.
交叉认证请求使用与普通认证请求相同的语法（CertReqMessages），但有一个限制，即密钥对必须由请求CA生成，并且私钥不得发送到响应CA。下级CA也可以使用此请求来获取由父CA签名的证书。
See Appendix C and [CRMF] for CertReqMessages syntax.
有关CertReqMessages语法，请参见附录C和[CRMF]。
Cross certification responses use the same syntax (CertRepMessage) as normal certification responses, with the restriction that no encrypted private key can be sent.
交叉认证响应使用与正常认证响应相同的语法（CertRepMessage），但限制不能发送加密的私钥。
See Section 5.3.4 for CertRepMessage syntax.
有关CertRepMessage语法，请参见第5.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,
newWithOld Certificate,
newWithNew Certificate
}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate,
newWithOld Certificate,
newWithNew Certificate
}
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
}
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
}
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 the protocol exchange 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
Use of this message for certificate confirmation is NOT RECOMMENDED; certConf SHOULD be used instead. Upon receiving a PKIConfirm for a certificate response, the recipient MAY treat it as a certConf with all certificates being accepted.
不建议将此消息用于证书确认；应改用certConf。在收到证书响应的PKIConfirm后，接收方可以将其视为certConf，并接受所有证书。
This data structure is used by the client to send a confirmation to the CA/RA to accept or reject certificates.
客户端使用此数据结构向CA/RA发送确认以接受或拒绝证书。
CertConfirmContent ::= SEQUENCE OF CertStatus
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
certReqId INTEGER,
statusInfo PKIStatusInfo OPTIONAL
}
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
certReqId INTEGER,
statusInfo PKIStatusInfo OPTIONAL
}
For any particular CertStatus, omission of the statusInfo field indicates ACCEPTANCE of the specified certificate. Alternatively, explicit status details (with respect to acceptance or rejection) MAY be provided in the statusInfo field, perhaps for auditing purposes at the CA/RA.
对于任何特定的CertStatus，省略statusInfo字段表示接受指定的证书。或者，可以在statusInfo字段中提供明确的状态详细信息（关于接受或拒绝），可能用于CA/RA的审计目的。
Within CertConfirmContent, omission of a CertStatus structure corresponding to a certificate supplied in the previous response message indicates REJECTION of the certificate. Thus, an empty CertConfirmContent (a zero-length SEQUENCE) MAY be used to indicate rejection of all supplied certificates. See Section 5.2.8, item (2), for a discussion of the certHash field with respect to proof-of-possession.
在CertConfirmContent中，省略与前一响应消息中提供的证书对应的CertStatus结构表示拒绝证书。因此，空CertConfirmContent（零长度序列）可用于指示拒绝所有提供的证书。有关占有证明的certHash字段的讨论，请参见第5.2.8节第（2）项。
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
This MAY be used by the EE to get a certificate from the CA to use to protect sensitive information during the protocol.
EE可以使用该证书从CA获取证书，用于在协议期间保护敏感信息。
GenMsg: {id-it 1}, < absent >
GenRep: {id-it 1}, Certificate | < absent >
GenMsg: {id-it 1}, < absent >
GenRep: {id-it 1}, Certificate | < absent >
EEs MUST ensure that the correct certificate is used for this purpose.
EEs必须确保为此目的使用了正确的证书。
This MAY be used by the EE to get the list of signature algorithms (e.g., RSA, DSA) whose subject public key values the CA is willing to certify. Note that for the purposes of this exchange, rsaEncryption and rsaWithSHA1, for example, are considered to be equivalent; the question being asked is, "Is the CA willing to certify an RSA public key?"
EE可使用此信息获取签名算法（例如RSA、DSA）列表，CA愿意验证其主题公钥值。请注意，就本次交换而言，例如，RSA加密和RSA Withsha1被认为是等效的；问题是，“CA是否愿意认证RSA公钥？”
GenMsg: {id-it 2}, < absent >
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
GenMsg: {id-it 2}, < absent >
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
This MAY be used by the client to get the list of encryption/key agreement algorithms whose subject public key values the CA is willing to certify.
客户机可以使用它来获取加密/密钥协议算法的列表，CA愿意认证这些算法的主题公钥值。
GenMsg: {id-it 3}, < absent >
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
GenMsg: {id-it 3}, < absent >
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
This MAY be used by the client to get the CA-preferred symmetric encryption algorithm for any confidential information that needs to be exchanged between the EE and the CA (for example, if the EE wants to send its private decryption key to the CA for archival purposes).
客户机可以使用该方法来获取CA首选的对称加密算法，该算法用于需要在EE和CA之间交换的任何机密信息（例如，如果EE希望将其私有解密密钥发送给CA进行存档）。
GenMsg: {id-it 4}, < absent >
GenRep: {id-it 4}, AlgorithmIdentifier
GenMsg: {id-it 4}, < absent >
GenRep: {id-it 4}, AlgorithmIdentifier
This MAY be used by the CA to announce a CA key update event.
CA可使用此消息来宣布CA密钥更新事件。
GenMsg: {id-it 5}, CAKeyUpdAnnContent
GenMsg: {id-it 5}, CAKeyUpdAnnContent
This MAY be used by the client to get a copy of the latest CRL.
客户可使用此功能获取最新CRL的副本。
GenMsg: {id-it 6}, < absent >
GenRep: {id-it 6}, CertificateList
GenMsg: {id-it 6}, < absent >
GenRep: {id-it 6}, CertificateList
This is used by the server to return a list of object identifiers that it does not recognize or support from the list submitted by the client.
服务器使用它从客户端提交的列表中返回它不识别或不支持的对象标识符列表。
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
This MAY be used by the EE to request the domain parameters to use for generating the key pair for certain public-key algorithms. It can be used, for example, to request the appropriate P, Q, and G to generate the DH/DSA key, or to request a set of well-known elliptic curves.
这可由EE用于请求域参数以用于生成特定公钥算法的密钥对。例如，它可以用于请求适当的P、Q和G以生成DH/DSA密钥，或者请求一组众所周知的椭圆曲线。
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | < absent >
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | < absent >
An absent infoValue in the GenRep indicates that the algorithm specified in GenMsg is not supported.
GenRep中缺少infoValue表示不支持GenMsg中指定的算法。
EEs MUST ensure that the parameters are acceptable to it and that the GenRep message is authenticated (to avoid substitution attacks).
EEs必须确保参数是可接受的，并且GenRep消息经过身份验证（以避免替换攻击）。
This MAY be used by the EE to send a passphrase to a CA/RA for the purpose of authenticating a later revocation request (in the case that the appropriate signing private key is no longer available to authenticate the request). See Appendix B for further details on the use of this mechanism.
这可由EE用于向CA/RA发送密码短语，以便认证稍后的撤销请求（在适当的签名私钥不再可用于认证请求的情况下）。有关此机制使用的更多详细信息，请参见附录B。
GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, < absent >
GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, < absent >
See Section 5.1.1.1 for the definition and use of {id-it 13}.
有关{id it 13}的定义和使用，请参见第5.1.1.1节。
See Section 5.1.1.2 for the definition and use of {id-it 14}.
有关{id it 14}的定义和使用，请参见第5.1.1.2节。
See Section 5.1.3 for the definition and use of {id-it 15}.
有关{id it 15}的定义和使用，请参见第5.1.3节。
This MAY be used to determine the appropriate language tag to use in subsequent messages. The sender sends its list of supported languages (in order, most preferred to least); the receiver returns the one it wishes to use. (Note: each UTF8String MUST include a language tag.) If none of the offered tags are supported, an error MUST be returned.
这可用于确定在后续消息中使用的适当语言标记。发送方发送其支持的语言列表（按顺序，从最优先到最不优先）；接收者返回它想要使用的那个。（注意：每个UTF8String必须包含一个语言标记。）如果不支持任何提供的标记，则必须返回错误。
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
Examples of GenReps that MAY be supported include those listed in the subsections of Section 5.3.19.
可能支持的GenRep示例包括第5.3.19节小节中列出的GenRep。
This data structure MAY be used by EE, CA, or RA to convey error info.
EE、CA或RA可以使用此数据结构来传递错误信息。
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
errorDetails PKIFreeText OPTIONAL
}
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
errorDetails PKIFreeText OPTIONAL
}
This message MAY be generated at any time during a PKI transaction. If the client sends this request, the server MUST respond with a PKIConfirm response, or another ErrorMsg if any part of the header is not valid. Both sides MUST treat this message as the end of the transaction (if a transaction is in progress).
此消息可在PKI交易期间的任何时间生成。如果客户端发送此请求，服务器必须使用PKIConfirm响应进行响应，如果标头的任何部分无效，则必须使用另一个ErrorMsg进行响应。双方必须将此消息视为交易的结束（如果交易正在进行）。
If protection is desired on the message, the client MUST protect it using the same technique (i.e., signature or MAC) as the starting message of the transaction. The CA MUST always sign it with a signature key.
如果需要对消息进行保护，则客户端必须使用与事务起始消息相同的技术（即签名或MAC）对其进行保护。CA必须始终使用签名密钥对其进行签名。
This pair of messages is intended to handle scenarios in which the client needs to poll the server in order to determine the status of an outstanding ir, cr, or kur transaction (i.e., when the "waiting" PKIStatus has been received).
这对消息用于处理客户端需要轮询服务器以确定未完成的ir、cr或kur事务的状态（即，当收到“等待”状态时）的场景。
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER }
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER }
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL }
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL }
The following clauses describe when polling messages are used, and how they are used. It is assumed that multiple certConf messages can be sent during transactions. There will be one sent in response to each ip, cp, or kup that contains a CertStatus for an issued certificate.
以下子句描述何时使用轮询消息以及如何使用它们。假定在事务期间可以发送多个certConf消息。对于包含已颁发证书的CertStatus的每个ip、cp或kup，将发送一个响应。
1. In response to an ip, cp, or kup message, an EE will send a certConf for all issued certificates and, following the ack, a pollReq for all pending certificates.
1. 作为对ip、cp或kup消息的响应，EE将为所有已颁发的证书发送certConf，并在确认之后为所有待定证书发送pollReq。
2. In response to a pollReq, a CA/RA will return an ip, cp, or kup if one or more of the pending certificates is ready; otherwise, it will return a pollRep.
2. 作为对pollReq的响应，如果一个或多个挂起证书就绪，CA/RA将返回ip、cp或kup；否则，它将返回一个pollRep。
3. If the EE receives a pollRep, it will wait for at least as long as the checkAfter value before sending another pollReq.
3. 如果EE收到一个pollRep，它将在发送另一个pollReq之前等待至少与checkAfter值相同的时间。
4. If an ip, cp, or kup is received in response to a pollReq, then it will be treated in the same way as the initial response.
4. 如果接收到ip、cp或kup以响应pollReq，则将以与初始响应相同的方式对其进行处理。
START
|
v
Send ir
| ip
v
Check status
of returned <------------------------+
certs |
| |
+------------------------>|<------------------+ |
| | | |
| (issued) v (waiting) | |
Add to <----------- Check CertResponse ------> Add to |
conf list for each certificate pending list |
/ |
/ |
(conf list) / (empty conf list) |
/ ip |
/ +----------------+
(empty pending list) / | pRep
END <---- Send certConf Send pReq------------>Wait
| ^ ^ |
| | | |
+-----------------+ +---------------+
(pending list)
START
|
v
Send ir
| ip
v
Check status
of returned <------------------------+
certs |
| |
+------------------------>|<------------------+ |
| | | |
| (issued) v (waiting) | |
Add to <----------- Check CertResponse ------> Add to |
conf list for each certificate pending list |
/ |
/ |
(conf list) / (empty conf list) |
/ ip |
/ +----------------+
(empty pending list) / | pRep
END <---- Send certConf Send pReq------------>Wait
| ^ ^ |
| | | |
+-----------------+ +---------------+
(pending list)
In the following exchange, the end entity is enrolling for two certificates in one request.
在以下交换中，终端实体在一个请求中注册两个证书。
Step End Entity PKI
--------------------------------------------------------------------
1 Format ir
2 -> ir ->
3 Handle ir
4 Manual intervention is
required for both certs.
5 <- ip <-
6 Process ip
7 Format pReq
8 -> pReq ->
9 Check status of cert requests
10 Certificates not ready
11 Format pRep
12 <- pRep <-
13 Wait
14 Format pReq
15 -> pReq ->
16 Check status of cert requests
17 One certificate is ready
18 Format ip
19 <- ip <-
20 Handle ip
21 Format certConf
22 -> certConf ->
23 Handle certConf
24 Format ack
25 <- pkiConf <-
26 Format pReq
27 -> pReq ->
28 Check status of certificate
29 Certificate is ready
30 Format ip
31 <- ip <-
31 Handle ip
32 Format certConf
33 -> certConf ->
34 Handle certConf
35 Format ack
36 <- pkiConf <-
Step End Entity PKI
--------------------------------------------------------------------
1 Format ir
2 -> ir ->
3 Handle ir
4 Manual intervention is
required for both certs.
5 <- ip <-
6 Process ip
7 Format pReq
8 -> pReq ->
9 Check status of cert requests
10 Certificates not ready
11 Format pRep
12 <- pRep <-
13 Wait
14 Format pReq
15 -> pReq ->
16 Check status of cert requests
17 One certificate is ready
18 Format ip
19 <- ip <-
20 Handle ip
21 Format certConf
22 -> certConf ->
23 Handle certConf
24 Format ack
25 <- pkiConf <-
26 Format pReq
27 -> pReq ->
28 Check status of certificate
29 Certificate is ready
30 Format ip
31 <- ip <-
31 Handle ip
32 Format certConf
33 -> certConf ->
34 Handle certConf
35 Format ack
36 <- pkiConf <-
Some of the PKI management functions outlined in Section 3.1 above are described in this section.
本节介绍了上文第3.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. This part is effectively the profile of the PKI management functionality that MUST be supported. Note, however, that the management functions described in this section do not need to be accomplished using the PKI messages defined in Section 5 if alternate means are suitable for a given environment (see Appendix D for profiles of the PKIMessages that MUST be supported).
本节讨论“强制性”功能，即所有终端实体和CA/RA实现必须能够提供所述功能。这一部分实际上是必须支持的PKI管理功能的概要。但是，请注意，如果替代方法适用于给定环境，则不需要使用第5节中定义的PKI消息来完成本节中描述的管理功能（必须支持的PKI消息的配置文件见附录D）。
[See Section 3.1.1.2 for this document's definition of "root CA".]
[本文件对“根CA”的定义见第3.1.1.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 certificate. 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 4.4.1) MAY be 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（见第4.4.1节），以帮助持有当前自签名CA证书（OldWithOld）的现有终端实体安全地过渡到新自签名CA证书（NewWithNew），并帮助持有NewWithNew的新终端实体安全地获取OldWithOld，以验证现有数据。
[See Section 3.1.1.2 for this document's definition of "subordinate CA".]
[参见第3.1.1.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 are 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 using any other authenticated means (if the end entity has an existing certificate).
如果使用PKI消息请求和提供此PKI信息，则请求必须是GenMsg消息，响应必须是GenRep消息，错误必须是错误消息。这些消息使用基于共享秘密信息的MAC（即PasswordBasedMAC）或使用任何其他经过身份验证的手段（如果终端实体具有现有证书）进行保护。
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必须“启动并运行”。
6.6.1. One-Way Request-Response Scheme:
6.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. (Authentication may alternatively be done using signatures instead of MACs, if the CAs are able to retrieve and validate the required public keys by some means, such as an out-of-band hash comparison.)
授权代码用于身份验证和完整性目的。这是通过基于授权码生成对称密钥并使用对称密钥在所有交换的消息上生成消息身份验证码（MAC）来实现的。（如果CA能够通过某种方式（例如带外散列比较）检索和验证所需的公钥，则也可以使用签名而不是MAC进行身份验证。）
The requester CA initiates the exchange by generating a cross-certification request (ccr) with a fresh random number (requester random number). The requester CA then sends the ccr message to the responder CA. The fields in this message are protected from modification with a MAC based on the authorization code.
请求者CA通过使用新的随机数（请求者随机数）生成交叉认证请求（ccr）来发起交换。然后，请求者CA将ccr消息发送给响应者CA。此消息中的字段将受到保护，不受基于授权代码的MAC的修改。
Upon receipt of the ccr message, the responder CA validates the message and the MAC, saves the requester random number, and generates its own random number (responder random number). It then 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.
收到ccr消息后，响应者CA验证消息和MAC，保存请求者随机数，并生成自己的随机数（响应者随机数）。然后，它生成（并存档，如果需要）一个新的请求者证书，该证书包含请求者CA公钥，并使用响应者CA签名私钥进行签名。响应者CA使用交叉认证响应（ccp）消息进行响应。此消息中的字段受保护，不受基于授权代码的MAC的修改。
Upon receipt of the ccp message, the requester CA validates the message (including the received random numbers) and the MAC. The requester CA responds with the certConf message. The fields in this message are protected from modification with a MAC based on the authorization code. The requester CA MAY write the requester certificate to the Repository as an aid to later certificate path construction.
在接收到ccp消息后，请求者CA验证消息（包括接收到的随机数）和MAC。请求者CA使用certConf消息进行响应。此消息中的字段受保护，不受基于授权代码的MAC的修改。请求者CA可以将请求者证书写入存储库，以帮助以后的证书路径构建。
Upon receipt of the certConf message, the responder CA validates the message and the MAC, and sends back an acknowledgement using the PKIConfirm message. It MAY also publish the requester certificate as an aid to later path construction.
收到certConf消息后，响应者CA验证消息和MAC，并使用PKIConfirm消息发回确认。它还可以发布请求者证书，以帮助以后构建路径。
Notes:
笔记：
1. The ccr message must contain a "complete" certification request; that is, all fields except the serial number (including, e.g., a BasicConstraints extension) must be specified by the requester CA.
1. ccr消息必须包含“完整”的认证请求；也就是说，除了序列号之外的所有字段（包括，例如，BasicConstraints扩展名）都必须由请求者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).
2. ccp消息应包含响应方CA的验证证书；如果存在，请求者CA必须验证该证书（例如，通过“带外”机制）。
(A simpler, non-interactive model of cross-certification may also be envisioned, in which the issuing CA acquires the subject CA's public key from some repository, verifies it via some out-of-band mechanism, and creates and publishes the cross-certificate without the subject CA's explicit involvement. This model may be perfectly legitimate for many environments, but since it does not require any protocol message exchanges, its detailed description is outside the scope of this specification.)
（还可以设想一个更简单、非交互式的交叉认证模型，其中颁发CA从某个存储库获取主体CA的公钥，通过带外机制进行验证，并在主体CA未明确参与的情况下创建和发布交叉证书。该模型对人来说可能是完全合法的。）y环境，但由于它不需要任何协议消息交换，其详细描述不在本规范的范围内。）
As with CAs, end entities must be initialized. Initialization of end entities requires at least two steps:
与CAs一样，必须初始化终端实体。终端实体的初始化至少需要两个步骤：
o acquisition of PKI information
o 获取PKI信息
o out-of-band verification of one root-CA public key
o 一个根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:
所需资料如下：
o the current root-CA public key
o 当前根CA公钥
o (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
o （如果认证CA不是根CA）从根CA到认证CA的认证路径以及适当的撤销列表
o the algorithms and algorithm parameters that the certifying CA supports for each relevant usage
o 认证CA为每个相关用途支持的算法和算法参数
Additional information could be required (e.g., supported extensions or CA policy information) in order to produce a certification request that 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 6.5.
可按照第6.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 6.1 for further details.
详见第6.1节。
An initialized end entity MAY request an additional certificate at any time (for any 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 (or, in certain circumstances, a new certificate for the same key pair). The request is made using a key update request (kur) message (referred to, in some environments, as a "Certificate Update" operation). 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相同。
This section defines the version negotiation used to support older protocols between client and servers.
本节定义了用于支持客户端和服务器之间的旧协议的版本协商。
If a client knows the protocol version(s) supported by the server (e.g., from a previous PKIMessage exchange or via some out-of-band means), then it MUST send a PKIMessage with the highest version supported by both it and the server. If a client does not know what version(s) the server supports, then it MUST send a PKIMessage using the highest version it supports.
如果客户端知道服务器支持的协议版本（例如，从以前的PKI消息交换或通过一些带外方式），则它必须发送具有其和服务器都支持的最高版本的PKI消息。如果客户端不知道服务器支持的版本，则必须使用其支持的最高版本发送PKI消息。
If a server receives a message with a version that it supports, then the version of the response message MUST be the same as the received version. If a server receives a message with a version higher or lower than it supports, then it MUST send back an ErrorMsg with the unsupportedVersion bit set (in the failureInfo field of the pKIStatusInfo). If the received version is higher than the highest supported version, then the version in the error message MUST be the highest version the server supports; if the received version is lower than the lowest supported version then the version in the error message MUST be the lowest version the server supports.
如果服务器接收到具有其支持的版本的消息，则响应消息的版本必须与接收到的版本相同。如果服务器收到的消息版本高于或低于其支持的版本，则必须发送回设置了unsupportedVersion位的ErrorMsg（在pKIStatusInfo的failureInfo字段中）。如果收到的版本高于支持的最高版本，则错误消息中的版本必须是服务器支持的最高版本；如果收到的版本低于支持的最低版本，则错误消息中的版本必须是服务器支持的最低版本。
If a client gets back an ErrorMsgContent with the unsupportedVersion bit set and a version it supports, then it MAY retry the request with that version.
如果客户机返回带有unsupportedVersion位集的ErrorMsgContent及其支持的版本，则可能会使用该版本重试请求。
RFC 2510 did not specify the behaviour of implementations receiving versions they did not understand since there was only one version in existence. With the introduction of the present revision of the specification, the following versioning behaviour is recommended.
RFC2510没有指定接收他们不了解的版本的实现的行为，因为只有一个版本存在。随着本规范当前版本的介绍，建议采用以下版本控制行为。
If, after sending a cmp2000 message, a client receives an ErrorMsgContent with a version of cmp1999, then it MUST abort the current transaction. It MAY subsequently retry the transaction using version cmp1999 messages.
如果在发送cmp2000消息后，客户端收到带有cmp1999版本的ErrorMsgContent，则必须中止当前事务。随后，它可能会使用cmp1999版本消息重试事务。
If a client receives a non-error PKIMessage with a version of cmp1999, then it MAY decide to continue the transaction (if the transaction hasn't finished) using RFC 2510 semantics. If it does not choose to do so and the transaction is not finished, then it MUST abort the transaction and send an ErrorMsgContent with a version of cmp1999.
如果客户端收到cmp1999版本的非错误消息，则它可能决定使用RFC2510语义继续事务（如果事务尚未完成）。如果它不选择这样做，并且事务未完成，则它必须中止事务并发送一个带有cmp1999版本的ErrorMsgContent。
If a server receives a version cmp1999 message it MAY revert to RFC 2510 behaviour and respond with version cmp1999 messages. If it does not choose to do so, then it MUST send back an ErrorMsgContent as described above in Section 7.
如果服务器收到版本cmp1999消息，它可能会恢复到RFC 2510行为，并用版本cmp1999消息进行响应。如果它不选择这样做，那么它必须发回一个ErrorMsgContent，如上文第7节所述。
Some cryptographic considerations are 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:
还请注意，将私钥公开给CA/RA作为占有证明技术可能会带来一些安全风险（取决于CA/RA是否可以被信任来适当处理此类材料）。建议实施者：
Exercise caution in selecting and using this particular POP mechanism
在选择和使用这种特殊的POP机制时要小心
When appropriate, have the user of the application explicitly state that they are willing to trust the CA/RA to have a copy of their private key before proceeding to reveal the private key.
在适当的情况下，让应用程序的用户明确声明，他们愿意信任CA/RA拥有其私钥的副本，然后再继续公开私钥。
A small subgroup attack during a Diffie-Hellman key exchange may be carried out as follows. A malicious end entity may deliberately choose D-H parameters that enable him/her to derive (a significant number of bits of) the D-H private key of the CA during a key archival or key recovery operation. Armed with this knowledge, the
Diffie-Hellman密钥交换过程中的小子组攻击可执行如下操作。恶意终端实体可能故意选择D-H参数，使其能够在密钥存档或密钥恢复操作期间导出CA的D-H私钥（大量比特）。有了这方面的知识
EE would then be able to retrieve the decryption private key of another unsuspecting end entity, EE2, during EE2's legitimate key archival or key recovery operation with that CA. In order to avoid the possibility of such an attack, two courses of action are available. (1) The CA may generate a fresh D-H key pair to be used as a protocol encryption key pair for each EE with which it
然后，在EE2的合法密钥存档或与该CA的密钥恢复操作期间，EE将能够检索到另一个未被怀疑的终端实体EE2的解密私钥。为了避免此类攻击的可能性，有两种方法可用。（1） CA可以生成一个新的D-H密钥对，以用作它所使用的每个EE的协议加密密钥对
interacts. (2) The CA may enter into a key validation protocol (not specified in this document) with each requesting end entity to ensure that the EE's protocol encryption key pair will not facilitate this attack. Option (1) is clearly simpler (requiring no extra protocol exchanges from either party) and is therefore RECOMMENDED.
互动。（2） CA可以与每个请求的终端实体签订密钥验证协议（本文档中未指定），以确保EE的协议加密密钥对不会助长此攻击。选项（1）显然更简单（不需要任何一方进行额外的协议交换），因此建议使用。
The PKI General Message types are identified by object identifiers (OIDs). The OIDs for the PKI General Message types defined in this document were assigned from an arc delegated by the IANA to the PKIX Working Group.
PKI通用消息类型由对象标识符（OID）标识。本文件中定义的PKI通用消息类型的OID由IANA委托给PKIX工作组的arc分配。
The cryptographic algorithms referred to in this document are identified by object identifiers (OIDs). The OIDs for cryptographic algorithms were assigned from several arcs owned by various organizations, including RSA Security, Entrust Technologies, IANA and IETF.
本文档中提到的加密算法由对象标识符（OID）标识。加密算法的OID是从多个组织拥有的ARC分配的，包括RSA Security、Trust Technologies、IANA和IETF。
Should additional encryption algorithms be introduced, the advocates for such algorithms are expected to assign the necessary OIDs from their own arcs.
如果引入额外的加密算法，这些算法的拥护者将从他们自己的弧中分配必要的OID。
No further action by the IANA is necessary for this document or any anticipated updates.
IANA无需对本文件或任何预期更新采取进一步行动。
Normative References
规范性引用文件
[X509] International Organization for Standardization and International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ISO Standard 9594-8:2001, ITU-T Recommendation X.509, March 2000.
[X509]国际标准化组织和国际电信联盟，“信息技术-开放系统互连-目录：公钥和属性证书框架”，ISO标准9594-8:2001，ITU-T建议X.509，2000年3月。
[MvOV97] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook of Applied Cryptography", CRC Press ISBN 0-8493-8523-7, 1996.
[MvOV97]Menezes，A.，van Oorschot，P.和S.Vanstone，“应用密码学手册”，CRC出版社ISBN 0-8493-8523-71996。
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode Plain Text", RFC 2482, January 1999.
[RFC2482]Whistler，K.和G.Adams，“Unicode纯文本中的语言标记”，RFC2482，1999年1月。
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[CRMF]Schaad，J.，“Internet X.509公钥基础设施证书请求消息格式（CRMF）”，RFC 4211，2005年9月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
Informative References
资料性引用
[CMPtrans] Kapoor, A., Tschalar, R. and T. Kause, "Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP", Work in Progress. 2004.
[CMPtrans]Kapoor，A.，Tchalar，R.和T.Kause，“互联网X.509公钥基础设施——CMP的传输协议”，正在进行中。2004
[PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards - Cryptographic Message Syntax Standard. Version 1.5", PKCS 7, November 1993.
[PKCS7]RSA实验室，“公钥加密标准-加密消息语法标准，1.5版”，PKCS7，1993年11月。
[PKCS10] Nystrom, M., and B. Kaliski, "The Public-Key Cryptography Standards - Certification Request Syntax Standard, Version 1.7", RFC 2986, May 2000.
[PKCS10]Nystrom，M.和B.Kaliski，“公钥加密标准-认证请求语法标准，版本1.7”，RFC 2986，2000年5月。
[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - Cryptographic Token Interface Standard. Version 2.10", PKCS 11, December 1999.
[PKCS11]RSA实验室，“公钥加密标准-加密令牌接口标准，版本2.10”，PKCS11，1999年12月。
[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月。
[RFC2559] Boeyen, S., Howes, T. and P. Richard, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999.
[RFC2559]Boeyen，S.，Howes，T.和P.Richard，“互联网X.509公钥基础设施操作协议-LDAPv2”，RFC 2559，1999年4月。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC2585]Housley，R.和P.Hoffman，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年5月。
[FIPS-180] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, May 1994.
[FIPS-180]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-1，1994年5月。
[FIPS-186] National Institute of Standards and Technology, "Digital Signature Standard", FIPS PUB 186, May 1994.
[FIPS-186]国家标准与技术研究所，“数字签名标准”，FIPS PUB 186，1994年5月。
[ANSI-X9.42] American National Standards Institute, "Public Key Cryptography for The Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", ANSI X9.42, February 2000.
[ANSI-X9.42]美国国家标准协会，“金融服务业的公钥加密：使用离散对数加密的对称密钥协议”，ANSI X9.42，2000年2月。
The reasons that justify the presence of an RA can be split into those that are due to technical factors and those which are organizational in nature. Technical reasons include the following.
证明RA存在的原因可分为技术因素和组织性质的原因。技术原因包括以下几点。
o 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).
o 如果正在使用硬件令牌，则并非所有终端实体都将拥有初始化这些令牌所需的设备；RA设备可包括必要的功能（这也可能是政策问题）。
o Some end entities may not have the capability to publish certificates; again, the RA may be suitably placed for this.
o 某些终端实体可能没有发布证书的能力；同样，可以为此适当地放置RA。
o 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).
o RA将能够代表与其关联的终端实体发出签名撤销请求，而终端实体可能无法这样做（如果密钥对完全丢失）。
Some of the organizational reasons that argue for the presence of an RA are the following.
支持RA存在的一些组织原因如下。
o 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).
o 将功能集中在RA设备中可能比向所有终端实体提供功能更具成本效益（特别是在使用特殊令牌初始化设备的情况下）。
o Establishing RAs within an organization can reduce the number of CAs required, which is sometimes desirable.
o 在组织内建立RAs可以减少所需的CA数量，这有时是可取的。
o RAs may be better placed to identify people with their "electronic" names, especially if the CA is physically remote from the end entity.
o RAs可能更适合于用其“电子”名称来识别人，尤其是当CA与最终实体的物理距离较远时。
o 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).
o 对于许多应用程序，已经有了一些管理结构，以便很容易找到RA角色的候选人（CA可能不是这样）。
A revocation request must incorporate suitable security mechanisms, including proper authentication, in order to reduce the probability of successful denial-of-service attacks. A digital signature on the request -- MANDATORY to support within this specification if revocation requests are supported -- can provide the authentication required, but there are circumstances under which an alternative mechanism may be desirable (e.g., when the private key is no longer accessible and the entity wishes to request a revocation prior to re-certification of another key pair). In order to accommodate such
撤销请求必须包含适当的安全机制，包括适当的身份验证，以降低成功拒绝服务攻击的概率。请求上的数字签名（如果支持撤销请求，则在本规范中必须支持数字签名）可以提供所需的身份验证，但在某些情况下，可能需要另一种机制（例如，当私钥不再可访问且实体希望在重新认证另一密钥对之前请求撤销时）。为了适应这种情况
circumstances, a PasswordBasedMAC on the request is also MANDATORY to support within this specification (subject to local security policy for a given environment) if revocation requests are supported and if shared secret information can be established between the requester and the responder prior to the need for revocation.
在这种情况下，如果支持撤销请求，并且在需要撤销之前可以在请求者和响应者之间建立共享秘密信息，则请求中基于密码的DMAC也必须在本规范中提供支持（根据给定环境的本地安全策略）。
A mechanism that has seen use in some environments is "revocation passphrase", in which a value of sufficient entropy (i.e., a relatively long passphrase rather than a short password) is shared between (only) the entity and the CA/RA at some point prior to revocation; this value is later used to authenticate the revocation request.
在某些环境中使用的一种机制是“撤销密码短语”，其中在撤销之前的某个点，实体和CA/RA之间（仅）共享足够熵的值（即，相对较长的密码短语而不是较短的密码）；此值稍后用于验证吊销请求。
In this specification, the following technique to establish shared secret information (i.e., a revocation passphrase) is OPTIONAL to support. Its precise use in CMP messages is as follows.
在本规范中，以下用于建立共享秘密信息（即撤销密码短语）的技术是可选的。它在CMP消息中的精确用法如下。
o The OID and value specified in Section 5.3.19.9 MAY be sent in a GenMsg message at any time, or MAY be sent in the generalInfo field of the PKIHeader of any PKIMessage at any time. (In particular, the EncryptedValue may be sent in the header of the certConf message that confirms acceptance of certificates requested in an initialization request or certificate request message.) This conveys a revocation passphrase chosen by the entity (i.e., the decrypted bytes of the encValue field) to the relevant CA/RA; furthermore, the transfer is accomplished with appropriate confidentiality characteristics (because the passphrase is encrypted under the CA/RA's protocolEncryptionKey).
o 第5.3.19.9节中规定的OID和值可以随时在GenMsg消息中发送，也可以随时在任何PKI消息的PKI头的generalInfo字段中发送。（特别是，可在certConf消息头中发送EncryptedValue，该消息确认接受初始化请求或证书请求消息中请求的证书。）这将实体选择的撤销密码短语（即encValue字段的解密字节）传送到相关CA/RA；此外，传输以适当的保密特性完成（因为密码短语在CA/RA的protocolEncryptionKey下加密）。
o If a CA/RA receives the revocation passphrase (OID and value specified in Section 5.3.19.9) in a GenMsg, it MUST construct and send a GenRep message that includes the OID (with absent value) specified in Section 5.3.19.9. If the CA/RA receives the revocation passphrase in the generalInfo field of a PKIHeader of any PKIMessage, it MUST include the OID (with absent value) in the generalInfo field of the PKIHeader of the corresponding response PKIMessage. If the CA/RA is unable to return the appropriate response message for any reason, it MUST send an error message with a status of "rejection" and, optionally, a failInfo reason set.
o 如果CA/RA在GenMsg中接收到撤销密码短语（OID和第5.3.19.9节中指定的值），则必须构造并发送包含第5.3.19.9节中指定OID（缺少值）的GenRep消息。如果CA/RA在任何PKI消息的PKI头的generalInfo字段中接收到吊销密码短语，则必须在相应响应PKI消息的PKI头的generalInfo字段中包含OID（缺少值）。如果CA/RA由于任何原因无法返回相应的响应消息，则必须发送一条状态为“拒绝”的错误消息，并且可以选择发送一个failInfo原因集。
o The valueHint field of EncryptedValue MAY contain a key identifier (chosen by the entity, along with the passphrase itself) to assist in later retrieval of the correct passphrase (e.g., when the revocation request is constructed by the entity and received by the CA/RA).
o EncryptedValue的valueHint字段可能包含密钥标识符（由实体选择，以及密码短语本身），以帮助以后检索正确的密码短语（例如，当撤销请求由实体构造并由CA/RA接收时）。
o The revocation request message is protected by a PasswordBasedMAC, with the revocation passphrase as the key. If appropriate, the senderKID field in the PKIHeader MAY contain the value previously transmitted in valueHint.
o 撤销请求消息由PasswordBasedMAC保护，撤销密码短语作为密钥。如果合适，PKI标头中的senderKID字段可能包含先前在valueHint中传输的值。
Using the technique specified above, the revocation passphrase may be initially established and updated at any time without requiring extra messages or out-of-band exchanges. For example, the revocation request message itself (protected and authenticated through a MAC that uses the revocation passphrase as a key) may contain, in the PKIHeader, a new revocation passphrase to be used for authenticating future revocation requests for any of the entity's other certificates. In some environments this may be preferable to mechanisms that reveal the passphrase in the revocation request message, since this can allow a denial-of-service attack in which the revealed passphrase is used by an unauthorized third party to authenticate revocation requests on the entity's other certificates. However, because the passphrase is not revealed in the request message, there is no requirement that the passphrase must always be updated when a revocation request is made (that is, the same passphrase MAY be used by an entity to authenticate revocation requests for different certificates at different times).
使用上面指定的技术，可以在不需要额外消息或带外交换的情况下在任何时候初始建立和更新撤销密码短语。例如，撤销请求消息本身（通过使用撤销密码短语作为密钥的MAC进行保护和认证）可以在pki报头中包含新的撤销密码短语，用于认证实体的任何其他证书的未来撤销请求。在某些环境中，这可能比在撤销请求消息中显示密码短语的机制更可取，因为这可能允许拒绝服务攻击，其中未经授权的第三方使用显示的密码短语对实体的其他证书上的撤销请求进行认证。但是，由于请求消息中未显示密码短语，因此不要求在发出撤销请求时始终更新密码短语（即，实体可以使用相同的密码短语在不同时间对不同证书的撤销请求进行身份验证）。
Furthermore, the above technique can provide strong cryptographic protection over the entire revocation request message even when a digital signature is not used. Techniques that do authentication of the revocation request by simply revealing the revocation passphrase typically do not provide cryptographic protection over the fields of the request message (so that a request for revocation of one certificate may be modified by an unauthorized third party to a request for revocation of another certificate for that entity).
此外，即使在不使用数字签名的情况下，上述技术也可以对整个撤销请求消息提供强大的密码保护。通过简单地显示撤销密码短语对撤销请求进行身份验证的技术通常不会对请求消息的字段提供加密保护（因此，未经授权的第三方可将撤销一份证书的请求修改为撤销该实体的另一份证书的请求）。
In the case of updates to [CRMF], which cause interpretation or interoperability issues, [CRMF] SHALL be the normative document.
如果[CRMF]的更新导致解释或互操作性问题，则[CRMF]应为规范性文件。
The following definitions are from [CRMF]. They are included here in order to codify behavioral clarifications to that request message; otherwise, all syntax and semantics are identical to [CRMF].
以下定义来自[CRMF]。它们包含在这里是为了对请求消息进行行为澄清；否则，所有语法和语义都与[CRMF]相同。
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
-- If certTemplate is an empty SEQUENCE (i.e., all fields
-- omitted), then controls MAY contain the
-- If certTemplate is an empty SEQUENCE (i.e., all fields
-- omitted), then controls MAY contain the
-- id-regCtrl-altCertTemplate control, specifying a template
-- for a certificate other than an X.509v3 public-key
-- certificate. Conversely, if certTemplate is not empty
-- (i.e., at least one field is present), then controls MUST
-- NOT contain id-regCtrl- altCertTemplate. The new control is
-- defined as follows:
-- id-regCtrl-altCertTemplate control, specifying a template
-- for a certificate other than an X.509v3 public-key
-- certificate. Conversely, if certTemplate is not empty
-- (i.e., at least one field is present), then controls MUST
-- NOT contain id-regCtrl- altCertTemplate. The new control is
-- defined as follows:
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- **********
-- * For the purposes of this specification, the ASN.1 comment
-- * given in [CRMF] pertains not only to certTemplate, but
-- * also to the altCertTemplate control. That is,
-- **********
-- * The signature (using "algorithmIdentifier") is on the
-- * DER-encoded value of poposkInput (i.e., the "value" OCTETs
-- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg
-- * certReq certTemplate (or the altCertTemplate control)
-- * contains the subject and publicKey values, then poposkInput
-- * MUST be omitted and the signature MUST be computed on the
-- * DER-encoded value of CertReqMsg certReq (or the DER-
-- * encoded value of AltCertTemplate). If
-- * certTemplate/altCertTemplate does not contain both the
-- * subject and public key values (i.e., if it contains only
-- * one of these, or neither), then poposkInput MUST be present
-- * and MUST be signed.
-- **********
-- **********
-- * For the purposes of this specification, the ASN.1 comment
-- * given in [CRMF] pertains not only to certTemplate, but
-- * also to the altCertTemplate control. That is,
-- **********
-- * The signature (using "algorithmIdentifier") is on the
-- * DER-encoded value of poposkInput (i.e., the "value" OCTETs
-- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg
-- * certReq certTemplate (or the altCertTemplate control)
-- * contains the subject and publicKey values, then poposkInput
-- * MUST be omitted and the signature MUST be computed on the
-- * DER-encoded value of CertReqMsg certReq (or the DER-
-- * encoded value of AltCertTemplate). If
-- * certTemplate/altCertTemplate does not contain both the
-- * subject and public key values (i.e., if it contains only
-- * one of these, or neither), then poposkInput MUST be present
-- * and MUST be signed.
-- **********
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- **********
-- * the type of "thisMessage" is given as BIT STRING in
-- * [CRMF]; it should be "EncryptedValue" (in accordance
-- * with Section 5.2.2, "Encrypted Values", of this specification).
-- * Therefore, this document makes the behavioral clarification
-- * of specifying that the contents of "thisMessage" MUST be encoded
-- * as an EncryptedValue and then wrapped in a BIT STRING. This
-- * allows the necessary conveyance and protection of the
-- * private key while maintaining bits-on-the-wire compatibility
-- * with [CRMF].
-- **********
-- **********
-- * the type of "thisMessage" is given as BIT STRING in
-- * [CRMF]; it should be "EncryptedValue" (in accordance
-- * with Section 5.2.2, "Encrypted Values", of this specification).
-- * Therefore, this document makes the behavioral clarification
-- * of specifying that the contents of "thisMessage" MUST be encoded
-- * as an EncryptedValue and then wrapped in a BIT STRING. This
-- * allows the necessary conveyance and protection of the
-- * private key while maintaining bits-on-the-wire compatibility
-- * with [CRMF].
-- **********
subsequentMessage [1] SubsequentMessage, dhMAC [2] BIT STRING }
subsequentMessage[1]subsequentMessage，dhMAC[2]位字符串}
Appendix D. PKI Management Message Profiles (REQUIRED).
附录D.PKI管理消息配置文件（必需）。
This appendix contains detailed profiles for those PKIMessages that MUST be supported by conforming implementations (see Section 6).
本附录包含必须由一致性实施支持的PKI消息的详细概要（见第6节）。
Profiles for the PKIMessages used in the following PKI management operations are provided:
提供了用于以下PKI管理操作的PKI消息的配置文件：
o initial registration/certification
o 初次登记/核证
o basic authenticated scheme
o 基本认证方案
o certificate request
o 证书申请
o key update
o 密钥更新
D.1. General Rules for Interpretation of These Profiles.
D.1. 解释这些剖面的一般规则。
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., in this version of the specification, pvno is always 2).
1. 如果个别概要文件中未提及可选或默认字段，则相关消息中应不包含这些字段（即，接收方可以有效地拒绝包含语法不正确字段的消息）。如果必填字段具有明显的值（例如，在此版本的规范中，pvno始终为2），则不会提及它们。
2. Where structures occur in more than one message, they are separately profiled as appropriate.
2. 如果结构出现在多条消息中，则会根据需要单独分析它们。
3. The algorithmIdentifiers from PKIMessage structures are profiled separately.
3. PKI消息结构中的算法标识符分别进行了分析。
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).
4. “特殊”X.500 DN称为“空DN”；这意味着一个DN包含一个长度为零的RelativeDistinguishedNames序列（其DER编码为'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".
5. 如果字段需要GeneralName，但没有合适的值可用（例如，终端实体在知道其名称之前生成请求），则GeneralName应为X.500 NULL-DN（即，所选名称字段包含NULL-DN）。此特殊值可以称为“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.
6. 如果配置文件忽略指定GeneralName的值，则相关PKIMessage字段中会出现NULL 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).
7. 如果由于字段命名而产生任何歧义，配置文件将使用“点”符号命名这些字段（例如，“certTemplate.subject”表示名为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).
8. 如果“类型序列”是消息的一部分，则使用基于零的数组表示法来描述序列中的字段（例如，crm[0]。certReq.certTemplate.subject指请求消息中包含的第一个CertReqMsg的子字段）。
9. All PKI message exchanges in Appendix D.4 to D.6 require a certConf message to be sent by the initiating entity and a PKIConfirm to be sent by the responding entity. The PKIConfirm 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).
9. 附录D.4至D.6中的所有PKI消息交换要求发起实体发送certConf消息，响应实体发送PKI确认消息。PKIConfirm不包括在某些给定的配置文件中，因为它的主体为NULL，并且它的头内容从上下文中清除。任何经过身份验证的方法都可以用于protectionAlg（例如，如果共享秘密信息已知，则基于密码的MAC，或签名）。
The following table contains definitions of algorithm uses within PKI management protocols. The columns in the table are:
下表包含PKI管理协议中使用的算法定义。表中的列为：
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 ECDSA, ... MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC, messages using MACing X9.9... SYM_PENC_ALG symmetric encryption of 3-DES (3-key- AES,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 ECDH, ... (symmetric keys for encryption of) private keys transported in
MSG_SIG_ALG保护PKI DSA/SHA-1 RSA/MD5，使用签名ECDSA的消息。。。MSG_MAC_ALG保护基于PKI密码的DMAC HMAC，使用MACing X9.9的消息。。。对称加密3-DES（3-key-AES，RC5，终端实体的私有EDE，CBC模式）CAST-128。。。对称密钥分发到带外保护的密钥非对称算法D-H RSA，用于ECDH的加密。。。（用于加密的对称密钥）传入的私钥
PKIMessages PROT_SYM_ALG symmetric encryption 3-DES (3-key- AES,RC5, algorithm used for EDE, CBC mode) CAST-128... encryption of private key bits (a key of this type is encrypted using PROT_ENC_ALG)
PKI消息保护对称加密3-DES（3-key-AES，RC5，用于EDE的算法，CBC模式）CAST-128。。。私钥位加密（此类密钥使用PROT_ENC_ALG加密）
Mandatory AlgorithmIdentifiers and Specifications:
强制性算法标识符和规范：
DSA/SHA-1:
AlgId: {1 2 840 10040 4 3};
DSA/SHA-1:
AlgId: {1 2 840 10040 4 3};
Digital Signature Standard [FIPS-186]
数字签名标准[FIPS-186]
Public Modulus size: 1024 bits.
公共模数大小：1024位。
PasswordBasedMac:
PasswordBasedMac：
AlgId: {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;
AlgId: {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
（本规范），以及
Secure Hash Standard [FIPS-180] and [RFC2104]
安全散列标准[FIPS-180]和[RFC2104]
HMAC key size: 160 bits (i.e., "K" = "H" in Section 5.1.3.1, "Shared secret information")
HMAC密钥大小：160位（即第5.1.3.1节“共享秘密信息”中的“K”=“H”）
3-DES:
3-DES：
AlgId: {1 2 840 113549 3 7}; (used in RSA's BSAFE and in S/MIME).
阿尔及德：{1 2 840 113549 3 7}；（在RSA的BSAFE和s/MIME中使用）。
D-H:
D-H：
AlgId: {1 2 840 10046 2 1};
AlgId: {1 2 840 10046 2 1};
[ANSI-X9.42]
[ANSI-X9.42]
Public Modulus Size: 1024 bits.
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g^q = 1 mod p
q INTEGER, -- prime factor of p-1
j INTEGER OPTIONAL, -- cofactor, j>=2
validationParms ValidationParms OPTIONAL
Public Modulus Size: 1024 bits.
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g^q = 1 mod p
q INTEGER, -- prime factor of p-1
j INTEGER OPTIONAL, -- cofactor, j>=2
validationParms ValidationParms OPTIONAL
}
ValidationParms ::= SEQUENCE {
seed BIT STRING, -- seed for prime generation
pGenCounter INTEGER -- parameter verification
}
}
ValidationParms ::= SEQUENCE {
seed BIT STRING, -- seed for prime generation
pGenCounter INTEGER -- parameter verification
}
POP fields for use (in signature field of pop field of ProofOfPossession structure) when proving possession of a private signing key that 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
此证明只允许算法标识符MSG_SIG_ALG签名保护
signature present bits calculated using MSG_SIG_ALG
使用MSG_SIG_ALG计算的签名显示位
Proof-of-possession of a private decryption key that corresponds to a public encryption key for which a certificate has been requested does not use this profile; the CertHash field of the certConf message is used instead.
拥有与已请求证书的公共加密密钥相对应的私有解密密钥的证明不使用此配置文件；改为使用certConf消息的CertHash字段。
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 that 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协议的这些组件）。
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 certificate confirmation. The CA sends a PKIConfirm back, closing the transaction. All messages are authenticated.
（未初始化的）终端实体从CA请求（第一个）证书。当CA用包含证书的消息进行响应时，终端实体用证书确认进行响应。CA发回PKI确认，关闭事务。所有消息都经过身份验证。
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
1. 终端实体可以基于带外方式对CA的签名进行身份验证
2. The end entity and the CA share a symmetric MACing key
2. 终端实体和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 certConf 8 -> certConf -> 9 handle certConf 10 format PKIConf 11 <- PKIConf <- 12 handle PKIConf
步骤#结束实体PKI 1格式ir 2->ir->3处理ir 4格式ip 5<-ip<-6处理ip 7格式certConf 8->certConf->9处理certConf 10格式PKIConf 11<-PKIConf<-12处理PKIConf
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 that 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消息（即，如果请求并支持集中密钥生成，则包括可选的第二个密钥对）。为简单起见，我们还要求此消息必须是最终消息（即，不使用“等待”状态值）。
The end entity has an out-of-band interaction with the CA/RA. This transaction established the shared secret, the referenceNumber and OPTIONALLY the distinguished name used for both sender and subject name in the certificate template. It is RECOMMENDED that the shared secret be at least 12 characters long.
终端实体与CA/RA具有带外交互。此事务在证书模板中建立了共享机密、引用编号和可选的可分辨名称（用于发送者和使用者名称）。建议共享密钥的长度至少为12个字符。
Initialization Request -- ir
初始化请求——ir
Field Value
字段值
recipient CA name
收件人CA名称
-- 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]
-- 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
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)
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 Appendix D.3 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. 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 Appendix D.3 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。可选地显示controls.publicationInfo——最终实体可能要求发布结果证书。
crm[1].certReq fixed value of one
crm[1]。certReq固定值为1
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]). Note that subjectPublicKeyInfo MAY be present
-- and contain an AlgorithmIdentifier followed by a
-- zero-length BIT STRING for the subjectPublicKey if it is
-- desired to inform the CA/RA of algorithm and parameter
-- preferences regarding the to-be-generated key pair.
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]). Note that subjectPublicKeyInfo MAY be present
-- and contain an AlgorithmIdentifier followed by a
-- zero-length BIT STRING for the subjectPublicKey if it is
-- desired to inform the CA/RA of algorithm and parameter
-- preferences regarding the to-be-generated key pair.
crm[1].certReq. present [object identifier MUST be PROT_ENC_ALG]
crm[1].certReq。存在[对象标识符必须为PROT_ENC_ALG]
controls.protocolEncrKey
-- 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
controls.protocolEncrKey
-- 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。可选显示controls.archiveOptions crm[1].certReq。可选显示controls.publicationInfo保护显示--使用MSG\u MAC\u ALG计算的位
Initialization Response -- ip
初始化响应——ip
Field Value
字段值
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
senderKID referenceNum
-- the reference number that 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
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
senderKID referenceNum
-- the reference number that 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 ip (CertRepMessage) contains exactly one response for each request
正文ip（CertRepMessage）仅包含每个请求的一个响应
-- 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
-- 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 "accepted", "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 "accepted" 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
crc[0]。状态。存在，允许正值：状态“已接受”，“grantedWithMods”允许负值：“拒绝”crc[0]。状态。当且仅当故障信息crc[0]时出现。状态。状态为“拒绝”crc[0]。当且仅当certifiedKeyPair crc[0].status.status为“accepted”或“grantedWithMods”时出现证书存在，除非最终实体的公钥是加密密钥且POP在带内exchange encryptedCert present中完成当且仅当最终实体的公钥是加密密钥且POP在带内exchange publicationInfo（可选）中完成时
-- indicates where certificate has been published (present
-- at discretion of CA)
-- 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 "accepted", "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 "accepted"
or "grantedWithMods"
certificate present
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 "accepted", "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 "accepted"
or "grantedWithMods"
certificate present
privateKey present
-- see Appendix C, Request Message Behavioral Clarifications
publicationInfo optionally present
-- indicates where certificate has been published (present
-- at discretion of CA)
privateKey present
-- see Appendix C, Request Message Behavioral Clarifications
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
protection present
-- bits calculated using MSG_MAC_ALG
extraCerts optionally present
-- the CA MAY provide additional certificates to the end
-- entity
Certificate confirm; certConf
证书确认；certConf
Field Value
字段值
sender present
-- same as in ir
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
-- 128 (pseudo-) random bits
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 shared
-- between the EE and the CA.
sender present
-- same as in ir
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
-- 128 (pseudo-) random bits
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 shared
-- between the EE and the CA.
senderKID referenceNum
-- the reference number which the CA has previously issued
-- to the end entity (together with the MACing key)
senderKID referenceNum
-- the reference number which the CA has previously issued
-- to the end entity (together with the MACing key)
body certConf
-- see Section 5.3.18, "PKI Confirmation Content", for the
-- contents of the certConf fields.
-- Note: two CertStatus structures are required if both an
-- encryption and a signing certificate were sent.
body certConf
-- see Section 5.3.18, "PKI Confirmation Content", for the
-- contents of the certConf fields.
-- Note: two CertStatus structures are required if both an
-- encryption and a signing certificate were sent.
protection present -- bits calculated using MSG_MAC_ALG
保护存在——使用MSG\u MAC\u ALG计算的位
Confirmation; PKIConf
确认书PKIConf
Field Value
字段值
sender present
-- same as in ip
recipient present
-- sender name from certConf
transactionID present
-- value from certConf message
senderNonce present
-- 128 (pseudo-) random bits
recipNonce present
-- value from senderNonce from certConf message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message.
senderKID referenceNum
body PKIConf
protection present
-- bits calculated using MSG_MAC_ALG
sender present
-- same as in ip
recipient present
-- sender name from certConf
transactionID present
-- value from certConf message
senderNonce present
-- 128 (pseudo-) random bits
recipNonce present
-- value from senderNonce from certConf message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message.
senderKID referenceNum
body PKIConf
protection present
-- bits calculated using MSG_MAC_ALG
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 certificate confirmation. The CA replies with a PKIConfirm, to close the transaction. All messages are authenticated.
（初始化的）终端实体（出于任何原因）从CA请求证书。当CA以包含证书的消息进行响应时，最终实体以证书确认进行响应。CA回复PKI确认，以关闭事务。所有消息都经过身份验证。
The profile for this exchange is identical to that given in Appendix D.4, with the following exceptions:
该交易所的情况与附录D.4中给出的情况相同，但以下情况除外：
o sender name SHOULD be present
o 发件人名称应存在
o protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY also be supported) in request, response, certConfirm, and PKIConfirm messages;
o 请求、响应、certConfirm和PKIConfirm消息中必须支持MSG_SIG_ALG的保护（也可能支持MSG_MAC_ALG）；
o senderKID and recipKID are only present if required for message verification;
o senderKID和recipKID仅在需要验证消息时出现；
o body is cr or cp;
o 身体是cr或cp；
o body may contain one or two CertReqMsg structures, but either CertReqMsg may be used to request certification of a locally-generated public key or a centrally-generated public key (i.e., the position-dependence requirement of Appendix D.4 is removed);
o 正文可能包含一个或两个CertReqMsg结构，但CertReqMsg可用于请求本地生成公钥或中央生成公钥的认证（即，删除附录D.4中的位置依赖性要求）；
o protection bits are calculated according to the protectionAlg field.
o 根据protectionAlg字段计算保护位。
An (initialized) end entity requests a certificate from a CA (to update the key pair and/or corresponding certificate that it already possesses). When the CA responds with a message containing a certificate, the end entity replies with a certificate confirmation. The CA replies with a PKIConfirm, to close the transaction. All messages are authenticated.
（初始化的）终端实体从CA请求证书（以更新其已拥有的密钥对和/或相应证书）。当CA以包含证书的消息进行响应时，最终实体以证书确认进行响应。CA回复PKI确认，以关闭事务。所有消息都经过身份验证。
The profile for this exchange is identical to that given in Appendix D.4, with the following exceptions:
该交易所的情况与附录D.4中给出的情况相同，但以下情况除外：
1. sender name SHOULD be present
1. 发件人名称应存在
2. protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY also be supported) in request, response, certConfirm, and PKIConfirm messages;
2. 请求、响应、certConfirm和PKIConfirm消息中必须支持MSG_SIG_ALG的保护（也可能支持MSG_MAC_ALG）；
3. senderKID and recipKID are only present if required for message verification;
3. senderKID和recipKID仅在需要验证消息时出现；
4. body is kur or kup;
4. 身体是库尔或库普；
5. body may contain one or two CertReqMsg structures, but either CertReqMsg may be used to request certification of a locally-generated public key or a centrally-generated public key (i.e., the position-dependence requirement of Appendix D.4 is removed);
5. 正文可能包含一个或两个CertReqMsg结构，但CertReqMsg可用于请求本地生成公钥或中央生成公钥的认证（即，删除附录D.4中的位置依赖性要求）；
6. protection bits are calculated according to the protectionAlg field;
6. 根据保护字段计算保护位；
7. regCtrl OldCertId SHOULD be used (unless it is clear to both sender and receiver -- by means not specified in this document -- that it is not needed).
7. 应使用regCtrl-OldCertId（除非发送方和接收方都清楚无需使用此文件中未指定的方法）。
Appendix E. PKI Management Message Profiles (OPTIONAL).
附录E.PKI管理消息配置文件（可选）。
This appendix contains detailed profiles for those PKIMessages that MAY be supported by implementations (in addition to the messages which MUST be supported; see Section 6 and Appendix D).
本附录包含实施可能支持的PKI消息的详细配置文件（除必须支持的消息外，请参见第6节和附录D）。
Profiles for the PKIMessages used in the following PKI management operations are provided:
提供了用于以下PKI管理操作的PKI消息的配置文件：
o root CA key update
o 根CA密钥更新
o information request/response
o 信息请求/答复
o cross-certification request/response (1-way)
o 交叉认证请求/响应（单向）
o in-band initialization using external identity certificate
o 使用外部身份证书进行带内初始化
Later versions of this document may extend the above to include profiles for the operations listed below (along with other operations, if desired).
本文档的更高版本可能会扩展上述内容，以包括下面列出的操作的配置文件（以及其他操作，如果需要）。
o revocation request
o 撤销请求
o certificate publication
o 证书发布
o CRL publication
o CRL出版物
E.1. General Rules for Interpretation of These Profiles.
E.1. 解释这些剖面的一般规则。
Identical to Appendix D.1.
与附录D.1相同。
Identical to Appendix D.2.
与附录D.2相同。
Profile of how a Certificate structure may be "self-signed". These structures are used for distribution of CA public keys. This can occur in one of three ways (see Section 4.4 above for a description of the use of these structures):
证书结构如何“自签名”的配置文件。这些结构用于CA公钥的分发。这可以通过以下三种方式之一实现（有关这些结构的使用说明，请参见上文第4.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
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
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.
此类证书（包括相关扩展名）必须包含所有字段的“合理”值。例如，当存在时，subjectAltName必须与issuerAltName相同，当存在时，KeyIdentifier必须包含适当的值，等等。
A root CA updates its key pair. It then produces a CA key update announcement message that can be made available (via some transport mechanism) to the relevant end entities. A confirmation message is NOT REQUIRED from the end entities.
根CA更新其密钥对。然后，它生成一条CA密钥更新公告消息，该消息可以（通过某种传输机制）提供给相关的终端实体。不需要来自终端实体的确认消息。
ckuann message:
ckuann消息：
Field Value Comment
--------------------------------------------------------------
sender CA name CA name
body ckuann(CAKeyUpdAnnContent)
oldWithNew present see Appendix E.3 above
newWithOld present see Appendix E.3 above
newWithNew present see Appendix E.3 above
extraCerts optionally present can be used to "publish"
certificates (e.g.,
certificates signed using
the new private key)
Field Value Comment
--------------------------------------------------------------
sender CA name CA name
body ckuann(CAKeyUpdAnnContent)
oldWithNew present see Appendix E.3 above
newWithOld present see Appendix E.3 above
newWithNew present see Appendix E.3 above
extraCerts optionally present can be used to "publish"
certificates (e.g.,
certificates signed using
the new private key)
The end entity sends a general message to the PKI requesting details that will be required for later PKI management operations. RA/CA responds with a general response. If an RA generates the response, then it will simply forward the equivalent message that it previously received from the CA, with the possible addition of certificates to the extraCerts fields of the PKIMessage. A confirmation message is NOT REQUIRED from the end entity.
最终实体向PKI发送一条常规消息，请求后续PKI管理操作所需的详细信息。RA/CA以一般响应作出响应。如果RA生成响应，那么它将简单地转发它以前从CA接收到的等效消息，并可能向PKI消息的ExterCerts字段添加证书。不需要来自最终实体的确认消息。
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
recipient CA name--issuerAltName中包含的CA名称
-- 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
-- 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)
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 that this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption/key agreement algorithm identifiers that
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm that 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
SignKeyPairTypes present, with relevant value
-- the set of signature algorithm identifiers that this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption/key agreement algorithm identifiers that
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm that 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.
-- 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.
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.
1. 响应CA可以在处理请求之前验证请求的来源（可能需要带外方式）。
2. Requesting CA can authenticate the authenticity of the origin of the response (possibly requiring out-of-band means) before processing the response
2. 请求CA可以在处理响应之前验证响应来源的真实性（可能需要带外方式）
The use of certificate confirmation and the corresponding server confirmation is determined by the generalInfo field in the PKIHeader (see Section 5.1.1). The following profile does not mandate support for either confirmation.
证书确认和相应服务器确认的使用由PKI标头中的generalInfo字段确定（见第5.1.1节）。以下配置文件不强制支持这两种确认。
Message Flows:
消息流：
Step# Requesting CA Responding CA 1 format ccr 2 -> ccr -> 3 handle ccr 4 produce ccp 5 <- ccp <- 6 handle ccp
步骤#请求CA响应CA 1格式ccr 2->ccr->3处理ccr 4生成ccp 5<-ccp<-6处理ccp
ccr:
ccr：
Field Value
字段值
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
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
recipKID 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
-- 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
recipKID 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
-- that it requires to be in the cross-certificate
POPOSigningKey present
-- see Section D3: Proof-of-possession profile
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
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
-- that it requires to be in the cross-certificate
POPOSigningKey present
-- see Section D3: Proof-of-possession profile
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
ccp:
ccp：
Field Value
字段值
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
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:
-- accepted, or
-- grantedWithMods,
-- then certifiedKeyPair MUST be present and failInfo MUST
-- be absent
PKIStatusInfo.status present
-- if PKIStatusInfo.status is one of:
-- accepted, 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
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
certifiedKeyPair是否存在取决于PKI状态信息。状态证书是否存在取决于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
-- 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
An (uninitialized) end entity wishes to initialize into the PKI with a CA, CA-1. It uses, for authentication purposes, a pre-existing identity certificate issued by another (external) CA, CA-X. A trust relationship must already have been established between CA-1 and CA-X so that CA-1 can validate the EE identity certificate signed by CA-X. Furthermore, some mechanism must already have been established within the Personal Security Environment (PSE) of the EE that would allow it to authenticate and verify PKIMessages signed by CA-1 (as one example, the PSE may contain a certificate issued for the public key of CA-1, signed by another CA that the EE trusts on the basis of out-of-band authentication techniques).
（未初始化的）终端实体希望使用CA CA-1初始化到PKI中。出于身份验证目的，它使用另一（外部）CA CA CA-X颁发的预先存在的身份证书。CA-1和CA-X之间必须已经建立了信任关系，以便CA-1可以验证CA-X签署的EE身份证书。此外，EE的个人安全环境（PSE）中必须已经建立了某种机制，允许其对CA-1签名的PKI消息进行身份验证和验证（作为一个示例，PSE可以包含为CA-1的公钥颁发的证书，该证书由EE基于带外认证技术信任的另一CA签名）。
The EE sends an initialization request to start the transaction. When CA-1 responds with a message containing the new certificate, the end entity replies with a certificate confirmation. CA-1 replies with a PKIConfirm to close the transaction. All messages are signed (the EE messages are signed using the private key that corresponds to the public key in its external identity certificate; the CA-1 messages are signed using the private key that corresponds to the public key in a
EE发送初始化请求以启动事务。当CA-1以包含新证书的消息进行响应时，最终实体以证书确认进行响应。CA-1回复PKI确认以关闭事务。对所有消息进行签名（使用与其外部身份证书中的公钥对应的私钥对EE消息进行签名；使用与外部身份证书中的公钥对应的私钥对CA-1消息进行签名）
certificate that can be chained to a trust anchor in the EE's PSE).
可以链接到EE的PSE中的信任锚点的证书）。
The profile for this exchange is identical to that given in Appendix D.4, with the following exceptions:
该交易所的情况与附录D.4中给出的情况相同，但以下情况除外：
o the EE and CA-1 do not share a symmetric MACing key (i.e., there is no out-of-band shared secret information between these entities);
o EE和CA-1不共享对称MACing密钥（即，这些实体之间不存在带外共享秘密信息）；
o sender name in ir MUST be present (and identical to the subject name present in the external identity certificate);
o ir中的发件人姓名必须存在（并且与外部身份证书中的主体姓名相同）；
o protectionAlg of MSG_SIG_ALG MUST be used in all messages;
o 所有消息中必须使用MSG_SIG_ALG的protectionAlg；
o external identity cert. MUST be carried in ir extraCerts field
o 必须在ir Extercerts字段中携带外部身份证书
o senderKID and recipKID are not used;
o 未使用senderKID和recipKID；
o body is ir or ip;
o 主体为ir或ip；
o protection bits are calculated according to the protectionAlg field.
o 根据protectionAlg字段计算保护位。
PKIXCMP {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-cmp2000(16)}
PKIXCMP {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-cmp2000(16)}
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
Certificate, CertificateList, Extensions, AlgorithmIdentifier,
UTF8String -- if required; otherwise, comment out
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,
UTF8String -- if required; otherwise, comment out
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
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
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-2005 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-crmf2005(36)}
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId,
CertReqMessages
FROM PKIXCRMF-2005 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-crmf2005(36)}
-- see also the behavioral clarifications to CRMF codified in
-- Appendix C of this specification
-- see also the behavioral clarifications to CRMF codified in
-- Appendix C of this specification
CertificationRequest
FROM PKCS-10 {iso(1) member-body(2)
us(840) rsadsi(113549)
pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)}
CertificationRequest
FROM PKCS-10 {iso(1) member-body(2)
us(840) rsadsi(113549)
pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)}
-- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT
-- tags). Alternatively, implementers may directly include
-- the [PKCS10] syntax in this module
-- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT
-- tags). Alternatively, implementers may directly include
-- the [PKCS10] syntax in this module
;
;
-- the rest of the module contains locally-defined OIDs and
-- constructs
-- the rest of the module contains locally-defined OIDs and
-- constructs
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate
}
-- This syntax, while bits-on-the-wire compatible with the
-- standard X.509 definition of "Certificate", allows the
-- possibility of future certificate types (such as X.509
-- attribute certificates, WAP WTLS certificates, or other kinds
-- of certificates) within this certificate management protocol,
-- should a need ever arise to support such generality. Those
-- implementations that do not foresee a need to ever support
-- other certificate types MAY, if they wish, comment out the
-- above structure and "un-comment" the following one prior to
-- compiling this ASN.1 module. (Note that interoperability
-- with implementations that don't do this will be unaffected by
-- this change.)
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate
}
-- This syntax, while bits-on-the-wire compatible with the
-- standard X.509 definition of "Certificate", allows the
-- possibility of future certificate types (such as X.509
-- attribute certificates, WAP WTLS certificates, or other kinds
-- of certificates) within this certificate management protocol,
-- should a need ever arise to support such generality. Those
-- implementations that do not foresee a need to ever support
-- other certificate types MAY, if they wish, comment out the
-- above structure and "un-comment" the following one prior to
-- compiling this ASN.1 module. (Note that interoperability
-- with implementations that don't do this will be unaffected by
-- this change.)
-- CMPCertificate ::= Certificate
-- CMPCertificate ::= Certificate
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL
}
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
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
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
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, certConf, and PKIConf
-- 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)
}
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response, certConf, and PKIConf
-- 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 [RFC3629] (note: each
-- UTF8String MAY include an [RFC3066] language tag
-- to indicate the language of the contained text
-- see [RFC2482] for details)
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String [RFC3629] (note: each
-- UTF8String MAY include an [RFC3066] language tag
-- to indicate the language of the contained text
-- see [RFC2482] for details)
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
pkiconf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General 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, --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
pkiconf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response error [23] ErrorMsgContent, --Error Message certConf [24] CertConfirmContent, --Certificate confirm pollReq [25] PollReqContent, --Polling request pollRep [26] PollRepContent --Polling response }
genp[22]GenRepContent，--一般响应错误[23]ErrorMsgContent，--错误消息certConf[24]CertConfirmContent，--证书确认pollReq[25]PollReqContent，--轮询请求pollRep[26]PollRepContent--轮询响应}
PKIProtection ::= BIT STRING
PKIProtection ::= BIT STRING
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
-- note: implementations MAY wish to limit acceptable sizes
-- of this string to values appropriate for their environment
-- in order to reduce the risk of denial-of-service attacks
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
-- note: implementations MAY wish to limit acceptable sizes
-- of this integer to values appropriate for their environment
-- in order to reduce the risk of denial-of-service attacks
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
-- note: implementations MAY wish to limit acceptable sizes
-- of this string to values appropriate for their environment
-- in order to reduce the risk of denial-of-service attacks
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
-- note: implementations MAY wish to limit acceptable sizes
-- of this integer to values appropriate for their environment
-- in order to reduce the risk of denial-of-service attacks
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
id-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])
id-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])
NestedMessageContent ::= PKIMessages
NestedMessageContent ::= PKIMessages
PKIStatus ::= INTEGER {
accepted (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
PKIStatus ::= INTEGER {
accepted (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 (note: proper handling of this status
-- response MAY use the polling req/rep PKIMessages specified
-- in Section 5.3.22; alternatively, polling in the underlying
-- transport layer MAY have some utility in this regard)
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
}
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 (note: proper handling of this status
-- response MAY use the polling req/rep PKIMessages specified
-- in Section 5.3.22; alternatively, polling in the underlying
-- transport layer MAY have some utility in this regard)
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
certRevoked (10),
-- the certificate has already been revoked
certConfirmed (11),
-- the certificate has already been confirmed
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
certRevoked (10),
-- the certificate has already been revoked
certConfirmed (11),
-- the certificate has already been confirmed
wrongIntegrity (12),
-- invalid integrity, password based instead of signature or
-- vice versa
badRecipientNonce (13),
-- invalid recipient nonce, either missing or wrong value
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA.
unacceptedExtension (16),
-- the requested extension is not supported by the TSA.
addInfoNotAvailable (17),
-- the additional information requested could not be
-- understood or is not available
badSenderNonce (18),
-- invalid sender nonce, either missing or wrong size
badCertTemplate (19),
-- invalid cert. template or missing mandatory information
signerNotTrusted (20),
-- signer of the message unknown or not trusted
transactionIdInUse (21),
-- the transaction identifier is already in use
unsupportedVersion (22),
-- the version of the message is not supported
notAuthorized (23),
-- the sender was not authorized to make the preceding
-- request or perform the preceding action
systemUnavail (24),
-- the request cannot be handled due to system unavailability
systemFailure (25),
-- the request cannot be handled due to system failure
duplicateCertReq (26)
-- certificate cannot be issued because a duplicate
-- certificate already exists
}
wrongIntegrity (12),
-- invalid integrity, password based instead of signature or
-- vice versa
badRecipientNonce (13),
-- invalid recipient nonce, either missing or wrong value
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA.
unacceptedExtension (16),
-- the requested extension is not supported by the TSA.
addInfoNotAvailable (17),
-- the additional information requested could not be
-- understood or is not available
badSenderNonce (18),
-- invalid sender nonce, either missing or wrong size
badCertTemplate (19),
-- invalid cert. template or missing mandatory information
signerNotTrusted (20),
-- signer of the message unknown or not trusted
transactionIdInUse (21),
-- the transaction identifier is already in use
unsupportedVersion (22),
-- the version of the message is not supported
notAuthorized (23),
-- the sender was not authorized to make the preceding
-- request or perform the preceding action
systemUnavail (24),
-- the request cannot be handled due to system unavailability
systemFailure (25),
-- the request cannot be handled due to system failure
duplicateCertReq (26)
-- certificate cannot be issued because a duplicate
-- certificate already exists
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
OOBCert ::= CMPCertificate
OOBCert ::= CMPCertificate
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over the DER encoding of the
-- self-signed certificate with the identifier certID.
}
-- hashVal is calculated over the DER encoding of the
-- self-signed certificate with the identifier certID.
}
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,
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).
-- 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)
-- }
}
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 CMPCertificate
OPTIONAL,
response SEQUENCE OF CertResponse
}
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
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)
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-utf8Pairs string defined
-- for regInfo in CertReqMsg [CRMF]
}
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-utf8Pairs string defined
-- for regInfo in CertReqMsg [CRMF]
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- see [CRMF] for comment on encoding
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- see [CRMF] for comment on encoding
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertOrEncCert ::= CHOICE {
certificate [0] CMPCertificate,
encryptedCert [1] EncryptedValue
}
CertOrEncCert ::= CHOICE {
certificate [0] CMPCertificate,
encryptedCert [1] EncryptedValue
}
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] CMPCertificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
CMPCertificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] CMPCertificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
CMPCertificate 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)
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)
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
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
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) }
--生成的CRL（可能有多个）}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew CMPCertificate, -- old pub signed with new priv
newWithOld CMPCertificate, -- new pub signed with old priv
newWithNew CMPCertificate -- new pub signed with new priv
}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew CMPCertificate, -- old pub signed with new priv
newWithOld CMPCertificate, -- new pub signed with old priv
newWithNew CMPCertificate -- new pub signed with new priv
}
CertAnnContent ::= CMPCertificate
CertAnnContent ::= CMPCertificate
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
CertConfirmContent ::= SEQUENCE OF CertStatus
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
-- the hash of the certificate, using the same hash algorithm
-- as is used to create and verify the certificate signature
certReqId INTEGER,
-- to match this confirmation with the corresponding req/rep
statusInfo PKIStatusInfo OPTIONAL
}
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
-- the hash of the certificate, using the same hash algorithm
-- as is used to create and verify the certificate signature
certReqId INTEGER,
-- to match this confirmation with the corresponding req/rep
statusInfo PKIStatusInfo OPTIONAL
}
PKIConfirmContent ::= NULL
PKIConfirmContent ::= NULL
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited
-- to, the following (un-comment in this ASN.1 module and use as
-- appropriate for a given environment):
--
-- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1}
-- CAProtEncCertValue ::= CMPCertificate
-- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2}
-- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier
-- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3}
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited
-- to, the following (un-comment in this ASN.1 module and use as
-- appropriate for a given environment):
--
-- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1}
-- CAProtEncCertValue ::= CMPCertificate
-- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2}
-- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier
-- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3}
-- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier
-- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4}
-- PreferredSymmAlgValue ::= AlgorithmIdentifier
-- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5}
-- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent
-- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6}
-- CurrentCRLValue ::= CertificateList
-- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7}
-- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER
-- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10}
-- KeyPairParamReqValue ::= OBJECT IDENTIFIER
-- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11}
-- KeyPairParamRepValue ::= AlgorithmIdentifer
-- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12}
-- RevPassphraseValue ::= EncryptedValue
-- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
-- ImplicitConfirmValue ::= NULL
-- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
-- ConfirmWaitTimeValue ::= GeneralizedTime
-- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15}
-- OrigPKIMessageValue ::= PKIMessages
-- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16}
-- SuppLangTagsValue ::= SEQUENCE OF UTF8String
--
-- where
--
-- id-pkix OBJECT IDENTIFIER ::= {
-- iso(1) identified-organization(3)
-- dod(6) internet(1) security(5) mechanisms(5) pkix(7)}
-- and
-- id-it OBJECT IDENTIFIER ::= {id-pkix 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.
-- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier
-- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4}
-- PreferredSymmAlgValue ::= AlgorithmIdentifier
-- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5}
-- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent
-- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6}
-- CurrentCRLValue ::= CertificateList
-- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7}
-- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER
-- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10}
-- KeyPairParamReqValue ::= OBJECT IDENTIFIER
-- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11}
-- KeyPairParamRepValue ::= AlgorithmIdentifer
-- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12}
-- RevPassphraseValue ::= EncryptedValue
-- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
-- ImplicitConfirmValue ::= NULL
-- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
-- ConfirmWaitTimeValue ::= GeneralizedTime
-- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15}
-- OrigPKIMessageValue ::= PKIMessages
-- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16}
-- SuppLangTagsValue ::= SEQUENCE OF UTF8String
--
-- where
--
-- id-pkix OBJECT IDENTIFIER ::= {
-- iso(1) identified-organization(3)
-- dod(6) internet(1) security(5) mechanisms(5) pkix(7)}
-- and
-- id-it OBJECT IDENTIFIER ::= {id-pkix 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
-- Receiver MAY ignore any contained OIDs that it does not
-- recognize.
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- Receiver MAY ignore any contained OIDs 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
}
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER
}
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER
}
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL
}
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL
}
END -- of CMP module
CMP模块的结束
Appendix G. Acknowledgements
附录G.确认书
The authors gratefully acknowledge the contributions of various members of the IETF PKIX Working Group and the ICSA CA-talk mailing list (a list solely devoted to discussing CMP interoperability efforts). Many of these contributions significantly clarified and improved the utility of this specification. Tomi Kause thanks Vesa Suontama and Toni Tammisalo for review and comments.
作者衷心感谢IETF PKIX工作组和ICSA CA talk邮件列表（仅用于讨论CMP互操作性工作的列表）各成员的贡献。这些贡献中的许多极大地澄清和改进了本规范的实用性。Tomi Kause感谢Vesa Suontama和Toni Tammisalo的评论。
Authors' Addresses
作者地址
Carlisle Adams University of Ottawa 800 King Edward Avenue P.O.Box 450, Station A Ottawa, Ontario K1N 6N5 CA
卡莱尔亚当斯渥太华大学800国王爱德华大道P.O.Box 450，车站A渥太华，安大略K1N 6N5 CA
Phone: (613) 562-5800 ext. 2345 Fax: (613) 562-5664 EMail: cadams@site.uottawa.ca
电话：（613）562-5800分机2345传真：（613）562-5664电子邮件：cadams@site.uottawa.ca
Stephen Farrell Trinity College Dublin Distributed Systems Group Computer Science Department Dublin IE
斯蒂芬·法雷尔三一学院都柏林分布式系统集团都柏林工业大学计算机科学系
Phone: +353-1-608-2945
EMail: stephen.farrell@cs.tcd.ie
Phone: +353-1-608-2945
EMail: stephen.farrell@cs.tcd.ie
Tomi Kause SSH Communications Security Corp Valimotie 17 Helsinki 00380 FI
Tomi Kause SSH通信安全公司Valimotie 17赫尔辛基00380 FI
Phone: +358 20 500 7415
EMail: toka@ssh.com
Phone: +358 20 500 7415
EMail: toka@ssh.com
Tero Mononen SafeNet, Inc. Fredrikinkatu 47 Helsinki 00100 FI
Tero Mononen SafeNet，Inc.Fredrikinkatu 47赫尔辛基00100 FI
Phone: +358 20 500 7814
EMail: tmononen@safenet-inc.com
Phone: +358 20 500 7814
EMail: tmononen@safenet-inc.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。