Network Working Group C. Bonatti, Ed.
Request for Comments: 4809 S. Turner, Ed.
Category: Informational IECA
G. Lebovitz, Ed.
Juniper
February 2007
Network Working Group C. Bonatti, Ed.
Request for Comments: 4809 S. Turner, Ed.
Category: Informational IECA
G. Lebovitz, Ed.
Juniper
February 2007
Requirements for an IPsec Certificate Management Profile
IPsec证书管理配置文件的要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed to meet the needs of enterprise-scale IPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements.
本信息性文档描述并确定了使用Internet密钥交换（IKE）（版本1和版本2）的Internet协议安全（IPsec）虚拟专用网络（VPN）系统与公钥基础设施（PKI）系统之间处理公钥证书（PKC）生命周期事务的要求。这些要求旨在满足企业级IPsec VPN部署的需要。旨在创建管理协议的标准跟踪概要文件，以满足其中许多要求。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope ......................................................5
1.2. Non-Goals ..................................................6
1.3. Definitions ................................................6
1.4. Requirements Terminology ...................................8
2. Architecture ....................................................9
2.1. VPN System .................................................9
2.1.1. IPsec Peer(s) .......................................9
2.1.2. VPN Administration Function (Admin) .................9
2.2. PKI System ................................................10
2.3. VPN-PKI Interaction .......................................11
3. Requirements ...................................................13
3.1. General Requirements ......................................13
3.1.1. One Protocol .......................................13
3.1.2. Secure Transactions ................................13
3.1.3. Admin Availability .................................13
3.1.4. PKI Availability ...................................14
3.1.5. End-User Transparency ..............................14
3.1.6. PKC Profile for PKI Interaction ....................14
3.1.6.1. Identity ..................................15
3.1.6.2. Key Usage .................................15
3.1.6.3. Extended Key Usage ........................15
3.1.6.4. Revocation Information Location ...........15
3.1.7. Error Handling .....................................15
3.2. Authorization .............................................15
3.2.1. One Protocol .......................................15
3.2.2. Bulk Authorization .................................16
3.2.3. Authorization Scenario .............................16
3.2.4. Authorization Request ..............................17
3.2.4.1. Specifying Fields within the PKC ..........17
3.2.4.2. Authorizations for Rekey, Renewal,
and Update ................................18
3.2.4.3. Other Authorization Elements ..............18
3.2.4.4. Cancel Capability .........................19
3.2.5. Authorization Response .............................19
3.2.5.1. Error Handling for Authorization ..........20
3.3. Generation ................................................20
3.3.1. Generation Method 1: IPsec Peer Generates Key Pair,
Constructs PKC Request, and Signs PKC Request ......21
3.3.2. Generation Method 2: IPsec Peer Generates Key Pair,
Admin Constructs PKS Request, Admin Signs PKC
Request ............................................22
3.3.3. Generation Method 3: Admin Generates Key Pair,
Constructs PKC Request, and Signs PKC Request ......23
3.3.4. Method 4: PKI Generates Key Pair ...................24
3.3.5. Error Handling for Generation ......................25
1. Introduction ....................................................4
1.1. Scope ......................................................5
1.2. Non-Goals ..................................................6
1.3. Definitions ................................................6
1.4. Requirements Terminology ...................................8
2. Architecture ....................................................9
2.1. VPN System .................................................9
2.1.1. IPsec Peer(s) .......................................9
2.1.2. VPN Administration Function (Admin) .................9
2.2. PKI System ................................................10
2.3. VPN-PKI Interaction .......................................11
3. Requirements ...................................................13
3.1. General Requirements ......................................13
3.1.1. One Protocol .......................................13
3.1.2. Secure Transactions ................................13
3.1.3. Admin Availability .................................13
3.1.4. PKI Availability ...................................14
3.1.5. End-User Transparency ..............................14
3.1.6. PKC Profile for PKI Interaction ....................14
3.1.6.1. Identity ..................................15
3.1.6.2. Key Usage .................................15
3.1.6.3. Extended Key Usage ........................15
3.1.6.4. Revocation Information Location ...........15
3.1.7. Error Handling .....................................15
3.2. Authorization .............................................15
3.2.1. One Protocol .......................................15
3.2.2. Bulk Authorization .................................16
3.2.3. Authorization Scenario .............................16
3.2.4. Authorization Request ..............................17
3.2.4.1. Specifying Fields within the PKC ..........17
3.2.4.2. Authorizations for Rekey, Renewal,
and Update ................................18
3.2.4.3. Other Authorization Elements ..............18
3.2.4.4. Cancel Capability .........................19
3.2.5. Authorization Response .............................19
3.2.5.1. Error Handling for Authorization ..........20
3.3. Generation ................................................20
3.3.1. Generation Method 1: IPsec Peer Generates Key Pair,
Constructs PKC Request, and Signs PKC Request ......21
3.3.2. Generation Method 2: IPsec Peer Generates Key Pair,
Admin Constructs PKS Request, Admin Signs PKC
Request ............................................22
3.3.3. Generation Method 3: Admin Generates Key Pair,
Constructs PKC Request, and Signs PKC Request ......23
3.3.4. Method 4: PKI Generates Key Pair ...................24
3.3.5. Error Handling for Generation ......................25
3.4. Enrollment ................................................25
3.4.1. One Protocol .......................................25
3.4.2. On-line Protocol ...................................25
3.4.3. Single Connection with Immediate Response ..........25
3.4.4. Manual Approval Option .............................25
3.4.5. Enrollment Method 1: Peer Enrolls to PKI Directly ..26
3.4.6. Enrollment Method 2a: Peer Enrolls through Admin ...27
3.4.7. Enrollment Method 2b: Peer Enrolls through Admin ...28
3.4.8. Enrollment Method 3a: Admin Authorizes and
Enrolls Directly to PKI ............................30
3.4.9. Enrollment Method 3b: Admin Requests and PKI
Generates and Sends PKC ............................31
3.4.10. Confirmation Handshake ............................32
3.4.11. Error Handling for Enrollment .....................33
3.5. Lifecycle .................................................34
3.5.1. One Protocol .......................................34
3.5.2. PKC Rekeys, Renewals, and Updates ..................35
3.5.2.1. Rekey Request .............................36
3.5.2.2. Renew Request .............................36
3.5.2.3. Update Request ............................37
3.5.2.4. Error Handling for Rekey, Renewal,
and Update ................................38
3.5.2.5. Confirmation Handshakes ...................38
3.5.3. Revocation .........................................38
3.6. Repositories ..............................................39
3.6.1. Lookups ............................................39
3.6.2. Error Handling for Repository Lookups ..............40
3.7. Trust .....................................................40
3.7.1. Trust Anchor PKC Acquisition .......................40
3.7.2. Certification Path Validation ......................41
3.7.3. Revocation Checking and Status Information .........41
3.7.4. Error Handling in Revocation Checking and
Certificate Path Validation ........................42
4. Security Considerations ........................................42
5. References .....................................................43
5.1. Normative References ......................................43
5.2. Informative References ....................................43
6. Acknowledgements ...............................................43
3.4. Enrollment ................................................25
3.4.1. One Protocol .......................................25
3.4.2. On-line Protocol ...................................25
3.4.3. Single Connection with Immediate Response ..........25
3.4.4. Manual Approval Option .............................25
3.4.5. Enrollment Method 1: Peer Enrolls to PKI Directly ..26
3.4.6. Enrollment Method 2a: Peer Enrolls through Admin ...27
3.4.7. Enrollment Method 2b: Peer Enrolls through Admin ...28
3.4.8. Enrollment Method 3a: Admin Authorizes and
Enrolls Directly to PKI ............................30
3.4.9. Enrollment Method 3b: Admin Requests and PKI
Generates and Sends PKC ............................31
3.4.10. Confirmation Handshake ............................32
3.4.11. Error Handling for Enrollment .....................33
3.5. Lifecycle .................................................34
3.5.1. One Protocol .......................................34
3.5.2. PKC Rekeys, Renewals, and Updates ..................35
3.5.2.1. Rekey Request .............................36
3.5.2.2. Renew Request .............................36
3.5.2.3. Update Request ............................37
3.5.2.4. Error Handling for Rekey, Renewal,
and Update ................................38
3.5.2.5. Confirmation Handshakes ...................38
3.5.3. Revocation .........................................38
3.6. Repositories ..............................................39
3.6.1. Lookups ............................................39
3.6.2. Error Handling for Repository Lookups ..............40
3.7. Trust .....................................................40
3.7.1. Trust Anchor PKC Acquisition .......................40
3.7.2. Certification Path Validation ......................41
3.7.3. Revocation Checking and Status Information .........41
3.7.4. Error Handling in Revocation Checking and
Certificate Path Validation ........................42
4. Security Considerations ........................................42
5. References .....................................................43
5.1. Normative References ......................................43
5.2. Informative References ....................................43
6. Acknowledgements ...............................................43
This document describes and identifies the requirements for transactions to handle PKC lifecycle transactions between [IPsec] VPN Systems using IKE ([IKEv1] and [IKEv2]) and PKI Systems. This document contains requirements for a transaction-based approach. Other models are conceivable, for example, a directory-centric approach, but their requirements are beyond the scope of this document.
本文件描述并确定了在使用IKE（[IKEv1]和[IKEv2]）的[IPsec]VPN系统和PKI系统之间处理PKC生命周期事务的事务要求。本文件包含基于事务的方法的要求。其他模型是可以想象的，例如，以目录为中心的方法，但是它们的需求超出了本文档的范围。
This document enumerates requirements for Public Key Certificate (PKC) lifecycle transactions between different VPN System and PKI System products in order to better enable large scale, PKI-enabled IPsec deployments with a common set of transactions. Requirements for both the IPsec and the PKI products are discussed. The requirements are carefully designed to achieve security without compromising ease of management and deployment, even where the deployment involves tens of thousands of IPsec users and devices.
本文档列举了不同VPN系统和PKI系统产品之间的公钥证书（PKC）生命周期事务的要求，以便更好地使用公共事务集进行大规模、支持PKI的IPsec部署。讨论了IPsec和PKI产品的要求。这些要求经过精心设计，以实现安全性，而不会影响管理和部署的易用性，即使部署涉及数万个IPsec用户和设备。
The requirements address transactions for the entire PKC lifecycle for PKI-enabled VPN System: authorization (of PKC issuance), generation (public-private key pair and PKC request), enrollment (PKC request, PKC response, and confirmation), maintenance (rekey, renew, update, revoke, and confirm), and repository lookups. These transactions enable a VPN Operator to:
这些要求涉及启用PKI的VPN系统的整个PKC生命周期的事务：授权（PKC颁发）、生成（公私密钥对和PKC请求）、注册（PKC请求、PKC响应和确认）、维护（重新密钥、续订、更新、撤销和确认）以及存储库查找。这些事务使VPN运营商能够：
- Use a VPN Administration function (Admin), which is introduced in this document, to manage PKC authorization and possibly act as the sole interface for the VPN System and the PKI System.
- 使用本文档中介绍的VPN管理功能（Admin）管理PKC授权，并可能作为VPN系统和PKI系统的唯一接口。
- Authorize individual or batches of PKC issuances based on a pre-agreed template (i.e., both types of authorization requests refer to the pre-agreed template). These authorizations can occur either prior to the enrollment or in the same transaction as the enrollment.
- 根据预先约定的模板（即，两种类型的授权请求均指预先约定的模板）对单个或批次的PKC发行进行授权。这些授权可以发生在注册之前，也可以发生在与注册相同的事务中。
- Provision PKI-based user or machine identity to IPsec Peers, on a large scale.
- 大规模地向IPsec对等方提供基于PKI的用户或机器身份。
- Set the corresponding gateway or client authorization policy for remote access and site-to-site connections.
- 为远程访问和站点到站点连接设置相应的网关或客户端授权策略。
- Establish policies for automatic PKC rekeys, renewals, and updates.
- 建立PKC自动密钥更新、续订和更新的策略。
- Ensure timely revocation information is available for PKCs used in IKE exchanges.
- 确保IKE交换中使用的PKC具有及时的吊销信息。
These requirements are intended to be used to profile a certificate management protocol that the VPN System will use to communicate with the PKI System. Note that this profile will be in another document. The certificate management profile will also clarify and constrain existing PKIX (PKI for X.509 Certificates) and IPsec standards to limit the complexity of deployment. Some requirements may require either a new protocol, or changes or extensions to an existing protocol.
这些要求旨在用于分析VPN系统将用于与PKI系统通信的证书管理协议。请注意，此配置文件将位于另一个文档中。证书管理概要文件还将澄清和约束现有的PKIX（用于X.509证书的PKI）和IPsec标准，以限制部署的复杂性。有些需求可能需要新协议，或者对现有协议进行更改或扩展。
The desired outcome of the requirements and profile documents is that both IPsec and PKI vendors create interoperable products to enable large-scale IPsec System deployments, and do so as quickly as possible. For example, a VPN Operator should be able to use any conforming IPsec implementation (VPN Administration or IPsec Peer) of the certificate management profile with any conforming PKI vendor's implementation to perform the VPN rollout and management.
需求和概要文件的预期结果是，IPsec和PKI供应商都创建了可互操作的产品，以支持大规模IPsec系统部署，并尽快这样做。例如，VPN运营商应能够将证书管理配置文件的任何符合性IPsec实施（VPN管理或IPsec对等）与任何符合性PKI供应商的实施一起使用，以执行VPN部署和管理。
The document addresses requirements on transactions between the VPN Systems and the PKI Systems and between the VPN Administration and IPsec Peers. The requirements strive to meet eighty percent of the market needs for large-scale deployments (i.e., VPNs including hundreds or thousands of managed VPN gateways or VPN remote access clients). Environments will understandably exist in which large-scale deployment tools are desired, but local security policy stringency will not allow for the use of such commercial tools. The solution will possibly miss the needs of the highest ten percent of stringency and the lowest ten percent of convenience requirements. Use cases will be considered or rejected based upon this eighty percent rule. The needs of small deployments are a stated non-goal; however, service providers employing the scoped solution and applying it to many smaller deployments in aggregate may address them.
本文件阐述了VPN系统和PKI系统之间以及VPN管理和IPsec对等方之间的交易要求。这些要求力求满足80%的大规模部署市场需求（即VPN，包括数百或数千个受管VPN网关或VPN远程访问客户端）。可以理解的是，在需要大规模部署工具的环境中，本地安全策略的严格性将不允许使用此类商业工具。解决方案可能会忽略最高10%的严格性要求和最低10%的便利性要求。用例将根据这个百分之八十的规则被考虑或拒绝。小型部署的需求是一个明确的非目标；但是，服务提供商使用范围明确的解决方案并将其应用于许多较小的总体部署可能会解决这些问题。
Gateway-to-gateway access and end-user remote access (to a gateway) are both covered. End-to-end communications are not necessarily excluded, but are intentionally not a focus.
网关到网关访问和最终用户远程访问（到网关）都包括在内。端到端通信不一定被排除在外，但有意不作为重点。
Only VPN-PKI transactions that ease and enable scalable PKI-enabled IPsec deployments are addressed.
仅处理简化并支持可扩展的启用PKI的IPsec部署的VPN-PKI事务。
The scenario for PKC cross-certification will not be addressed.
PKC交叉认证的场景将不会得到解决。
The protocol specification for the VPN-PKI interactions will not be addressed.
VPN-PKI交互的协议规范将不会被提及。
The protocol specification for the VPN Administrator to Peer transactions will not be addressed. These interactions are considered vendor proprietary. These interactions may be standardized later to enable interoperability between VPN Administration function stations and IPsec Peers from different vendors, but are far beyond the scope of this current effort, and will be described as opaque transactions in this document.
VPN管理员对对等事务的协议规范将不会被解决。这些交互被认为是供应商专有的。这些交互稍后可能会被标准化，以实现VPN管理功能站和来自不同供应商的IPsec对等点之间的互操作性，但这些交互远远超出了当前工作的范围，在本文档中将被描述为不透明事务。
The protocol specification for Registration Authority - Certificate Authority (RA-CA), CA-Repository, and RA-Repository interactions will not be addressed.
注册机构-证书颁发机构（RA-CA）、CA存储库和RA存储库交互的协议规范将不予讨论。
VPN System The VPN System is comprised of the VPN Administration function (defined below), the IPsec Peers, and the communication mechanism between the VPN Administration and the IPsec Peers. VPN System is defined in more detail in Section 2.1.
VPN系统VPN系统由VPN管理功能（定义如下）、IPsec对等点以及VPN管理和IPsec对等点之间的通信机制组成。VPN系统的详细定义见第2.1节。
PKI System The PKI System, or simply PKI, is the set of functions needed to authorize, issue, and manage PKCs. PKI System is defined in more detail in Section 2.2.
PKI系统PKI系统，简称PKI，是授权、发布和管理PKC所需的一组功能。PKI系统的详细定义见第2.2节。
(VPN) Operator The Operator is the person or group of people that define security policy and configure the VPN System to enforce that policy, with the VPN Administration function.
（VPN）运营商运营商是指定义安全策略并配置VPN系统以实施该策略的个人或群体，具有VPN管理功能。
IPsec Peer (Gateway or Client) For the purposes of this document, an IPsec Peer, or simply "Peer", is any VPN System component that communicates IKE and IPsec to another Peer in order to create an IPsec Security Association for communications. It can be either a traditional security gateway (with two network interfaces, one for the protected network and one for the unprotected network) or an IPsec client (with a single network interface). In both cases, the Peer can pass traffic with no IPsec protection, and can add IPsec protection to chosen traffic streams. See Section 2.1.1 for more details.
IPsec对等方（网关或客户端）在本文档中，IPsec对等方或简称“对等方”是任何VPN系统组件，它将IKE和IPsec通信到另一个对等方，以便为通信创建IPsec安全关联。它可以是传统的安全网关（具有两个网络接口，一个用于受保护的网络，另一个用于未受保护的网络）或IPsec客户端（具有单个网络接口）。在这两种情况下，对等方都可以在没有IPsec保护的情况下传递流量，并且可以向选定的流量流添加IPsec保护。详见第2.1.1节。
(VPN) Admin The Admin is the VPN System function that interacts with the PKI System to establish PKC provisioning for the VPN connections. See Section 2.1.2 for more details.
（c）设置VPN系统与PKS的VPN连接，用于与PKS进行交互。详见第2.1.2节。
End Entity An end entity is the entity or subject that is identified in a PKC. The end entity is the one entity that will finally use a private key associated with a PKC to digitally sign data. In this document, an IPsec Peer is certainly an end entity, but the VPN Admin can also constitute an end entity. Note that end entities can have different PKCs for different purposes (e.g., signature vs. key exchange, Admin-functions vs. Peer-functions).
最终实体最终实体是PKC中标识的实体或主体。最终实体将最终使用与PKC关联的私钥对数据进行数字签名。在本文中，IPsec对等方当然是一个终端实体，但VPN管理员也可以构成一个终端实体。请注意，终端实体可以有不同的PKC用于不同的目的（例如，签名与密钥交换、管理功能与对等功能）。
PKC Rekey The routine procedure for replacement of a PKC with a new PKC with a new public key for the same subject name. A rekey process can rely on the existing key pair to bootstrap authentication for the new enrollment.
PKC重新设置PKC密钥的例行程序，用于使用具有相同主题名称的新公钥的新PKC替换PKC。重设密钥过程可以依赖现有密钥对来引导新注册的身份验证。
PKC Renewal The acquisition of a new PKC with the same public key due to the expiration of an existing PKC. Renewal occurs prior to the expiration of the existing PKC to avoid any connection outages. A renewal process can rely on the existing key pair to bootstrap authentication for the new enrollment.
PKC续订由于现有PKC到期而获得具有相同公钥的新PKC。续订发生在现有PKC到期之前，以避免任何连接中断。续订过程可以依赖现有密钥对来引导新注册的身份验证。
PKC Update A special case of a renewal-like occurrence where a PKC needs to be changed prior to expiration due to some change in its subject's information. Examples might include change in the address, telephone number, or name change due to marriage of the end entity. An update process can rely on the existing key pair to bootstrap authentication for the new enrollment.
PKC更新—类似续签事件的特殊情况，其中PKC由于主体信息的某些更改而需要在到期前进行更改。示例可能包括地址、电话号码的更改，或由于最终实体的婚姻而导致的名称更改。更新过程可以依赖现有密钥对来引导新注册的身份验证。
Registration Authority (RA) An optional entity in a PKI System given responsibility for performing some of the administrative tasks necessary in the registration of end entities, such as confirming the subject's identity and verifying that the subject has possession of the private key associated with the public key requested for a PKC.
注册机构（RA）PKI系统中的可选实体，负责执行最终实体注册中必要的一些管理任务，如确认主体身份和验证主体拥有与PKC请求的公钥相关的私钥。
Certificate Authority (CA) An authority in a PKI System that is trusted by one or more users to create and sign PKCs. It is important to note that the CA is responsible for the PKCs during their whole lifetime, not just for issuing them.
证书颁发机构（CA）：PKI系统中一个或多个用户信任的创建和签署PKC的机构。需要注意的是，CA在PKC的整个生命周期中负责PKC，而不仅仅是签发PKC。
Repository An Internet-accessible server in a PKI System that stores and makes available for retrieval PKCs and Certificate Revocation Lists (CRLs).
存储库PKI系统中可访问Internet的服务器，用于存储和检索PKC和证书吊销列表（CRL）。
Root CA/Trust Anchor 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直接受信任。
Certificate Revocation List (CRL) A CRL is a CA-signed, timestamped list identifying revoked PKCs and made freely available in a repository. Peers retrieve the CRL to verify that a PKC being presented to them as the identity in an IKE transaction has not been revoked.
证书撤销列表（CRL）CRL是一个CA签名的时间戳列表，用于标识已撤销的PKC，并在存储库中免费提供。对等方检索CRL以验证作为IKE事务中的标识呈现给他们的PKC是否已被撤销。
CRL Distribution Point (CDP) The CDP is a PKC extension that identifies the location from which end entities should retrieve CRLs to check status information.
CRL分发点（CDP）CDP是PKC扩展，用于标识终端实体应从中检索CRL以检查状态信息的位置。
Authority Info Access (AIA) The AIA is a PKC extension that indicates how to access CA information and services for the issuer of the PKC in which the extension appears. Information and services may include on-line validation services and Certificate Policy (CP) data.
授权信息访问（AIA）AIA是PKC扩展，指示如何访问PKC发行人的CA信息和服务，该扩展出现在PKC中。信息和服务可能包括在线验证服务和证书策略（CP）数据。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[必须”中的说明进行解释。
This section describes the overall architecture for a PKI-supported IPsec VPN deployment. First, an explanation of the VPN System is presented. Second, key points about the PKI System are stated. Third, the VPN-PKI architecture is presented.
本节介绍支持PKI的IPsec VPN部署的总体体系结构。首先，对VPN系统进行了说明。其次，阐述了PKI系统的关键技术。第三，提出了VPN-PKI体系结构。
The VPN System consists of the IPsec Peers and the VPN Administration function, as depicted in Figure 1.
VPN系统由IPsec对等点和VPN管理功能组成，如图1所示。
+---------------------------------------------------+
| |
| +----------+ |
| | VPN | |
| +---------->| Admin |<-------+ |
| | | Function | | |
| | +----------+ | |
| v v |
| +---------+ +---------+ |
| | IPsec | | IPsec | |
| | Peer 1 |<=======================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+---------------------------------------------------+
+---------------------------------------------------+
| |
| +----------+ |
| | VPN | |
| +---------->| Admin |<-------+ |
| | | Function | | |
| | +----------+ | |
| v v |
| +---------+ +---------+ |
| | IPsec | | IPsec | |
| | Peer 1 |<=======================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+---------------------------------------------------+
Figure 1: VPN System
图1:VPN系统
The Peers are two entities between which establishment of an IPsec Security Association is required. Two Peers are shown in Figure 1, but implementations can support an actual number in the hundreds or thousands. The Peers can be gateway-to-gateway, remote-access-host-to-gateway, or a mix of both. The Peers authenticate themselves in the IKE negotiation using digital signatures generated with PKCs from a PKI System.
对等点是两个实体，需要在它们之间建立IPsec安全关联。图1中显示了两个对等点，但实现可以支持数百或数千的实际数量。对等点可以是网关到网关、远程访问主机到网关或两者的混合。对等方使用PKI系统中PKC生成的数字签名在IKE协商中对自己进行身份验证。
This document defines the notion of a VPN Administration function, hereafter referred to as Admin, and gives the Admin great responsibility within the VPN System. The Admin is a centralized function used by the Operator to interact with the PKI System to establish PKI policy (e.g., algorithms, key lengths, lifecycle options, and PKC fields) for groups of IPsec Peers. The Admin also
本文档定义了VPN管理功能的概念，以下称为管理员，并赋予管理员在VPN系统中的重大责任。管理员是运营商用于与PKI系统交互以为IPsec对等组建立PKI策略（例如，算法、密钥长度、生命周期选项和PKC字段）的集中式功能。管理员也
authorizes PKC issuance and can act as the Peer's PKI System interface, which allows the Admin to perform many RA-like functions.
授权PKC发行，并可作为对等方的PKI系统接口，允许管理员执行许多类似RA的功能。
It is important to note that, within this document, the Admin is neither a device nor a person; rather, it is a function. Every large-scale VPN deployment will contain the Admin function. The function can be performed on a stand-alone workstation, on a gateway, or on an administration software component. The Admin function can also be one and the same as the gateway, client device, or software. They are represented in the architectural diagram as different functions, but they need not be different physical entities. As such, the Admin's architecture and the means by which it interacts with the participating IPsec Peers will vary widely from implementation to implementation. However, some basic functions of the Admin are assumed.
需要注意的是，在本文档中，管理员既不是设备也不是个人；相反，它是一种功能。每个大规模VPN部署都将包含管理功能。该功能可在独立工作站、网关或管理软件组件上执行。管理功能也可以与网关、客户端设备或软件相同。它们在体系结构图中表示为不同的功能，但它们不需要是不同的物理实体。因此，管理员的体系结构及其与参与的IPsec对等方进行交互的方式将因实现的不同而有很大差异。然而，一些基本的管理功能是假定的。
- It, and not the PKI, will define the Certificate Policy (CP) [FRAME] for use in a VPN System. The PKC's characteristics and contents are a function of the CP. In VPN Systems, the Operator chooses to strengthen the VPN by using PKI; PKI is a bolt-on to the VPN System. The Operator will configure local security policy in part through the Admin and its authorized PKI-enabled Peers.
- 它（而不是PKI）将定义在VPN系统中使用的证书策略（CP）[FRAME]。PKC的特点和内容是CP的功能。在VPN系统中，运营商选择使用PKI加强VPN；PKI是VPN系统的一个螺栓。运营商将部分通过管理员及其授权的启用PKI的对等方配置本地安全策略。
- It will interact directly with the PKI System to initiate authorization for end entity PKCs by sending the parameters and contents for individual PKCs or batches of PKCs based on a pre-agreed template (i.e., both types of authorization requests refer to the pre-agreed template). Templates will be agreed in an out-of-band mechanism by the VPN Operator and the PKI Operator. It will receive back from the PKI a unique tuple of authorization identifiers and one-time authorization tokens that will authorize Peers to request a PKC.
- 它将直接与PKI系统交互，通过基于预先约定的模板发送单个PKC或批量PKC的参数和内容（即，两种类型的授权请求均指预先约定的模板），启动对最终实体PKC的授权。VPN运营商和PKI运营商将通过带外机制商定模板。它将从PKI接收一组唯一的授权标识符和一次性授权令牌，这些令牌将授权对等方请求PKC。
- It will deliver instructions to the IPsec Peers, and the Peers will carry out those instructions (e.g., Admin passes Peer information necessary to generate keys and PKC request).
- 它将向IPsec对等方发送指令，对等方将执行这些指令（例如，管理员传递生成密钥和PKC请求所需的对等方信息）。
The PKI System, as depicted in Figure 2, can be set up and operated by the Operator (in-house), be provided by third party PKI providers to which connectivity is available at the time of provisioning (managed PKI service), or be integrated with the VPN product.
如图2所示，PKI系统可由运营商（内部）设置和操作，由第三方PKI提供商提供，在提供时连接可用（托管PKI服务），或与VPN产品集成。
+---------------------------------------------+
| +-------------------------+ |
| v | |
| +--------------+ v |
| | Repository | +----+ +----+ |
| | Certs & CRLs |<-> | CA |<->| RA | |
| +--------------+ +----+ +----+ |
| |
+---------------------------------------------+
+---------------------------------------------+
| +-------------------------+ |
| v | |
| +--------------+ v |
| | Repository | +----+ +----+ |
| | Certs & CRLs |<-> | CA |<->| RA | |
| +--------------+ +----+ +----+ |
| |
+---------------------------------------------+
Figure 2: PKI System
图2:PKI系统
This framework assumes that all components of the VPN obtain PKCs from a single PKI community. An IPsec Peer can accept a PKC from a Peer that is from a CA outside of the PKI community, but the auto provision and life cycle management for such a PKC or its trust anchor PKC fall out of scope.
该框架假设VPN的所有组件都从单个PKI社区获得PKC。IPsec对等方可以接受来自PKI社区之外CA的对等方的PKC，但此类PKC或其信任锚PKC的自动资源调配和生命周期管理不在范围之内。
The PKI System contains a mechanism for handling Admin's authorization requests and PKC enrollments. This mechanism is referred to as the Registration Authority (RA). The PKI System contains a Repository for Peers to retrieve each other's PKCs and revocation information. Last, the PKI System contains the core function of a CA that uses a public and private key pair and signs PKCs.
PKI系统包含处理管理员授权请求和PKC注册的机制。这一机制称为登记机关（RA）。PKI系统包含一个存储库，供对等方检索彼此的PKC和吊销信息。最后，PKI系统包含CA的核心功能，CA使用公钥和私钥对并对PKC进行签名。
The interaction between the VPN System and the PKI System is the key focus of this requirements document, as shown in Figure 3. Therefore, it is sensible to consider the steps necessary to set up, use, and manage PKCs for one Peer to establish an association with another Peer.
VPN系统和PKI系统之间的交互是本需求文档的重点，如图3所示。因此，明智地考虑建立、使用和管理一个对等点的PKCS以建立与另一个对等体的关联所需的步骤。
+-----------------------------------------------+
| PKI System |
| |
| +--------------+ |
| | Repository | +----+ +----+ |
| | Certs & CRLs | | CA | | RA | |
| +--------------+ +----+ +----+ |
| |
+-----------------------------------------------+
^ ^ ^
|[G] |[A] |[G]
|[E] |[G] |[E]
|[L] |[E] |[L]
|[R] |[R] |[R]
| |[L] |
+-----+------------------+-------------------+-------+
| | v | |
| | +----------+ | |
| | [G][E][L][R]| VPN |[G][E][L][R] | |
| | +---------->| Admin |<----------+ | |
| | | | Function | | | |
| | | +----------+ | | |
| v v v v |
| +---------+ +---------+ |
| | IPsec | [I] | IPsec | |
| | Peer 1 |<========================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+----------------------------------------------------+
+-----------------------------------------------+
| PKI System |
| |
| +--------------+ |
| | Repository | +----+ +----+ |
| | Certs & CRLs | | CA | | RA | |
| +--------------+ +----+ +----+ |
| |
+-----------------------------------------------+
^ ^ ^
|[G] |[A] |[G]
|[E] |[G] |[E]
|[L] |[E] |[L]
|[R] |[R] |[R]
| |[L] |
+-----+------------------+-------------------+-------+
| | v | |
| | +----------+ | |
| | [G][E][L][R]| VPN |[G][E][L][R] | |
| | +---------->| Admin |<----------+ | |
| | | | Function | | | |
| | | +----------+ | | |
| v v v v |
| +---------+ +---------+ |
| | IPsec | [I] | IPsec | |
| | Peer 1 |<========================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+----------------------------------------------------+
[A] = Authorization: PKC issuance
[G] = Generation: Public key, private key, and PKC request
[E] = Enrollment: Sending PKC request, verifying PKC response, and
confirming PKC response
[I] = IKE and IPsec communication
[L] = Lifecycle: Rekey, renewal, update, revocation, and confirmation
[R] = Repository: Posting and lookups
[A] = Authorization: PKC issuance
[G] = Generation: Public key, private key, and PKC request
[E] = Enrollment: Sending PKC request, verifying PKC response, and
confirming PKC response
[I] = IKE and IPsec communication
[L] = Lifecycle: Rekey, renewal, update, revocation, and confirmation
[R] = Repository: Posting and lookups
Figure 3. Architectural Framework for VPN-PKI Interaction
图3。VPN-PKI交互体系结构框架
Requirements for each of the interactions, [A], [G], [E], [L], and [R], are addressed in Sections 3.2 through 3.6. However, only requirements for [A], [E], [L], and [R] will be addressed by the certificate management profile. Requirements for [I] transactions are beyond the scope of this document. Additionally, the act of certification (i.e., binding the public key to the name) is performed at the CA and is not shown in the figure.
第3.2节至第3.6节介绍了每种交互作用[A]、[G]、[E]、[L]和[R]的要求。但是，证书管理概要文件将只处理[A]、[E]、[L]和[R]的要求。[I]交易的要求超出了本文件的范围。此外，认证行为（即，将公钥绑定到名称）在CA处执行，图中未显示。
The target profile, to be based on this requirements document, MUST call for ONE PROTOCOL or ONE USE PROFILE for each main element of the [A], [E], [L], and [R] interactions. In order to reduce complexity and improve interoperability, having multiple competing protocols or profiles to solve the same requirement should be avoided whenever possible.
基于本需求文件的目标概要文件必须为[A]、[E]、[L]和[R]交互的每个主要元素调用一个协议或一个使用概要文件。为了降低复杂性并提高互操作性，应尽可能避免使用多个相互竞争的协议或概要文件来解决相同的需求。
Meeting some of the requirements may necessitate the creation of a new protocol or new extension for an existing protocol; however, the latter is much preferred.
满足某些要求可能需要创建新协议或现有协议的新扩展；然而，后者更受欢迎。
The target certificate management profile MUST specify the [A], [E], [L], and [R] transactions between VPN and PKI Systems. To support these transactions, the Admin and PKI MUST exchange policy details, identities, and keys. As such, the method of communication for [A], [E], and [L] transactions MUST be secured in a manner that ensures privacy, authentication, and message data integrity. The communication method MUST require that mutual trust be established between the PKI and the Admin (see Section 3.7.1). [R] transactions do not require authentication or message data integrity because the responses (i.e., PKCs and CRLs) are already digitally signed. Whether [R] transactions require privacy is determined by the local security policy.
目标证书管理配置文件必须指定VPN和PKI系统之间的[A]、[E]、[L]和[R]事务。为了支持这些事务，管理员和PKI必须交换策略详细信息、身份和密钥。因此，[A]、[E]和[L]交易的通信方法必须以确保隐私、身份验证和消息数据完整性的方式进行保护。通信方法必须要求PKI和管理员之间建立互信（见第3.7.1节）。[R] 事务不需要身份验证或消息数据完整性，因为响应（即PKC和CRL）已进行数字签名。[R]交易是否需要隐私由本地安全策略决定。
The target certificate management profile will not specify [G] transactions. However, these transactions MUST be secured in a manner that ensures privacy, authentication, and message data integrity because these transactions are the basis for the other transactions.
目标证书管理配置文件不会指定[G]事务。但是，必须以确保隐私、身份验证和消息数据完整性的方式保护这些事务，因为这些事务是其他事务的基础。
The Admin MUST be reachable by the Peers. Most implementations will meet this requirement by ensuring Peers can connect to the Admin from anywhere on the network or Internet. However, communication between the Admin and Peers can be "off-line". It can, in some environments, be "moving media" (i.e., the configuration or data is loaded on to a floppy disk or other media and physically moved to the IPsec Peers). Likewise, it can be entered directly on the IPsec Peer via a User Interface (UI). In this case, the Admin function is co-located on
管理员必须可由对等方访问。大多数实现将通过确保对等方可以从网络或Internet上的任何位置连接到管理员来满足这一要求。但是，管理员和对等方之间的通信可以是“离线”的。在某些环境中，它可以是“移动媒体”（即，配置或数据加载到软盘或其他媒体上，并物理移动到IPsec对等方）。同样，它可以通过用户界面（UI）直接在IPsec对等机上输入。在这种情况下，管理功能位于
the Peer device itself. Most requirements and scenarios in this document assume on-line availability of the Admin for the life of the VPN System.
对等设备本身。本文档中的大多数需求和场景都假设管理员在VPN系统的生命周期内在线可用。
Availability is REQUIRED initially for authorization transactions between the PKI and Admin. Further availability is required in most cases, but the extent of this availability is a decision point for the Operator. Most requirements and scenarios in this document assume on-line availability of the PKI for the life of the VPN System.
PKI和管理员之间的授权事务最初需要可用性。大多数情况下需要进一步的可用性，但这种可用性的程度是运营商的决策点。本文档中的大多数要求和场景都假设PKI在VPN系统的生命周期内在线可用。
Off-line interaction between the VPN and PKI Systems (i.e., where physical media is used as the transport method) is beyond the scope of this document.
VPN和PKI系统之间的离线交互（即，使用物理介质作为传输方法）超出了本文件的范围。
PKI interactions are to be transparent to the user. Users SHOULD NOT even be aware that PKI is in use. First time connections SHOULD consist of no more than a prompt for some identification and pass phrase, and a status bar notifying the user that setup is in progress.
PKI交互对用户是透明的。用户甚至不应该知道PKI正在使用。第一次连接应该只包含一个提示，提示输入一些标识和密码短语，以及一个状态栏，通知用户安装正在进行。
A PKC used for identity in VPN-PKI transactions MUST include all the [CERTPROFILE] mandatory fields. It MUST also contain contents necessary to support path validation and certificate status checking.
用于VPN-PKI交易中标识的PKC必须包含所有[CERTPROFILE]必填字段。它还必须包含支持路径验证和证书状态检查所必需的内容。
It is preferable that the PKC profiles for IPsec transactions [IKECERTPROFILE] and VPN-PKI transactions (in the certificate management profile) are the same so that one PKC could be used for both transaction sets. If the profiles are inconsistent, then different PKCs (and perhaps different processing requirements) might be required. However, the authors urge that progress continue on other aspects of this standardization effort regardless of the status of efforts to achieve PKC profile consensus.
IPsec配置文件[ECE]和PKC配置文件可用于相同的事务，因此，IPsec配置文件中的[ECE-VPN]事务更适合于使用同一个IPsec配置文件。如果配置文件不一致，则可能需要不同的PKC（以及可能不同的处理要求）。然而，作者敦促继续在该标准化工作的其他方面取得进展，无论为达成PKC概要共识所做的努力的状态如何。
PKCs MUST support identifying (i.e., naming) Peers and Admins. The following name forms MUST be supported:
PKC必须支持识别（即命名）对等方和管理员。必须支持以下名称表单：
- Fully-Qualified Domain Name (FQDN) - RFC 822 (also called USER FQDN) - IPv4 Address - IPv6 Address
- 完全限定域名（FQDN）-RFC 822（也称为用户FQDN）-IPv4地址-IPv6地址
PKCs MUST support indicating the purposes for which the key (i.e., digital signature) can be used. Further, PKCs MUST always indicate that relying parties (i.e., Peers) need to understand the indication.
PKCs必须支持指示密钥（即数字签名）的用途。此外，PKC必须始终表明依赖方（即对等方）需要理解该指示。
Extended Key Usage (EKU) indications are not required. The presence or lack of an EKU MUST NOT cause an implementation to fail an IKE connection.
不需要扩展密钥使用（EKU）指示。EKU的存在或缺乏不得导致实现使IKE连接失败。
PKCs MUST indicate the location of CRL such that any Peer who holds the PKC locally will know exactly where to go and how to request the CRL.
PKC必须指明CRL的位置，以便在本地持有PKC的任何对等方都能准确知道去哪里以及如何申请CRL。
The protocol for the VPN-PKI transactions MUST specify error handling for each transaction. Thorough error condition descriptions and handling instructions will greatly aid interoperability efforts between the PKI and VPN System products.
VPN-PKI事务的协议必须为每个事务指定错误处理。完整的错误条件描述和处理说明将极大地帮助PKI和VPN系统产品之间的互操作性工作。
This section refers to the [A] elements labeled in Figure 3.
本节涉及图3中标记的[A]元素。
One protocol MUST be specified for the Admin to PKI (RA/CA) interactions. This protocol MUST support privacy, authorization, authentication, and integrity. PKCs for authorization of the Admin can be initialized through an out-of-band mechanism.
必须为管理员到PKI（RA/CA）交互指定一个协议。此协议必须支持隐私、授权、身份验证和完整性。管理员授权的PKC可以通过带外机制初始化。
The transport used to carry the authorization SHOULD be reliable (TCP).
用于传输授权的传输应该是可靠的（TCP）。
The protocol SHOULD be as lightweight as possible.
协议应尽可能轻量级。
Bulk authorization MUST be supported by the certificate management profile. Bulk authorization occurs when the Admin requests of the PKI that authorization be established for several different subjects with almost the same contents. A minimum of one value (more is also acceptable) differs per subject. Because the authorizations may occur before any keys have been generated, the only way to ensure unique authorization identifiers are issued is to have at least one value differ per subject.
证书管理配置文件必须支持批量授权。当管理员请求PKI为几个内容几乎相同的不同主题建立授权时，就会发生批量授权。每个受试者至少有一个值（也可接受多个值）不同。由于授权可能发生在生成任何密钥之前，因此确保发出唯一授权标识符的唯一方法是每个主题至少有一个不同的值。
Authorization can occur prior to a PKC enrollment request, or the authorization and the PKC enrollment request can be presented to the PKI at the same time. Both of these authorization scenarios MUST be supported.
授权可以发生在PKC注册请求之前，或者授权和PKC注册请求可以同时提交给PKI。必须支持这两种授权方案。
A bulk authorization SHOULD occur in one single connection to the PKI (RA/CA), with the number of subjects being one or greater. Implementations SHOULD be able to handle one thousand subjects in a batch authorization.
批量授权应在与PKI（RA/CA）的单个连接中进行，主体数量为一个或多个。实现应该能够在批授权中处理1000个主题。
The authorization scenario for VPN-PKI transactions involves a two-step process: an authorization request and an authorization response. Figure 4 shows the salient interactions to perform authorization transactions.
VPN-PKI事务的授权场景包括两个步骤：授权请求和授权响应。图4显示了执行授权事务的显著交互。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
| 1
2 |
v
+-------+
| Admin |
+-------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
| 1
2 |
v
+-------+
| Admin |
+-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 4. Authorization Transactions
图4。授权交易
1) Authorization Request [A]. Admin sends a list of identities and PKC contents for the PKI System to authorize enrollment. See Section 3.2.4.
1) 授权请求[A]。管理员发送PKI系统的身份和PKC内容列表以授权注册。见第3.2.4节。
2) Authorization Response [A]. The PKI returns a list of unique authorization identifiers and one-time authorization tokens to be used for the enrollment of each PKC (1). Response may indicate success, failure, or errors for any particular authorization. See Section 3.2.5.
2) 授权响应[A]。PKI返回用于注册每个PKC（1）的唯一授权标识符和一次性授权令牌的列表。响应可能表示任何特定授权的成功、失败或错误。见第3.2.5节。
The Admin authorizes individual PKCs or batches of PKC issuances based on a pre-agreed template. This template is agreed by the VPN Operator and PKI Operator and is referred to in each authorization request. This allows the authorization requests to include the minimal amount of information necessary to support a VPN System.
管理员根据预先商定的模板授权单个PKC或批量PKC发行。该模板经VPN运营商和PKI运营商同意，并在每个授权请求中引用。这允许授权请求包含支持VPN系统所需的最少信息量。
The Admin can send the PKI System the set of PKC contents that it wants the PKI to issue to a group of IPsec Peers. In other words, it tells the PKI System, "if you see a PKC request that looks like this, from this person, process it and issue the PKC."
管理员可以向PKI系统发送它希望PKI发布给一组IPsec对等方的PKC内容集。换句话说，它告诉PKI系统，“如果您看到一个类似于此的PKC请求，请从此人处处理该请求并发出PKC。”
Requirements for PKC fields used in IPsec transactions are specified in [IKECERTPROFILE].
[IKECERTPROFILE]中规定了IPsec事务中使用的PKC字段的要求。
Requirements for PKC fields used in VPN-PKI transactions are specified in Section 3.1.6.
第3.1.6节规定了VPN-PKI交易中使用的PKC字段的要求。
When the VPN Operator and PKI Operator pre-agree on a template, they MUST also agree on the local policy regarding PKC renewal and PKC update. These are:
当VPN运营商和PKI运营商预先商定模板时，他们还必须就PKC续订和PKC更新的本地政策达成一致。这些是：
- Admin MUST specify if automatic renewals are allowed, that is, the Admin authorizes the PKI to process a future renewal for the specified Peer PKC.
- 管理员必须指定是否允许自动续订，即管理员授权PKI处理指定对等PKC的未来续订。
- Admin MUST specify if PKC update is allowed, that is, the Admin authorizes the PKI to accept a future request for a new PKC with changes to non-key-related fields.
- 管理员必须指定是否允许PKC更新，也就是说，管理员授权PKI接受将来对非密钥相关字段进行更改的新PKC请求。
If a PKC renewal is authorized, the Admin MUST further specify:
如果授权PKC续订，管理员必须进一步指定：
- Who can renew, that is, can only the Admin send a renewal request or can the Peer send a request directly to the PKI, or either.
- 谁可以续订，也就是说，只有管理员可以发送续订请求，或者对等方可以直接向PKI发送请求，或者两者都可以。
- How long before the PKC expiration date the PKI will accept and process a renewal (i.e., N% of validity period, or the UTC time after which renewal is permitted).
- PKC到期日前多长时间PKI将接受并处理续约（即有效期的N%，或允许续约的UTC时间）。
If a PKC update is authorized, the Admin MUST further specify:
如果授权PKC更新，管理员必须进一步指定：
- The aspects of non-key-related fields that are changeable.
- 可更改的非关键相关字段的方面。
- The entity that can send the PKC Update request, that is, only the Admin, only the Peer, or either.
- 可以发送PKC更新请求的实体，即仅管理员、对等方或两者之一。
- How long before the PKC expiration date the PKI will accept and process an update (i.e., N% of validity period, or the UTC time after which update is permitted).
- PKC到期日前多长时间PKI将接受并处理更新（即有效期的N%，或允许更新的UTC时间）。
A new authorization by the Admin is REQUIRED for PKC rekey. No parameters of prior authorizations need be considered.
PKC重新密钥需要管理员的新授权。无需考虑先前授权的参数。
The Admin MUST have the ability to specify the format for the authorization ID and one-time authorization token. The one-time authorization token SHOULD be unique per authorization ID. The more randomness that can be achieved in the relationship between an authorization ID and its one-time authorization token, the better. The one-time authorization token MUST be in UTF-8 format to avoid
管理员必须能够指定授权ID和一次性授权令牌的格式。每个授权ID的一次性授权令牌应该是唯一的。授权ID与其一次性授权令牌之间的关系越随机越好。一次性授权令牌必须为UTF-8格式，以避免
incompatibilities that may occur due to international characters. It MUST support normalization as in [CERTPROFILE]. The Admin MUST have the ability to constrain the UTF-8 character set.
国际字符可能导致的不兼容。它必须支持[CERTPROFILE]中的规范化。管理员必须能够约束UTF-8字符集。
There MUST be an option to specify a validation period for the authorization ID and its one-time authorization token. If such a validation period is set, any PKC requests using the authorization ID and one-time authorization token that arrive at the PKI outside of the validation period MUST be dropped, and the event logged.
必须有一个选项来指定授权ID及其一次性授权令牌的验证期。如果设置了此验证期，则必须丢弃在验证期之外到达PKI的任何使用授权ID和一次性授权令牌的PKC请求，并记录事件。
The Protocol SHOULD consider what happens when Admin-requested information conflicts with PKI settings such that the Admin request cannot be issued as requested (e.g., Admin requests validation period = 3 weeks and CA is configured to only allow validation periods = 1 week). Proper conflict handling MUST be specified.
该协议应该考虑当管理员请求的信息与PKI设置冲突时发生的情况，使得不能按照请求发出管理请求（例如，管理请求验证周期＝3周，而CA被配置为仅允许验证周期＝1周）。必须指定正确的冲突处理。
Either the Admin or the Peer can send a cancel authorization message to PKI. The canceling entity MUST provide the authorization ID and one-time authorization token in order to cancel the authorization. At that point, the authorization will be erased from the PKI, and a log entry of the event written.
管理员或对等方都可以向PKI发送取消授权消息。取消实体必须提供授权ID和一次性授权令牌才能取消授权。此时，授权将从PKI中删除，并写入事件的日志条目。
After the cancellation has been verified (a Cancel, Cancel ACK, ACK type of a process is REQUIRED to cover a lost connections scenario), the PKI will accept a new authorization request with the exact same contents as the canceled one, except that the identifier MUST be new. The PKI MUST NOT process duplicate authorization requests.
验证取消后（需要进程的Cancel、Cancel ACK、ACK类型来覆盖断开连接的情况），PKI将接受新的授权请求，其内容与被取消的授权请求完全相同，但标识符必须是新的。PKI不得处理重复的授权请求。
Note that if the PKI has already issued a PKC associated with an authorization, then cancellation of the authorization is not possible and the authorization request SHOULD be refused by the PKI. Once a PKC has been issued it MUST be revoked in accordance with Section 3.6.
请注意，如果PKI已发布与授权相关的PKC，则无法取消授权，并且PKI应拒绝授权请求。一旦签发PKC，必须按照第3.6节的规定撤销PKC。
If the authorization request is acceptable, the PKI will respond to the Admin with a unique authorization identifier per subject authorization requested and a one-time authorization token per authorization ID. See Section 3.2.4.3 for additional authorization ID and one-time authorization token requirements.
如果授权请求可接受，PKI将对管理员作出响应，每个请求的主体授权使用唯一授权标识符，每个授权ID使用一次性授权令牌。有关其他授权ID和一次性授权令牌要求，请参见第3.2.4.3节。
The PKI can alter parameters of the authorization request submitted by the Admin. In that event, the PKI MUST return all the contents of the authorization request (as modified) to the Admin with the confirmation of authorization success. This will allow the Admin to
PKI可以更改管理员提交的授权请求的参数。在这种情况下，PKI必须将授权请求（修改后）的所有内容返回给管理员，并确认授权成功。这将允许管理员
perform an "operational test" to verify that the issued PKCs will meet its requirements. If the Admin determines that the modified parameters are unacceptable, then the authorization should be cancelled in accordance with Section 3.2.4.4.
执行“运行测试”，以验证发布的PKC是否符合其要求。如果管理员确定修改的参数不可接受，则应根据第3.2.4.4节取消授权。
After receiving a bulk authorization request from the Admin, the PKI MUST be able to reply YES to those individual PKC authorizations that it has satisfied and NO or FAILED for those requests that cannot be satisfied, along with sufficient reason or error codes.
在收到管理员发出的批量授权请求后，PKI必须能够对其已满足的单个PKC授权回答“是”，对无法满足的请求回答“否”或“失败”，并附上充分的原因或错误代码。
A method is REQUIRED to identify if there is a change in PKI settings between the time the authorization is granted and the PKC request occurs, and what to do about the discrepancy.
需要一种方法来确定在授予授权和PKC请求发生之间PKI设置是否有变化，以及如何处理差异。
Thorough error condition descriptions and handling instructions MUST be provided to the Admin for each transaction in the authorization process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products.
对于授权过程中的每个事务，必须向管理员提供完整的错误条件描述和处理说明。提供此类错误代码将极大地帮助PKI和IPsec产品之间的互操作性工作。
This section refers to the [G] elements labeled in Figure 3.
本节涉及图3中标记的[G]元素。
Once the PKI System has responded with authorization identifiers and authorization tokens (see Section 3.2), and this information is received at the Admin, the next step is to generate public and private key pairs and to construct PKC requests using those key pairs. The key generations can occur at one of three places, depending on local requirements: at the IPsec Peer, at the Admin, or at the PKI. The PKC request can come from either the IPsec Peer, a combination of the Peer and the Admin, or not at all.
一旦PKI系统响应了授权标识符和授权令牌（见第3.2节），并且管理员收到了该信息，下一步就是生成公钥和私钥对，并使用这些密钥对构造PKC请求。密钥生成可以发生在三个位置之一，具体取决于本地需求：IPsec对等方、管理员或PKI。PKC请求可以来自IPsec对等方（对等方和管理员的组合），也可以根本不来自。
3.3.1. Generation Method 1: IPsec Peer Generates Key Pair, Constructs PKC Request, and Signs PKC Request
3.3.1. 生成方法1：IPsec对等方生成密钥对，构造PKC请求，并对PKC请求进行签名
This option will be used most often in the field. This is the most secure method for keying, as the keys are generated on the end entity and the private key never leaves the end entity. However, it is the most computationally intensive for the Peer, as it must be "ASN.1 aware" to support generating and digitally signing the PKC request.
此选项将在现场最常用。这是最安全的密钥设置方法，因为密钥是在最终实体上生成的，私钥永远不会离开最终实体。然而，它对对等方来说是计算最密集的，因为它必须是“ASN.1感知”的，才能支持生成PKC请求并对其进行数字签名。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+-------+
+------>| Admin |
| +-------+
|
| 1
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+-------+
+------>| Admin |
| +-------+
|
| 1
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 5. Generation Interactions: IPsec Peer Generates Key Pair and Constructs PKC Request
图5。生成交互：IPsec对等方生成密钥对并构造PKC请求
1) Opaque transaction [G]. Admin sends authorization identifier, one-time authorization token, and any other parameters needed by the Peer to generate the PKC request, including key type and size.
1) 不透明交易[G]。管理员发送授权标识符、一次性授权令牌以及对等方生成PKC请求所需的任何其他参数，包括密钥类型和大小。
2) Generation [G]. Peer receives authorization identifier, one-time authorization token, and any parameters. Peer generates key pair and constructs PKC request.
2) 代[G]。对等方接收授权标识符、一次性授权令牌和任何参数。对等方生成密钥对并构造PKC请求。
Steps prior to these can be found in Section 3.2. The next step, enrollment, can occur either directly between the Peer and PKI (see Section 3.4.5) or through the Admin (see Section 3.4.6).
上述步骤见第3.2节。下一步，注册，可以直接在对等方和PKI之间进行（参见第3.4.5节），也可以通过管理员进行（参见第3.4.6节）。
3.3.2. Generation Method 2: IPsec Peer Generates Key Pair, Admin Constructs PKC Request, Admin Signs PKC Request
3.3.2. 生成方法2：IPsec对等方生成密钥对，管理员构造PKC请求，管理员签名PKC请求
This option also supports IPsec Peer generation of a key pair, but removes the requirement for the Peer to be ASN.1 aware because it does not have to construct or digitally sign the PKC request. The drawback is that the key pair does need to be provided to the Admin. In the most probable cases where the Admin function is remotely located from the peer, this means that the private key will leave the cryptographic boundary of the peer, which is a significant security trade-off consideration. Whenever possible, it is always better to have private keys generated and never leave the cryptographic boundary of the generating system.
此选项还支持IPsec对等方生成密钥对，但不需要对等方感知ASN.1，因为它不必构造PKC请求或对PKC请求进行数字签名。缺点是需要将密钥对提供给管理员。在最有可能的情况下，管理功能远离对等方，这意味着私钥将离开对等方的加密边界，这是一个重要的安全权衡考虑。只要可能，最好生成私钥，并且永远不要离开生成系统的加密边界。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
3 +-------+
+------>| Admin | 4
| +-------+
|
| 1
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
3 +-------+
+------>| Admin | 4
| +-------+
|
| 1
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 6. Generation Interactions: IPsec Peer Generates Key Pair, Admin Constructs PKC Request
图6。生成交互：IPsec对等方生成密钥对，管理员构造PKC请求
1) Opaque transaction [G]. Admin sends command to Peer to generate key pair, based on parameters provided in the command.
1) 不透明交易[G]。管理员根据命令中提供的参数向对等方发送命令以生成密钥对。
2) Generation [G]. Peer generates key pair.
2) 代[G]。对等方生成密钥对。
3) Opaque transaction [G]. Peer returns key pair to Admin.
3) 不透明交易[G]。对等方将密钥对返回给管理员。
4) Generation [G]. Admin constructs and digitally signs PKC request.
4) 代[G]。管理员构造PKC请求并对其进行数字签名。
Steps prior to these can be found in Section 3.2. The next step, enrollment, occurs through the Admin (see Section 3.4.7).
上述步骤见第3.2节。下一步，注册，通过管理员进行（见第3.4.7节）。
3.3.3. Generation Method 3: Admin Generates Key Pair, Constructs PKC Request, and Signs PKC Request
3.3.3. 生成方法3：管理员生成密钥对，构造PKC请求，并对PKC请求进行签名
This option exists for deployments where Peers cannot generate their own key pairs. Some examples are for PDAs and handsets where to generate an RSA key would be operationally impossible due to processing and battery constraints. Another case covers key recovery requirements, where the same PKCs are used for other functions in addition to IPsec, and key recovery is required (e.g., local data encryption), therefore key escrow is needed from the Peer. If key escrow is performed then the exact requirements and procedures for it are beyond the scope of this document.
此选项适用于对等方无法生成自己的密钥对的部署。一些示例适用于PDA和手机，由于处理和电池限制，无法生成RSA密钥。另一种情况涉及密钥恢复要求，在这种情况下，除了IPsec之外，相同的PKC还用于其他功能，并且需要密钥恢复（例如，本地数据加密），因此需要从对等方托管密钥。如果执行密钥托管，则其确切要求和程序超出本文件的范围。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+-------+
| Admin | 1
+-------+
+-------+
| Admin | 1
+-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 7. Generation Interactions: Admin Generates Key Pair and Constructs PKC Request
图7。生成交互：管理员生成密钥对并构造PKC请求
1) Generation [G]. Admin generates key pair, constructs PKC request, and digitally signs PKC request.
1) 代[G]。管理员生成密钥对，构造PKC请求，并对PKC请求进行数字签名。
Steps prior to these can be found in Section 3.2. The next step, enrollment, occurs through the Admin (see Section 3.4.8).
上述步骤见第3.2节。下一步，注册，通过管理员进行（见第3.4.8节）。
Note that separate authorizations steps are still of value even though the Admin is also performing the key generation. The PKC template, Subject fields, SubjectAltName fields, and more are part of the request, and must be communicated in some way from the Admin to the PKI. Instead of creating a new mechanism, the authorization schema can be reused. This also allows for the feature of role-based
请注意，即使管理员也在执行密钥生成，单独的授权步骤仍然有价值。PKC模板、主题字段、主题名称字段等都是请求的一部分，必须以某种方式从管理员传递到PKI。授权模式可以重用，而不是创建新的机制。这也允许基于角色的功能
administration, where Operator 1 is the only one allowed to have the Admin function pre-authorize PKCs, but Operator 2 is the one doing batch enrollments and VPN device configurations.
管理，其中运营商1是唯一允许使用管理功能预授权PKCs的运营商，但运营商2是进行批量注册和VPN设备配置的运营商。
This option exists for deployments where end entities cannot generate their own key pairs and the Admin function is a minimal implementation. The PKI and Admin pre-agree to have the PKI generate key pairs and PKCs. This is, in all likelihood, the easiest way to deploy PKCs, though it sacrifices some security since both the CA and the Admin have access to the private key. However, in cases where key escrow is required, this may be acceptable. The Admin effectively acts as a proxy for the Peer in the PKC enrollment process.
此选项适用于终端实体无法生成自己的密钥对且管理功能是最小实现的部署。PKI和管理员预先同意让PKI生成密钥对和PKC。这很可能是部署PKC的最简单方法，尽管它牺牲了一些安全性，因为CA和管理员都可以访问私钥。但是，在需要密钥托管的情况下，这是可以接受的。管理员在PKC注册过程中有效地充当对等方的代理。
+--------------+ +-----------------------+
| Repository | | CA/RA | 1
+--------------+ +-----------------------+
+--------------+ +-----------------------+
| Repository | | CA/RA | 1
+--------------+ +-----------------------+
+-------+
| Admin |
+-------+
+-------+
| Admin |
+-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 8. Generation Interactions: IPsec Peer Generates Key Pair, Admin Constructs PKC Request
图8。生成交互：IPsec对等方生成密钥对，管理员构造PKC请求
1) Generation [G] The PKI generates the key pair.
1) 生成[G]PKI生成密钥对。
Steps prior to these can be found in Section 3.2. The next step, enrollment, occurs through the Admin (see Section 3.4.9).
上述步骤见第3.2节。下一步，注册，通过管理员进行（见第3.4.9节）。
Thorough error condition descriptions and handling instructions MUST be provided for each transaction in the key generation and PKC request construction process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products.
在密钥生成和PKC请求构造过程中，必须为每个事务提供彻底的错误条件描述和处理说明。提供此类错误代码将极大地帮助PKI和IPsec产品之间的互操作性工作。
Error conditions MUST be communicated to the Admin regardless of who generated the key or PKC request.
无论是谁生成了密钥或PKC请求，都必须将错误情况告知管理员。
This section refers to the [E] elements labeled in Figure 3.
本节涉及图3中标记的[E]元素。
Regardless of where the keys were generated and the PKC request constructed, an enrollment process will need to occur to request that the PKI issue a PKC and the corresponding PKC be returned.
无论密钥是在何处生成的，PKC请求是在何处构造的，都需要进行注册过程，以请求PKI颁发PKC并返回相应的PKC。
The protocol MUST be exactly the same regardless of whether the enrollment occurs from the Peer to the PKI or from the Admin to the PKI.
无论注册是从对等方到PKI还是从管理员到PKI，协议都必须完全相同。
One protocol MUST be specified for enrollment requests, responses, and confirmations.
必须为注册请求、响应和确认指定一个协议。
The protocol MUST support enrollment that occurs over the Internet and without the need for manual intervention.
协议必须支持通过Internet进行的注册，无需手动干预。
Enrollment requests and responses MUST be able to occur in one on-line connection between the Admin on behalf of the Peer or the Peer itself and the PKI (RA/CA).
注册请求和响应必须能够在管理员代表对等方或对等方本身与PKI（RA/CA）之间的一个在线连接中发生。
Manual approval of PKC enrollments is too time consuming for large scale implementations, and is therefore not required.
手动批准PKC注册对于大规模实施来说太耗时，因此不需要。
In this case, the IPsec Peer only communicates with the PKI after being commanded to do so by the Admin. This enrollment mode is depicted in Figure 9 and the letters in the following description refer to Figure 3. Prior authorization (Section 3.2) and generation (Section 3.3.1) steps are not shown.
在这种情况下，IPsec对等方仅在收到管理员的命令后才与PKI通信。此注册模式如图9所示，以下描述中的字母参考图3。未显示事先授权（第3.2节）和生成（第3.3.1节）步骤。
Most IPsec Systems have enough CPU power to generate a public and private key pair of sufficient strength for secure IPsec. In this case, the end entity needs to prove to the PKI that it has such a key pair; this is normally done by the PKI sending the end entity a nonce, which the end entity signs and returns to the Admin along with the end entity's public key.
大多数IPsec系统都有足够的CPU能力来生成足够强度的公钥和私钥对，以实现安全的IPsec。在这种情况下，终端实体需要向PKI证明其具有这样的密钥对；这通常由PKI向终端实体发送一个nonce来完成，该nonce由终端实体签名并与终端实体的公钥一起返回给管理员。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
1,3 |
|
|
| +-------+
| | Admin |
| +-------+
|
2,4 |
v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
1,3 |
|
|
| +-------+
| | Admin |
| +-------+
|
2,4 |
v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 9. VPN-PKI Interaction Steps: IPsec Peer Generates Keys and PKC Request, Enrolls Directly with PKI
图9。VPN-PKI交互步骤：IPsec对等方生成密钥和PKC请求，直接使用PKI注册
1) Enrollment Request [E]. The IPsec Peer sends PKC requests to the PKI, providing the generated public key.
1) 注册申请[E]。IPsec对等方向PKI发送PKC请求，提供生成的公钥。
2) Enrollment Response [E]. The PKI responds to the enrollment request, providing either the new PKC that was generated or a suitable error indication.
2) 注册响应[E]。PKI响应注册请求，提供生成的新PKC或适当的错误指示。
3) Enrollment Confirmation [E]. Peer positively acknowledges receipt of new PKC back to the Admin.
3) 注册确认[E]。对等方向管理员确认收到新的PKC。
4) Enrollment Confirmation Receipt [E]. PKI sends enrollment confirmation receipt back to the Peer.
4) 注册确认收据[E]。PKI将注册确认回执发送回对等方。
In this case, the IPsec Peer has generated the key pair and the PKC request, but does not enroll directly to the PKI System. Instead, it automatically sends its request to the Admin, and the Admin redirects the enrollment to the PKI System. The PKI System does not care where the enrollment comes from, as long as it is a valid enrollment. Once the Admin receives the PKC response, it automatically forwards it to the IPsec Peer.
在这种情况下，IPsec对等方已生成密钥对和PKC请求，但不直接注册到PKI系统。相反，它会自动向管理员发送请求，管理员会将注册重定向到PKI系统。只要注册有效，PKI系统就不关心注册来自何处。管理员收到PKC响应后，会自动将其转发给IPsec对等方。
Most IPsec Systems have enough CPU power to generate a public and private key pair of sufficient strength for secure IPsec. In this case, the end entity needs to prove to the Admin that it has such a key pair; this is normally done by the Admin sending the end entity a nonce, which the end entity signs and returns to the Admin along with the end entity's public key.
大多数IPsec系统都有足够的CPU能力来生成足够强度的公钥和私钥对，以实现安全的IPsec。在这种情况下，终端实体需要向管理员证明它有这样一个密钥对；这通常由管理员向终端实体发送一个nonce来完成，该nonce由终端实体签名并与终端实体的公钥一起返回给管理员。
This enrollment mode is depicted in Figure 10 and the letters in the following description refer to Figure 3. Prior authorization (Section 3.2) and generation (Section 3.3.1) steps are not shown.
此注册模式如图10所示，以下描述中的字母参考图3。未显示事先授权（第3.2节）和生成（第3.3.1节）步骤。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 2,6
|
|
v 3,7
1,5 +-------+
+> | Admin |
| +-------+
|
|
4,8 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 2,6
|
|
v 3,7
1,5 +-------+
+> | Admin |
| +-------+
|
|
4,8 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 10. VPN-PKI Interaction Steps: IPsec Peer Generates Keys and PKC Request, Enrolls Through Admin
图10。VPN-PKI交互步骤：IPsec对等方生成密钥和PKC请求，通过管理员注册
1) Opaque Transaction [E]. The IPsec Peer requests a PKC from the Admin, providing the generated public key.
1) 不透明交易[E]。IPsec对等方向管理员请求PKC，并提供生成的公钥。
2) Enrollment Request [E]. The Admin forwards the enrollment request to the PKI.
2) 注册申请[E]。管理员将注册请求转发给PKI。
3) Enrollment Response [E]. The PKI responds to the enrollment request, providing either the new PKC that was generated or a suitable error indication.
3) 注册响应[E]。PKI响应注册请求，提供生成的新PKC或适当的错误指示。
4) Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer.
4) 不透明交易[E]。管理员将注册响应转发回IPsec对等方。
5) Opaque Transaction [E]. Peer positively acknowledges receipt of new PKC back to the Admin.
5) 不透明交易[E]。对等方向管理员确认收到新的PKC。
6) Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI.
6) 注册确认[E]。管理员将注册确认转发回PKI。
7) Enrollment Confirmation Receipt [E]. PKI sends enrollment confirmation receipt back to the Admin.
7) 注册确认收据[E]。PKI将注册确认回执发送回管理员。
8) Opaque Transaction [E]. Admin forwards PKI's enrollment confirmation receipt back to the Peer.
8) 不透明交易[E]。管理员将PKI的注册确认回执转发回对等方。
In this case, the IPsec Peer has generated the key pair, but the PKC request is constructed and signed by the Admin. The PKI System does not care where the enrollment comes from, as long as it is a valid enrollment. Once the Admin retrieves the PKC, it then automatically forwards it to the IPsec Peer along with the key pair.
在本例中，IPsec对等方已生成密钥对，但PKC请求由管理员构造和签名。只要注册有效，PKI系统就不关心注册来自何处。管理员检索到PKC后，会自动将其连同密钥对转发给IPsec对等方。
Some IPsec Systems do not have enough CPU power to generate a public and private key pair of sufficient strength for secure IPsec. In this case, the Admin needs to prove to the PKI that it has such a key pair; this is normally done by the PKI sending the Admin a nonce, which the Admin signs and returns to the PKI along with the end entity's public key. A drawback to this case is that the private key will eventually be sent over the wire (though hopefully securely so) from Admin to the IPsec Peer; whenever possible, it is preferred to keep a key within its cryptographic boundary of origin. Failing to do so opens the system to risk of the private keys being sniffed and discerned.
一些IPsec系统没有足够的CPU能力来生成足够强度的公钥和私钥对以实现安全的IPsec。在这种情况下，管理员需要向PKI证明它有这样一个密钥对；这通常是由PKI向管理员发送一个nonce来完成的，管理员对该nonce进行签名并将其与最终实体的公钥一起返回给PKI。这种情况的一个缺点是私钥最终将通过线路（尽管希望安全地）从Admin发送到IPsec对等方；只要可能，最好将密钥保持在其原始加密边界内。否则，系统将面临私钥被嗅探和识别的风险。
This enrollment mode is depicted in Figure 11 and the letters in the following description refer to Figure 3. Prior authorization (Section 3.2) and generation (Section 3.3.2) steps are not shown.
此注册模式如图11所示，以下描述中的字母参考图3。未显示事先授权（第3.2节）和生成（第3.3.2节）步骤。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 11. VPN-PKI Interaction Steps: IPsec Peer Generates Keys, Admin Constructs and Signs PKC Request, Enrolls through Admin
图11。VPN-PKI交互步骤：IPsec对等方生成密钥，管理员构造并签署PKC请求，通过管理员注册
1) Enrollment Request [E]. The Admin requests a PKC from the PKI, providing the generated public key.
1) 注册申请[E]。管理员从PKI请求PKC，并提供生成的公钥。
2) Enrollment Response [E]. The PKI responds to the enrollment request, providing either the new PKC that was generated or a suitable error indication.
2) 注册响应[E]。PKI响应注册请求，提供生成的新PKC或适当的错误指示。
3) Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer.
3) 不透明交易[E]。管理员将注册响应转发回IPsec对等方。
4) Opaque Transaction [E]. Peer positively acknowledges receipt of new PKC back to the Admin.
4) 不透明交易[E]。对等方向管理员确认收到新的PKC。
5) Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI.
5) 注册确认[E]。管理员将注册确认转发回PKI。
6) Enrollment Confirmation Receipt [E]. PKI sends enrollment confirmation receipt back to the Admin.
6) 注册确认收据[E]。PKI将注册确认回执发送回管理员。
7) Opaque Transaction [E]. Admin forwards PKI's enrollment confirmation receipt back to the Peer.
7) 不透明交易[E]。管理员将PKI的注册确认回执转发回对等方。
3.4.8. Enrollment Method 3a: Admin Authorizes and Enrolls Directly to PKI
3.4.8. 注册方法3a：管理员直接授权并注册到PKI
In this case, the Admin generates the key pair, PKC request, and digitally signs the PKC request. The PKI System does not care where the enrollment comes from, as long as it is a valid enrollment. Once the Admin retrieves the PKC, it then automatically forwards it to the IPsec Peer along with the key pair.
在这种情况下，管理员生成密钥对PKC请求，并对PKC请求进行数字签名。只要注册有效，PKI系统就不关心注册来自何处。管理员检索到PKC后，会自动将其连同密钥对转发给IPsec对等方。
Some IPsec Systems do not have enough CPU power to generate a public and private key pair of sufficient strength for secure IPsec. In this case, the Admin needs to prove to the PKI that it has such a key pair; this is normally done by the PKI sending the Admin a nonce, which the Admin signs and returns to the PKI along with the end entity's public key. A drawback to this case is that the private key will eventually be sent over the wire (though hopefully securely so) from Admin to the IPsec Peer; whenever possible, it is preferred to keep a key within its cryptographic boundary of origin. Failing to do so opens the system to risk of the private keys being sniffed and discerned.
一些IPsec系统没有足够的CPU能力来生成足够强度的公钥和私钥对以实现安全的IPsec。在这种情况下，管理员需要向PKI证明它有这样一个密钥对；这通常是由PKI向管理员发送一个nonce来完成的，管理员对该nonce进行签名并将其与最终实体的公钥一起返回给PKI。这种情况的一个缺点是私钥最终将通过线路（尽管希望安全地）从Admin发送到IPsec对等方；只要可能，最好将密钥保持在其原始加密边界内。否则，系统将面临私钥被嗅探和识别的风险。
This enrollment mode is depicted in Figure 12 and the letters in the following description refer to Figure 3. Prior authorization (Section 3.2) and generation (Section 3.3.3) steps are not shown.
此注册模式如图12所示，以下描述中的字母参考图3。未显示事先授权（第3.2节）和生成（第3.3.3节）步骤。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 12. VPN-PKI Interaction Steps: Admin Generates Keys and PKC Request, and Enrolls Directly with PKI
图12。VPN-PKI交互步骤：管理员生成密钥和PKC请求，并直接使用PKI注册
1) Enrollment Request [E]. The Admin requests a PKC from the PKI, providing the generated public key.
1) 注册申请[E]。管理员从PKI请求PKC，并提供生成的公钥。
2) Enrollment Response [E]. The PKI responds to the enrollment request, providing either the new PKC that was generated or a suitable error indication.
2) 注册响应[E]。PKI响应注册请求，提供生成的新PKC或适当的错误指示。
3) Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer, along with the keys.
3) 不透明交易[E]。管理员将注册响应连同密钥一起转发回IPsec对等方。
4) Opaque Transaction [E]. Peer positively acknowledges receipt of new PKC back to the Admin.
4) 不透明交易[E]。对等方向管理员确认收到新的PKC。
5) Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI.
5) 注册确认[E]。管理员将注册确认转发回PKI。
6) Enrollment Confirmation Receipt [E]. PKI sends enrollment confirmation receipt back to the Admin.
6) 注册确认收据[E]。PKI将注册确认回执发送回管理员。
7) Opaque Transaction [E]. Admin forwards PKI's enrollment confirmation receipt back to the Peer.
7) 不透明交易[E]。管理员将PKI的注册确认回执转发回对等方。
3.4.9. Enrollment Method 3b: Admin Requests and PKI Generates and Sends PKC
3.4.9. 注册方法3b：管理员请求和PKI生成并发送PKC
In this instance, the PKI and Admin have previously agreed to have the PKI generate keys and certificates when the PKI receives an authorization request. The PKI returns to the IPsec Peer through the Admin, the final product of a key pair and PKC. Again, the mechanism for the Peer to Admin communication is opaque.
在本例中，PKI和管理员先前已同意在PKI收到授权请求时让PKI生成密钥和证书。PKI通过Admin（密钥对和PKC的最终产品）返回到IPsec对等方。同样，对等管理通信的机制是不透明的。
A drawback to this case is that the private key will eventually be sent over the wire (though hopefully securely so) from Admin to the IPsec Peer; whenever possible, it is preferred to keep a key within its cryptographic boundary of origin. Failing to do so opens the system to risk of the private keys being sniffed and discerned.
这种情况的一个缺点是私钥最终将通过线路（尽管希望安全地）从Admin发送到IPsec对等方；只要可能，最好将密钥保持在其原始加密边界内。否则，系统将面临私钥被嗅探和识别的风险。
This enrollment mode is depicted in Figure 13 and the letters in the following description refer to Figure 3. Prior authorization (Section 3.2) and generation (Section 3.3.4) steps are not shown.
此注册模式如图13所示，以下描述中的字母参考图3。未显示事先授权（第3.2节）和生成（第3.3.4节）步骤。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 4
|
|
v 1,5
3 +-------+
+->| Admin |
| +-------+
|
|
2,6 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 4
|
|
v 1,5
3 +-------+
+->| Admin |
| +-------+
|
|
2,6 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 13. VPN-PKI Interaction Steps: PKI Generates Keys, PKC Request, and Enrolls Directly with PKI
图13。VPN-PKI交互步骤：PKI生成密钥，PKC请求，直接与PKI注册
1) Enrollment Response [E]. The PKI responds to the authorization request sent, providing either the new PKC and public-private key pair that were generated or a suitable error indication.
1) 注册响应[E]。PKI响应发送的授权请求，提供生成的新PKC和公私密钥对或适当的错误指示。
2) Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer, along with the keys.
2) 不透明交易[E]。管理员将注册响应连同密钥一起转发回IPsec对等方。
3) Opaque Transaction [E]. Peer positively acknowledge receipt of new PKC back to the Admin.
3) 不透明交易[E]。对等方向管理员确认收到新的PKC。
4) Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI.
4) 注册确认[E]。管理员将注册确认转发回PKI。
5) Enrollment Confirmation Receipt [E]. PKI sends enrollment confirmation receipt back to the Admin.
5) 注册确认收据[E]。PKI将注册确认回执发送回管理员。
6) Opaque Transaction [E]. Admin forwards PKI's enrollment confirmation receipt back to the Peer.
6) 不透明交易[E]。管理员将PKI的注册确认回执转发回对等方。
Any time a new PKC is issued by the PKI, a confirmation of PKC receipt MUST be sent back to the PKI by the Peer or the Admin (forwarding the Peer's confirmation).
每当PKI发布新的PKC时，对等方或管理员必须向PKI发送PKC接收确认（转发对等方确认）。
Operationally, the Peer MUST send a confirmation to the PKI verifying that it has received the PKC, loaded it, and can use it effectively in an IKE exchange. This requirement exists so that:
在操作上，对等方必须向PKI发送确认，确认其已收到PKC、已加载PKC，并且可以在IKE交换中有效使用PKC。这一要求的存在是为了：
- The PKI does not publish the new PKC in the repository for others until that PKC is able to be used effectively by the Peer, and
- PKI不会在存储库中为其他人发布新的PKC，直到对等方能够有效使用该PKC，并且
- A revocation may be invoked if the PKC is not received and operational within an allowable window of time.
- 如果PKC未在允许的时间窗口内收到和运行，则可以调用撤销。
To assert such proof, the Peer MUST sign a portion of data with the new key. The result MUST be sent to the PKI. The entity that actually sends the result to the PKI MAY be either the Peer (sending it directly to the PKI) or Admin (the Peer would send it to Admin, and Admin can, in turn, send it to the PKI).
要断言这样的证明，对等方必须使用新密钥对部分数据进行签名。结果必须发送到PKI。实际将结果发送到PKI的实体可能是对等方（直接发送到PKI）或管理员（对等方将其发送到管理员，而管理员可以反过来将其发送到PKI）。
The Admin MUST acknowledge the successful receipt of the confirmation, thus signaling to the Peer that it may proceed using this PKC in IKE connections. The PKI MUST complete all the processing necessary to enable the Peer's operational use of the new PKC (for example, writing the PKC to the repository) before sending the confirmation acknowledgement. The Peer MUST NOT begin using the PKC until the PKI's confirmation acknowledgement has been received.
管理员必须确认成功接收到确认，从而向对等方发出信号，表示可以继续在IKE连接中使用此PKC。在发送确认确认之前，PKI必须完成所有必要的处理，以使对等方能够在操作上使用新的PKC（例如，将PKC写入存储库）。在收到PKI的确认之前，对等方不得开始使用PKC。
Thorough error condition descriptions and handling instructions are REQUIRED for each transaction in the enrollment process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products.
注册过程中的每个事务都需要完整的错误条件描述和处理说明。提供此类错误代码将极大地帮助PKI和IPsec产品之间的互操作性工作。
The profile will clarify what happens if the request and retrieval fails for some reason. The following cases MUST be covered:
概要文件将阐明如果请求和检索因某种原因失败会发生什么。必须涵盖以下情况：
- Admin or Peer cannot send the request.
- 管理员或对等方无法发送请求。
- Admin or Peer sent the request, but the PKI did not receive the request.
- 管理员或对等方发送了请求，但PKI未收到该请求。
- PKI received the request, but could not read it effectively.
- PKI收到了请求，但无法有效读取。
- PKI received and read the request, but some contents of the request violated the PKI's configured policy such that the PKI was unable to generate the PKC.
- PKI接收并读取请求，但请求的某些内容违反了PKI的配置策略，因此PKI无法生成PKC。
- The PKI System generated the PKC, but could not send it.
- PKI系统生成了PKC，但无法发送。
- The PKI sent the PKC, but the requestor (Admin or Peer) did not receive it.
- PKI发送了PKC，但请求者（管理员或对等方）没有收到它。
- The Requestor (Admin or Peer) received the PKC, but could not process it due to incorrect contents, or other PKC-construction-related problem.
- 请求者（管理员或对等方）收到了PKC，但由于内容不正确或其他与PKC构造相关的问题，无法对其进行处理。
- The Requestor failed trying to generate the confirmation.
- 请求者尝试生成确认失败。
- The Requestor failed trying to send the confirmation.
- 请求者尝试发送确认失败。
- The Requestor sent the confirmation, but the PKI did not receive it.
- 请求者发送了确认，但PKI没有收到。
- The PKI received the confirmation but could not process it.
- PKI已收到确认，但无法处理该确认。
In each case the following questions MUST be addressed:
在每种情况下，必须解决以下问题：
- What does Peer do? - What does Admin do? - What does PKI do? - Is Authorization used?
- Peer做什么管理员做什么PKI做什么是否使用授权？
If a failure occurs after the PKI sends the PKC and before the Peer receives it, then the Peer MUST re-request with the same authorization ID and one-time authorization token. The PKI, seeing the authorization ID and authorization token, MUST send the PKC again.
如果在PKI发送PKC之后和对等方收到PKC之前发生故障，则对等方必须使用相同的授权ID和一次性授权令牌重新请求。看到授权ID和授权令牌的PKI必须再次发送PKC。
Enrollment errors MUST be sent to the Admin regardless of the entity that generated the enrollment request.
无论生成注册请求的实体是什么，都必须将注册错误发送给管理员。
This section refers to the [L] elements labeled in Figure 3.
本节涉及图3中标记的[L]元素。
Once the PKI has issued a PKC for the end entity Peer, the Peer MUST be able to either contact the PKI directly or through the Admin for any subsequent rekeys, renewals, updates, or revocations. The PKI MUST support either case for renewals, updates, and revocations. Rekeys are Admin initiated; therefore, Peer initiated rekeys MUST be transferred via the Admin.
一旦PKI为终端实体对等方发布PKC，对等方必须能够直接或通过管理员联系PKI，以便进行任何后续的密钥更新、更新或撤销。PKI必须支持续订、更新和撤销这两种情况。密钥由管理员发起；因此，对等方发起的密钥必须通过管理员进行传输。
One protocol MUST be specified for rekey, renew, and update requests, responses, and confirmations. It MUST be the same protocol as is specified in Section 3.4.
必须为重设密钥、续订和更新请求、响应和确认指定一个协议。它必须与第3.4节规定的协议相同。
Revocation requests MAY use the same protocol as rekey, renew, and update operations. Revocation requests MAY also occur via email, telephone, Instant Messaging, etc.
撤销请求可以使用与重新密钥、续订和更新操作相同的协议。撤销请求也可能通过电子邮件、电话、即时消息等进行。
Rekeys, renewals, and updates are variants of a PKC enrollment request scenario with unique operational and management requirements.
密钥更新、续订和更新是PKC注册请求场景的变体，具有独特的操作和管理要求。
- A PKC rekey replaces an end entity's PKC with a new PKC that has a new public key for the same SubjectName and SubjectAltName contents before the end entity's currently held PKC expires.
- PKC重新密钥将最终实体的PKC替换为新的PKC，该PKC在最终实体当前持有的PKC到期之前具有相同SubjectName和SubjectAltName内容的新公钥。
- A PKC renewal replaces an end entity's PKC with the same public key for the same SubjectName and SubjectAlternativeName contents as an existing PKC before that PKC expires.
- 在PKC过期之前，PKC续订将使用与现有PKC相同的公钥替换最终实体的PKC，该公钥用于相同的SubjectName和SubjectAlternativeName内容。
- A PKC update is defined as a new PKC issuance with the same public key for an altered SubjectName or SubjectAlternativeName before expiration of the end entity's current PKC.
- PKC更新定义为在最终实体的当前PKC到期之前，为修改后的SubjectName或SubjectAlternativeName发行具有相同公钥的新PKC。
When sending rekey, renew, or update requests, the entire contents of the PKC request needs to be sent to the PKI, not just the changed elements.
发送重新密钥、续订或更新请求时，需要将PKC请求的全部内容发送到PKI，而不仅仅是更改的元素。
The rekey, renew, and update requests MUST be signed by the private key of the old PKC. This will allow the PKI to verify the identity of the requestor, and ensure that an attacker does not submit a request and receive a PKC with another end entity's identity.
重新密钥、续订和更新请求必须由旧PKC的私钥签名。这将允许PKI验证请求者的身份，并确保攻击者不会提交请求并接收具有另一个终端实体身份的PKC。
Whether or not a new key is used for the new PKC in a renew or update scenario is a matter of local security policy, and MUST be specified by the Admin to the PKI in the original authorization request. Reusing the same key is permitted, but not encouraged. If a new key is used, the update or renew request must be signed by both the old key -- to prove the right to make the request -- and the new key -- to use for the new PKC.
在续订或更新场景中，新PKC是否使用新密钥是本地安全策略的问题，必须由管理员在原始授权请求中指定给PKI。允许重复使用同一密钥，但不鼓励重复使用。如果使用了新密钥，则更新或续订请求必须由旧密钥（以证明有权发出请求）和新密钥（用于新PKC）签名。
The new PKC resulting from a rekey, renew, or update will be retrieved in-band, using the same mechanism as a new PKC request.
通过重新设置密钥、续订或更新生成的新PKC将使用与新PKC请求相同的机制在带内检索。
For the duration of time after a rekey, renew, or update has been processed and before PKI has received confirmation of the Peer's successful receipt of the new PKC, both PKCs (the old and the new) for the end entity will be valid. This will allow the Peer to continue with uninterrupted IKE connections with the previous PKC while the rekey, renewal, or update process occurs.
在处理重新密钥、续订或更新之后以及PKI收到对等方成功接收新PKC的确认之前的一段时间内，终端实体的PKC（旧PKC和新PKC）都将有效。这将允许对等方在重新密钥、续订或更新过程发生时继续与以前的PKC进行不间断的IKE连接。
After the rekey, renewal, or update occurs, the question now exists for the PKI of what to do about the old PKC. If the old PKC is to be made unusable, the PKI will need to add it to the revocation list, removed from the repository; however this should only occur once all connections that used the old PKC have expired. The decision about if the old PKC should be made unusable is determined by local policy. Either the PKI or the Admin MUST specify this parameter during the authorization phase. In this case, the PKI or the Admin MUST also specify the length of time from when the PKI receives the end entity Peer's confirmation (of receipt of the PKC) until when the old PKC is made unusable.
在重新注册、更新或更新之后，PKI现在面临的问题是如何处理旧PKC。如果要使旧PKC不可用，PKI需要将其添加到吊销列表中，并从存储库中删除；但是，只有在使用旧PKC的所有连接都过期后，才会发生这种情况。关于旧PKC是否不可用的决定由当地政策决定。PKI或管理员必须在授权阶段指定此参数。在这种情况下，PKI或管理员还必须指定从PKI收到终端实体对等方的确认（收到PKC）到旧PKC无法使用的时间长度。
In the case where the new keys were generated for a renew or update request and for rekey requests, once the Peer receives the confirmation acknowledgement from the PKI, it is good practice for the old key pair to be destroyed as soon as possible. Deletion can occur once all connections that used the old PKC have expired.
在为续订或更新请求以及重新密钥请求生成新密钥的情况下，一旦对等方接收到来自PKI的确认确认，最好尽快销毁旧密钥对。一旦使用旧PKC的所有连接都过期，就会发生删除。
If a PKC has been revoked, it MUST NOT be allowed a rekey, renewal, or update.
如果PKC已被吊销，则不得允许其重新注册、续订或更新。
Should the PKC expire without rekey, renewal, or update, an entirely new request MUST be made.
如果PKC到期而未重新注册、续订或更新，则必须提出全新的请求。
Admins manage rekeys to ensure uninterrupted use of the VPN by Peers with new keys. Rekeys can occur automatically if the Admin is configured to initiate a new authorization for the rekey.
管理员管理重新密钥，以确保具有新密钥的对等方不间断地使用VPN。如果管理员配置为启动重新密钥的新授权，则可以自动进行重新密钥。
Scenarios for rekey are omitted as they use the same scenarios used in the original PKC enrollment from Sections 3.2, 3.3, and 3.4.
由于使用了第3.2、3.3和3.4节中原始PKC注册中使用的相同场景，因此省略了重新注册的场景。
Admins manage renewals to ensure uninterrupted use of the VPN by Peers with the same key pair.
管理员管理续订，以确保具有相同密钥对的对等方不间断地使用VPN。
At the time of authorization, certain details about renewal acceptance will be conveyed by the Admin to the PKI, as stated in Section 3.2.4.2. The renewal request MUST match the conditions that were specified in the original authorization for:
授权时，如第3.2.4.2节所述，管理员将向PKI传达续签验收的某些细节。续订请求必须符合原始授权中规定的条件：
- Keys: New, existing, or either. - Requestor: End entity Peer, Admin, or either. - Period: How soon before PKC expiry. - Time: Length of time before making the old PKC unusable.
- 密钥：新的、现有的或任意一个。-请求者：终端实体对等方、管理员或任何一方。-期限：PKC到期前多久。-时间：使旧PKC无法使用之前的时间长度。
If any of these conditions are not met, the PKI must reject the renewal and log the event.
如果不满足上述任何条件，PKI必须拒绝续订并记录事件。
Scenarios for renewal are omitted as they use the same scenarios used in the original PKC enrollment from Sections 3.2, 3.3, and 3.4.
续签场景被省略，因为它们使用的场景与第3.2、3.3和3.4节中原始PKC注册中使用的场景相同。
An update to the contents of a PKC will be necessary when details about an end entity Peer's identity change, but the Operator does not want to generate a new PKC from scratch, requiring a whole new authorization. For example, a gateway device may be moved from one site to another. Its IPv4 Address will change in the SubjectAltName extension, but all other information could stay the same. Another example is an end user who gets married and changes the last name or moves from one department to another. In either case, only one field (the Surname or Organizational Unit (OU) in the DN) need change.
当终端实体对等方身份的详细信息发生变化时，需要更新PKC的内容，但运营商不希望从头生成新的PKC，需要全新的授权。例如，网关设备可以从一个站点移动到另一个站点。其IPv4地址将在SubjectAltName扩展名中更改，但所有其他信息可能保持不变。另一个例子是最终用户结婚后更改姓氏或从一个部门搬到另一个部门。在这两种情况下，只有一个字段（DN中的姓氏或组织单位（OU））需要更改。
An update differs from a rekey or a renewal in a few ways:
更新在以下几个方面与重新注册或续订不同：
- A new key is not necessary
- 不需要新钥匙
- The timing of the update event is not predictable, as is the case with a scheduled rekey or renewal.
- 更新事件的时间是不可预测的，就像计划的重新密钥或续订一样。
- The update request may occur at any time during a PKC's period of validity.
- 更新请求可能在PKC有效期内的任何时间发生。
- Once the update is completed, and the new PKC is confirmed, the old PKC should cease to be usable, as its contents no longer accurately describe the subject.
- 一旦更新完成，并且新的PKC得到确认，旧的PKC将不再可用，因为其内容不再准确描述主题。
At the time of authorization, certain details about update acceptance can be conveyed by the Admin to the PKI, as stated in Section 3.2.4.2. The update request MUST match the conditions that were specified in the original authorization for:
授权时，管理员可以向PKI传达有关更新验收的某些详细信息，如第3.2.4.2节所述。更新请求必须与原始授权中指定的条件相匹配：
- Keys: new, existing, or either. - Requestor: End entity Peer, Admin, or either. - The fields in the Subject and SubjectAltName that are changeable. - Time: Length of time before making the old PKC unusable.
- 密钥：新的、现有的或任意一个。-请求者：终端实体对等方、管理员或任何一方。-Subject和SubjectAltName中可更改的字段。-时间：使旧PKC无法使用之前的时间长度。
If any of these conditions are not met, the PKI MUST reject the update and log the event.
如果不满足上述任何条件，PKI必须拒绝更新并记录事件。
If an update authorization was not made at the time of original authorization, one can be made from Admin to the PKI at any time during the PKC's valid life. When such an update is desired, Admin
如果在原始授权时未进行更新授权，则可以在PKC有效期内的任何时间从管理员向PKI进行更新授权。当需要这样的更新时，管理员
must notify the PKI System that an update is authorized for the end entity and must specify the new contents. Admin then initiates the update request with the given contents in whichever mechanism the VPN System employs (direct from end entity to PKI, from end entity through Admin, or directly from Admin).
必须通知PKI系统已授权对最终实体进行更新，并且必须指定新内容。然后，Admin以VPN系统采用的任何机制（直接从终端实体到PKI，从终端实体到Admin，或直接从Admin）使用给定内容启动更新请求。
Scenarios for update are omitted as they use the same scenarios used in the original PKC enrollment from Sections 3.2, 3.3, and 3.4.
由于更新场景与第3.2、3.3和3.4节原始PKC注册中使用的场景相同，因此省略了更新场景。
Thorough error condition descriptions and handling instructions are required for each transaction in the rekey, renewal, or update process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products.
在重新密钥、续订或更新过程中，每个事务都需要完整的错误条件描述和处理说明。提供此类错误代码将极大地帮助PKI和IPsec产品之间的互操作性工作。
The confirmation handshake requirements are the same as in Sections 3.2, 3.3, and 3.4 except that depending on the Administrative policy the PKI MUST also issue a revocation on the original PKC before sending the confirmation response.
确认握手要求与第3.2、3.3和3.4节中的要求相同，但根据管理政策，PKI还必须在发送确认响应之前对原始PKC发出撤销。
The Peer MUST be able to initiate revocation for its own PKC. In this case the revocation request MUST be signed by the Peer's current key pair for the PKC it wishes to revoke. Whether the actual revocation request transaction occurs directly with the PKI or is first sent to Admin (who proxies or forwards the request to the PKI) is a matter of implementation.
对等方必须能够为其自己的PKC发起吊销。在这种情况下，撤销请求必须由对等方希望撤销的PKC的当前密钥对签名。实际的撤销请求事务是直接与PKI发生还是首先发送给管理员（由管理员代理或转发请求给PKI）是一个实现问题。
The Admin MUST be able to initiate revocation for any PKC issued under a template it controls. The Admin will identify itself to the PKI by use of its own PKC; it MUST sign any revocation request to the PKI with the private key from its own PKC. The PKI MUST have the ability to configure Admin(s) with revocation authority, as identified by its PKC. Any PKC authorizations must specify if said PKC may be revoked by the Admin (see Section 3.2.3.2 for more details).
管理员必须能够对其控制的模板下发布的任何PKC发起吊销。管理员将使用自己的PKC向PKI标识自己；它必须使用自己的PKC的私钥对PKI的任何撤销请求进行签名。PKI必须能够配置具有PKC标识的吊销权限的管理员。任何PKC授权都必须指定管理员是否可以撤销上述PKC（更多详细信息，请参见第3.2.3.2节）。
The profile MUST identify the one protocol or transaction within a protocol to be used for both Peer and Admin initiated revocations.
配置文件必须标识协议中的一个协议或事务，用于对等方和管理员发起的撤销。
The profile MUST identify the size of CRL the client will be prepared to support.
配置文件必须确定客户准备支持的CRL的大小。
Below are guidelines for revocation in specific transactions:
以下是特定交易中的撤销指南：
- AFTER RENEW, BEFORE EXPIRATION: The PKI MUST be responsible for the PKC revocation during a renew transaction. PKI MUST revoke the PKC after receiving the confirm notification from the Peer, and before sending the confirm-ack to the Peer. The Peer MUST NOT revoke its own PKC in this case.
- 续订后，到期前：PKI必须负责续订交易期间的PKC撤销。PKI必须在收到来自对等方的确认通知后，以及在向对等方发送确认确认之前撤销PKC。在这种情况下，对等方不得撤销其自己的PKC。
- AFTER UPDATE, BEFORE EXPIRATION: The PKI MUST be responsible for the PKC revocation during an update transaction. PKI MUST revoke the PKC after receiving the confirm notification from the Peer, and before sending the confirm-ack to the Peer. The Peer MUST NOT revoke its own PKC in this case.
- 更新后，到期前：PKI必须负责更新事务期间的PKC撤销。PKI必须在收到来自对等方的确认通知后，以及在向对等方发送确认确认之前撤销PKC。在这种情况下，对等方不得撤销其自己的PKC。
This section refers to the [R] elements labeled in Figure 3.
本节涉及图3中标记的[R]元素。
The PKI System SHOULD be built so that lookups resolve directly and completely at the URL indicated in a CDP or AIA. The PKI SHOULD be built such that URL contents do not contain referrals to other hosts or URLs, as such referral lookups will increase the time to complete the IKE negotiation, and can cause implementations to timeout.
PKI系统的构建应使查找能够在CDP或AIA中指示的URL处直接和完全解析。PKI的构建应确保URL内容不包含对其他主机或URL的引用，因为此类引用查找将增加完成IKE协商的时间，并可能导致实现超时。
CDP MUST be flagged as required in the authorization request. The method MUST also be specified: the HTTP method MUST be method; the Lightweight Directory Access Protocol (LDAP) method MAY be supported.
必须按照授权请求中的要求标记CDP。还必须指定方法：HTTP方法必须是method；LDAP（轻量级）目录访问方法可能受支持。
The complete hierarchical PKC chain (except the trust anchor) MUST be able to be searched in their respective repositories. The information to accomplish these searches MUST be adequately communicated in the PKCs sent during the IKE transaction.
必须能够在各自的存储库中搜索完整的分层PKC链（信任锚点除外）。完成这些搜索的信息必须在IKE事务期间发送的PKC中充分传达。
All PKCs must be retrievable through a single protocol. The final specification will identify one protocol as a "MUST", others MAY be listed as "OPTIONAL".
所有PKC必须可通过单个协议检索。最终规范将确定一个协议为“必须”，其他协议可能被列为“可选”。
The general requirements for the retrieval protocol include:
检索协议的一般要求包括：
- The protocol can be easily firewalled (including Network Address Translation (NAT) or Port Address Translation (PAT)).
- 该协议可以很容易地进行防火墙（包括网络地址转换（NAT）或端口地址转换（PAT））。
- The protocol can easily perform some query against a remote repository on a specific ID element that was given to it in a standard PKC field.
- 该协议可以轻松地对在标准PKC字段中给定给远程存储库的特定ID元素执行某些查询。
Other considerations include:
其他考虑因素包括：
- Relative speed - Relative ease of administration - Scalability
- 相对速度-相对易于管理-可扩展性
Intermediate PKCs will be needed for the case of re-keying of the CA, or a PKI System where multiple CAs exist.
对于CA的密钥更新或存在多个CA的PKI系统，需要中间PKC。
PKCs MAY have extendedKeyusage to help identify the proper PKC for IPsec, though the default behavior is to not use them (see 3.1.5.3).
PKC可能具有extendedKeyusage来帮助识别IPsec的正确PKC，尽管默认行为是不使用它们（请参见3.1.5.3）。
IPsec Peers MUST be able to resolve Internet domain names and support the mandatory repository access protocol at the time of starting up so they can perform the PKC lookups.
IPsec对等方必须能够解析Internet域名，并在启动时支持强制存储库访问协议，以便执行PKC查找。
IPsec Peers should cache PKCs to reduce latency in setting up Phase 1. Note that this is an operational issue, not an interoperability issue.
IPsec对等方应缓存PKC，以减少设置阶段1的延迟。请注意，这是一个操作问题，而不是互操作性问题。
The use case for accomplishing lookups when PKCs are not sent in IKE is a stated non-goal of the profile at this time.
当PKC未在IKE中发送时，完成查找的用例是当前概要文件的非目标。
Thorough error condition descriptions and handling instructions are required for each transaction in the repository lookup process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products.
存储库查找过程中的每个事务都需要完整的错误条件描述和处理说明。提供此类错误代码将极大地帮助PKI和IPsec产品之间的互操作性工作。
The root PKC MUST arrive on the Peer via one of two methods:
根PKC必须通过以下两种方法之一到达对等方：
(a) Peer can get the root PKC via its secure communication with Admin. This requires the Peer to know less about interaction with the PKI.
(a) 对等方可以通过与管理员的安全通信获取根PKC。这要求对等方对与PKI的交互知之甚少。
(b) Admin can command Peer to retrieve the root cert directly from the PKI. How retrieval of the root cert takes place is beyond the scope of this document, but is assumed to occur via an unauthenticated but confidential enrollment protocol.
(b) 管理员可以命令Peer直接从PKI检索根证书。根证书的检索方式超出了本文档的范围，但假定是通过未经验证但保密的注册协议进行的。
The IPsec Peer MUST perform identity verification based on the fields of the PKC and parameters applicable to the VPN Security Association. The fields of the PKC used for verification MAY include either the X.500 Distinguished Name (DN) within the Subject Name, or a specific field within the Extension SubjectAltName (per [DOI] 4.6.2.1 Identification Type Values). Usage descriptions for each follow.
IPsec对等方必须根据PKC字段和适用于VPN安全关联的参数执行身份验证。用于验证的PKC字段可以包括主题名称中的X.500可分辨名称（DN），或者扩展名SubjectAltName中的特定字段（根据[DOI]4.6.2.1标识类型值）。下面是每种用法的说明。
The Peers or a Simple Certificate Validation Protocol (SCVP) server MUST validate the certification path, as per RFC 3280. The contents necessary in the PKC to allow this will be enumerated in the profile document.
对等方或简单证书验证协议（SCVP）服务器必须按照RFC 3280验证证书路径。PKC中允许此操作所需的内容将在概要文件中列举。
The Peer MAY have the ability to construct the certification path itself; however, Admin MUST be able to supply Peers with the trust anchor and any chaining PKCs necessary. The Admin MAY ensure the template uses the AIA extension in PKCs as a means of facilitating path validation.
对等方可能有能力自行构建认证路径；然而，管理员必须能够向对等方提供信任锚和任何必要的链接PKC。管理员可以确保模板在PKCs中使用AIA扩展作为促进路径验证的手段。
DNS MUST be supported by the Peers in order to support resolving URLs present in CDPs and AIA extensions.
为了支持解析CDP和AIA扩展中存在的URL，对等方必须支持DNS。
The PKI System MUST provide a mechanism whereby Peers can check the revocation status of PKCs that are presented to it for IKE identity. The mechanism should allow for access to extremely fresh revocation information. CRLs have been chosen as the mechanism for communicating this information. Operators are RECOMMENDED to refresh CRLs as often as logistically possible.
PKI系统必须提供一种机制，通过该机制，对等方可以检查提交给它的PKC的撤销状态，以获得IKE身份。该机制应允许访问非常新的撤销信息。CRL已被选为传达此信息的机制。建议运营商在后勤方面尽可能频繁地刷新CRL。
A single mandatory protocol mechanism for performing CRL lookups MUST be specified by the final specification.
最终规范必须指定用于执行CRL查找的单一强制协议机制。
All PKCs used in IKE MUST have cRLDistributionPoint and authorityInfoAccess fields populated with valid URLs. This will allow all recipients of the PKC to know immediately how revocation is to be accomplished, and where to find the revocation information. The AIA is needed in an environment where multiple layers of CAs exist and for the case of a CA key roll-over.
IKE中使用的所有PKC必须使用有效URL填充cRLDistributionPoint和authorityInfoAccess字段。这将允许PKC的所有收件人立即知道如何完成撤销，以及在何处查找撤销信息。在存在多个CA层的环境中以及CA密钥转移的情况下，需要AIA。
IPsec Systems have an OPTION to turn off revocation checking. Such may be desired when the two Peers are communicating over a network without access to the CRL service, such as at a trade show, in a lab, or in a demo environment. If revocation checking is OFF, the implementation MUST proceed to use the PKC as valid identity in the exchange and need not perform any check.
IPsec系统具有关闭吊销检查的选项。当两个对等方在没有访问CRL服务的情况下通过网络进行通信时，例如在展销会、实验室或演示环境中，可能需要这样做。如果撤销检查处于关闭状态，则实现必须继续将PKC用作exchange中的有效标识，并且无需执行任何检查。
If the revocation of a PKC is used as the only means of deactivation of access authorization for the Peer (or user), then the speed of deactivation will be as rapid as the refresh rate of the CRL issued and published by the PKI. If more immediate deactivation of access is required than the CRL refreshing can provide, then another mechanism for authorization that provides more immediate access deactivation should be layered into the VPN deployment. Such a second mechanism is out of the scope of this profile. (Examples are Xauth, L2TP's authentication, etc.)
如果PKC的撤销被用作停用对等方（或用户）访问授权的唯一手段，那么停用的速度将与PKI发布和发布的CRL的刷新率一样快。如果需要比CRL刷新所能提供的更即时的访问停用，则应在VPN部署中分层提供更即时的访问停用的另一种授权机制。这种第二种机制不在本概要文件的范围内。（例如Xauth、L2TP的身份验证等）
3.7.4. Error Handling in Revocation Checking and Certificate Path Validation
3.7.4. 吊销检查和证书路径验证中的错误处理
Thorough error condition descriptions and handling instructions are required for each transaction in the revocation checking and path validation process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products.
撤销检查和路径验证过程中的每个事务都需要完整的错误条件描述和处理说明。提供此类错误代码将极大地帮助PKI和IPsec产品之间的互操作性工作。
This requirements document does not specify a concrete solution, and as such has no system-related security considerations per se. However, the intent of the PKI4IPSEC WG was to profile and use concrete protocols for certificate management (e.g., Cryptographic Message Syntax (CMS), Certificate Management over CMS (CMC), Certificate Request Message Format (CRMF)). The individual security considerations of these protocols should be carefully considered in the profiling effort.
本需求文件未规定具体的解决方案，因此本身没有与系统相关的安全注意事项。然而，PKI4IPSEC工作组的目的是分析并使用具体的证书管理协议（例如，加密消息语法（CMS）、CMS上的证书管理（CMC）、证书请求消息格式（CRMF））。在分析工作中，应仔细考虑这些协议的各个安全因素。
In addition, this document allows significant flexibility in the allocation of functions between the roles of Peer and Admin. This functional allocation is crucial both to achieving successful deployment, and to maintaining the integrity of the PKI enrollment and management processes. However, much of the responsibility for this allocation necessarily falls to product implementers and system operators through the selection of applicable use cases and development of security policy constraints. These factors must be carefully considered to ensure the security of PKI4IPSEC certificate management.
此外，本文档允许在对等角色和管理员角色之间分配功能时具有极大的灵活性。这种功能分配对于实现成功部署以及维护PKI注册和管理过程的完整性至关重要。然而，通过选择适用的用例和开发安全策略约束，这种分配的大部分责任必然落在产品实现者和系统操作员身上。为了确保PKI4IPSEC证书管理的安全性，必须仔细考虑这些因素。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[CERTPROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[CERTPROFILE]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[FRAME]Chokhani，S.，Ford，W.，Sabett，R.，Merrill，C.，和S.Wu，“互联网X.509公钥基础设施证书政策和认证实践框架”，RFC 3647，2003年11月。
[IKECERTPROFILE] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, February 2007.
[IKECERTPROFILE]Korver，B.，“IKEv1/ISAKMP、IKEv2和PKIX的互联网IP安全PKI配置文件”，正在进行的工作，2007年2月。
[IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKEv1]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsec]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
This RFC is substantially based on a prior document developed by Project Dploy. The principle editor of that document was Gregory M. Lebovitz (NetScreen/Juniper). Contributing authors included Lebovitz, Paul Hoffman (VPN Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH Communications Security). Substantial editorial contributions were made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet), Thomas Hardjono (VeriSign), Carlisle Adams (Entrust), and Michael Shieh (NetScreen/Juniper).
本RFC基本上基于Dploy项目开发的先前文件。该文件的主编是Gregory M.Lebovitz（NetScreen/Juniper）。贡献作者包括Lebovitz、Paul Hoffman（VPN联盟）、Hank Mauldin（思科系统）和Jussi Kukkonen（SSH通信安全）。Leo Pluswick（ICSA）、Tim Polk（NIST）、Chris Wells（SafeNet）、Thomas Hardjono（VeriSign）、Carlisle Adams（委托）和Michael Shieh（NetScreen/Juniper）做出了大量的编辑贡献。
Once brought to the IETF's PKI4IPSEC WG, the following people made substantial contributions: Jim Schaad and Stefan Santesson.
一旦加入IETF的PKI4IPSEC工作组，以下人员做出了重大贡献：Jim Schaad和Stefan Santesson。
Editors' Addresses
编辑地址
Chris Bonatti IECA, Inc. EMail: Bonattic@ieca.com
Chris Bonatti IECA，Inc.电子邮件：Bonattic@ieca.com
Sean Turner IECA, Inc. EMail: Turners@ieca.com
Sean Turner IECA，Inc.电子邮件：Turners@ieca.com
Gregory M. Lebovitz Juniper EMail: gregory.ietf@gmail.com
Gregory M.Lebovitz Juniper电子邮件：Gregory。ietf@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。