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
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.
この情報資料は、説明と公開鍵証明書（PKC）インターネット鍵交換を使用してインターネットプロトコルセキュリティ（IPsec）の仮想プライベートネットワーク（VPN）システム間のライフサイクル取引（IKE）（バージョン1および2）と公開鍵を処理するために、トランザクションの要件を特定しますインフラストラクチャ（PKI）システム。これらの要件は、エンタープライズ規模の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
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の]）とPKIシステムを使用して、[IPsecの】VPNシステム間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.
この文書では、より良い取引の共通セットで大規模な、PKI対応のIPsecの展開を可能にするために、異なるVPNシステムとPKIシステムの製品間での公開鍵証明書（PKC）のライフサイクル取引の要件を列挙します。 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:
（PKC発行の）許可、世代（公開鍵と秘密鍵のペアとPKC要求）、登録（PKC要求、PKCの応答、および確認）、メンテナンス（再入力：要件は、PKI対応のVPNシステムの全体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.
- PKCの認可を管理し、おそらくVPNシステムとPKIシステムのための唯一のインターフェイスとして機能するように、このドキュメントで紹介され、VPN管理機能（管理者）を使用してください。
- 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ベースのユーザまたはマシンのID、。
- 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オペレータは、VPNの展開と管理を実行するために、任意の準拠PKIベンダーの実装で証明書管理プロファイルのいずれかの適合するIPsec実装（VPNの管理やIPsecピア）を使用することができるはずです。
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ピア間の取引上の要件に対応しています。要件は（すなわち、VPNは、管理VPNゲートウェイやVPNリモートアクセスクライアントの数百または数千を含む）の大規模な展開のための市場ニーズの80％を満たすために努力しています。環境は、当然のことながら、大規模な展開ツールが望まれるには存在しますが、ローカルセキュリティポリシーのストリンジェンシーは、このような商用ツールの使用を許可されません。解決策は、おそらくジェンシーの最高の十パーセントと利便性要件の最低十パーセントのニーズを欠場します。ユースケースが考えられたり、この八十パーセントルールに基づいて拒否されます。小規模の導入の必要性は非目標を述べています。しかし、サービスプロバイダースコープのソリューションを採用し、合計で多くの小規模な展開に適用するには、それらに対処することができます。
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.
唯一のVPN-PKI取引やすさと拡張性のPKI対応のIPsecの展開を有効に対処しています。
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ピア（ゲートウェイまたはクライアント）は、通信用のIPsecセキュリティアソシエーションを作成するために、他のピアにIKEとIPsecを通信する任意のVPNシステムコンポーネントです。なお、またはIPsecクライアント（2つのネットワークインターフェイス、保護されたネットワークのための1つおよび保護されていないネットワークのための1つを有する）（単一のネットワーク・インターフェースを有する）従来のセキュリティ・ゲートウェイのいずれかであり得ます。どちらの場合も、ピアはありません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.
（VPN）管理者ザ・管理者は、VPN接続のためのPKCのプロビジョニングを確立するPKIシステムと相互作用してVPNシステムの機能です。詳細については、セクション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 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）のPKCを作成し、署名する1人以上のユーザーに信頼されているPKIシステムでの権限。 CAがないだけで、それらを発行するために、彼らの一生の間のPKCのために責任があることに注意することが重要です。
Repository An Internet-accessible server in a PKI System that stores and makes available for retrieval PKCs and Certificate Revocation Lists (CRLs).
検索のPKCおよび証明書失効リスト（CRL）のために利用できるように格納し、PKIシステムで、インターネットにアクセス可能なサーバーをリポジトリ。
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 /トラストアンカーA 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は、取り消されたPKCεを識別するCA署名、タイムスタンプ付きリストであり、リポジトリに自由に利用可能となります。ピアはIKEトランザクションのIDが失効していないようPKCが彼らに提示されていることを確認するために、CRLを取得します。
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は、エンドエンティティは、ステータス情報を確認するCRLを取得すべき場所を識別するPKC拡張です。
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の発行者のための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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【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システムは、図1に示すように、IPsecのピアとVPN管理機能から成ります。
+---------------------------------------------------+
| |
| +----------+ |
| | 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セキュリティアソシエーションの確立が必要とされている間に、2つのエンティティです。 2つのピアが図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 authorizes PKC issuance and can act as the Peer's PKI System interface, which allows the Admin to perform many RA-like functions.
この文書では、VPN管理機能の概念を定義し、以下管理者と呼ばれ、VPNシステム内の管理大きな責任を与えます。管理者は、IPsecピアのグループのためのPKIポリシー（例えば、アルゴリズム、鍵長、ライフサイクル・オプション、及びPKCフィールド）を確立するために、PKIシステムと対話するためにオペレータによって使用される集中化関数です。管理者はまた、PKCの発行を許可し、管理者は、多くのRAのような機能を実行することを可能にするピアのPKIシステムのインターフェイスとして機能することができます。
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.
- それは（すなわち、認証要求の両方のタイプは、事前に合意された参照事前に合意されたテンプレートに基づいて個々のPKCまたはPKCSのバッチのためのパラメータと内容を送信することにより、エンドエンティティのPKCのための認証を開始するPKIシステムと直接対話しますテンプレート）。テンプレートは、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).
- （例えば、管理者がキーとPKC要求を生成するために必要なピア情報を渡す）これは、IPsecピアに命令を提供し、ピアはそれらの命令を実行します。
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 | |
| +--------------+ +----+ +----+ |
| |
+---------------------------------------------+
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システムは、公開鍵と秘密鍵のペアや看板のPKCを使用してCAのコア機能が含まれています。
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に示すように、この要件ドキュメントの主要な焦点である、セットアップに必要な手順を考慮することが賢明である、使用、および確立するために、1つのピアのためのPKCを管理別のピアとの関連。
+-----------------------------------------------+
| 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] =認証：PKC発行[G] =ジェネレーション：公開鍵、秘密鍵、およびPKC要求[E] =登録：、PKCの要求を送信するPKCの応答を確認し、PKCの応答を確認し、[I]は= IKEおよびIPsec通信[ L]ライフサイクル=：リキー、更新、更新、取り消し、および確認[R] =レポジトリ：転記とルックアップを
Figure 3. Architectural Framework for VPN-PKI Interaction
VPN-PKIの相互作用図3.アーキテクチャーのフレームワーク
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.
相互作用の各々のための要件[A]、[G]、[E]、[L]、および[R]は、3.6を介してセクション3.2で対処されます。ただし、[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.
ターゲットプロファイルが、この要件文書に基づくものと、[E]、[L]、および[R]相互作用が、[A]の各主要構成要素の一つのプロトコルまたはONE用プロファイルを要求しなければなりません。同じ要件を解決するために、複数の競合プロトコルまたはプロファイルを持つ、複雑さを軽減し、相互運用性を向上させるためには、可能な限り避けるべきです。
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とAdmin（3.7.1項を参照）との間で確立されることを要求しなければなりません。応答（すなわち、のPKCおよびCRL）がすでにデジタル署名されているため、[R]トランザクションは、認証やメッセージデータの整合性を必要としません。 [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 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.
管理者は、ピアによって到達可能でなければなりません。ほとんどの実装では、どこでもネットワークやインターネット上から管理者に接続することができピアを確実にすることによって、この要件を満たしています。ただし、管理者およびピア間の通信は、「オフライン」することができます。それは、いくつかの環境では、「移動媒体」とすることができる（即ち、構成やデータは、フロッピーディスクまたは他の媒体上にロードされ、物理的にIPsecのピアに移動します）。同様に、ユーザーインターフェイス（UI）を介してIPSecピアに直接入力することができます。この場合、管理機能は、ピアデバイス自体に同じ場所に配置されます。このドキュメントのほとんどの要件とシナリオは、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とAdmin間の認証取引のために最初に必要となります。さらに、可用性は、ほとんどの場合に必要とされるが、この可用性の程度はオペレータのための決定点です。このドキュメントのほとんどの要件とシナリオは、VPNシステムの生活のためのPKIのオンライン可用性を前提としています。
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.
1つのPKCの両方のトランザクションセットを使用することができるように、IPsecの取引[IKECERTPROFILE]及び（証明書管理プロファイルの）VPN-PKIトランザクションのPKCプロファイルが同じであることが好ましいです。プロファイルが矛盾している場合は、異なるの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（別名USER 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.
PKCキー（すなわち、デジタル署名）を使用することができるための目的を示すサポートしなければなりません。さらに、の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は、局所的にPKCを保持しているすべてのピアが正確にどこへ行くとどのようにCRLを要求するために知っているような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の際に管理者の要求を発生します。一つの値の最小値は、（複数も可）被験者ごとに異なります。いずれかのキーが生成される前に権限が発生する可能性があるため、独自の認証識別子が発行されることを保証する唯一の方法は、少なくとも1つの値は、対象ごとに異なることです。
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.
バルク認可は被写体数が1以上であると、PKI（RA / CA）に1つの接続で発生しました。実装は、バッチ承認に千科目を処理できる必要があります。
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取引の認可シナリオは、2段階のプロセスを含みます。図4は、認証トランザクションを実行するために顕著な相互作用を示しています。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
| 1
2 |
v
+-------+
| Admin |
+-------+
+--------------------+ +--------+
| 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コンテンツのセットを送信することができます。言い換えれば、それは「あなたはこの人から、このようになりますPKC要求を見ればそれを処理し、PKCを発行する。」、PKIシステムに指示します
Requirements for PKC fields used in IPsec transactions are specified in [IKECERTPROFILE].
IPsecのトランザクションで使用されるPKCフィールドの要件は[IKECERTPROFILE]で指定されています。
Requirements for PKC fields used in VPN-PKI transactions are specified in Section 3.1.6.
VPN-PKI取引に使用されるPKCフィールドの要件は、3.1.6項で規定されています。
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.
- 自動更新が許可されている場合は管理者が指定しなければならない、つまり、管理者は、指定されたピアPKCの将来の更新を処理するためにPKIを許可します。
- 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の更新が許可されている場合は管理者が指定しなければならない、つまり、管理者は、非キー関連分野への変更で新しいPKCの将来の要求を受け入れるようにPKIを許可します。
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).
- PKIを受け入れ、更新を処理するどのくらいPKC有効期限の前に（すなわち、有効期間、または更新が許可された後UTC時間のN％）でした。
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 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.
管理者は、許可IDとワンタイム認証トークンの形式を指定する能力を持たなければなりません。ワンタイム認証トークンは、許可IDごとに一意である必要があります。許可IDとワンタイム認証トークンとの関係で達成することができ、よりランダム性、より良いです。ワンタイム認証トークンは、国際的な文字が原因で発生する可能性があります互換性の問題を回避するために、UTF-8形式でなければなりません。これは、[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.
プロトコルは、管理要求は要求として発行することはできません（例えば、管理者の要求の検証期間= 3週間とCAのみ許可し、検証期間= 1週間に設定されている）ようなPKIの設定と管理、要求された情報の競合を何が起こるかを検討すべきです。適切な競合の処理を指定する必要があります。
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.
キャンセルが確認された後（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に従って取り消さなければなりません。
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 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.
PKIは、管理者から提出された承認リクエストのパラメータを変更することができます。その場合には、PKIは、認証成功の確認と管理に（修正された）認証要求のすべての内容を返さなければなりません。これは、管理者が発行したの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は、それが満足およびNOまたは十分な理由やエラーコードとともに、満足できないそれらの要求のために失敗したそれらの個々のPKC権限をYESに返信することができなければなりません。
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で：キーの世代が地域の要件に応じて、3つの場所で発生する可能性があります。 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 |
+--------------+ +-----------------------+
+-------+
+------>| 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に記載されています。次のステップで、登録は、（セクション3.4.6を参照）を直接ピアとPKI（セクション3.4.5を参照）との間または管理を介してのいずれかで起こり得ます。
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ピアの生成をサポートしていますが、それは構築またはデジタルPKCの要求に署名する必要がないため、ピア意識ASN.1ことにするための要件を削除します。欠点は、鍵ペアは管理者に提供する必要がないということです。管理機能をリモートピアから配置されている最も可能性の高いケースでは、これは、秘密鍵は、重大なセキュリティのトレードオフを考慮すべき事項であるピアの暗号境界を残すことを意味します。可能な限り、生成された秘密鍵を持っており、発電システムの暗号境界を残すことはありませんし、常により良いです。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
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.
このオプションは、ピアが自分の鍵ペアを生成することができない展開のために存在します。 RSAキーを生成するためのPDAや携帯電話が原因処理し、バッテリ制約のために運用は不可能であろうためにいくつかの例があります。別の場合には、同じのPKCは、IPSecに加えて、他の機能のために使用されるキー回復要件をカバーし、キー回復は、したがって、キーエスクローがピアから必要とされ、（例えば、ローカルデータの暗号化）が必要です。キーエスクローが行われた場合、それのための正確な要件と手順は、このドキュメントの範囲を超えています。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+-------+
| Admin | 1
+-------+
+--------------------+ +--------+
| 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 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.
管理者はまた、キー生成を実行しているにもかかわらず、独立した権限の手順は、まだ価値のあることに注意してください。 PKCテンプレート、件名フィールド、のSubjectAltNameフィールド、およびよりは、要求の一部であり、PKIへの管理者から何らかの方法で伝達されなければなりません。代わりに、新しいメカニズムを作成する、認証スキーマを再利用することができます。これはまた、オペレータ1は、管理機能事前承認のPKCを持つことが許可された唯一のものですが、オペレータ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とAdminはPKI鍵ペアとのPKCを生成させる前に同意するものとします。これは、CAおよび管理者の両方が秘密鍵へのアクセス権を持っているので、それはいくつかのセキュリティを犠牲にかかわらず、すべての可能性では、最も簡単な方法は、のPKCを展開すること、です。しかし、キーエスクローが必要な場合には、これは許容できます。管理者は、効果的にPKCの登録プロセスにおけるピアのプロキシとして動作します。
+--------------+ +-----------------------+
| Repository | | CA/RA | 1
+--------------+ +-----------------------+
+-------+
| Admin |
+-------+
+--------------------+ +--------+
| 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.
プロトコルは、インターネット上で、手動の介入を必要とせずに発生し登録をサポートしなければなりません。
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）の代わりに管理者との間の1つのオンライン接続で発生することができなければなりません。
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システムは、安全なIPsecのための十分な強度の公開鍵と秘密鍵のペアを生成するのに十分なCPUパワーを持っています。この場合、エンドエンティティは、そのような鍵ペアを有するPKIに証明する必要があります。これは通常、エンドエンティティの公開鍵と一緒に管理するエンドエンティティ兆候とリターンエンドエンティティナンスを送信するPKIによって行われます。
+--------------+ +-----------------------+
| 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
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システムは、安全なIPsecのための十分な強度の公開鍵と秘密鍵のペアを生成するのに十分なCPUパワーを持っています。この場合、エンドエンティティが、それは、このような鍵のペアを持っている管理者に証明する必要があります。これは通常、エンドエンティティの公開鍵と一緒に管理するエンドエンティティ兆候とリターンエンドエンティティナンスを送信する管理者によって行われます。
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 |
+--------------------+ +--------+
Figure 10. VPN-PKI Interaction Steps:
IPsec Peer Generates Keys and PKC Request,
Enrolls Through Admin
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システムは、安全なIPsecのための十分な強度の公開鍵と秘密鍵のペアを生成するのに十分なCPUパワーを持っていません。この場合、管理者は、そのような鍵のペアを持っているPKIに証明する必要があります。これは通常、エンドエンティティの公開鍵と一緒にPKIを管理者に管理者のサインと戻りナンスを送信するPKIによって行われます。この場合の欠点は、プライベート鍵は、最終的に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 |
+--------------------+ +--------+
Figure 11. VPN-PKI Interaction Steps:
IPsec Peer Generates Keys, Admin Constructs and
Signs PKC Request, Enrolls through Admin
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システムは、安全なIPsecのための十分な強度の公開鍵と秘密鍵のペアを生成するのに十分なCPUパワーを持っていません。この場合、管理者は、そのような鍵のペアを持っているPKIに証明する必要があります。これは通常、エンドエンティティの公開鍵と一緒にPKIを管理者に管理者のサインと戻りナンスを送信するPKIによって行われます。この場合の欠点は、プライベート鍵は、最終的に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 |
+--------------------+ +--------+
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とAdminは、以前PKI認可要求を受信したときに、PKIは、鍵と証明書を生成させることで合意しました。 PKIは、管理、鍵ペアおよび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.
この場合の欠点は、プライベート鍵は、最終的に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 |
+--------------------+ +--------+
Figure 13. VPN-PKI Interaction Steps:
PKI Generates Keys, PKC Request, and Enrolls
Directly with 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).
新しいPKCは、PKIによって発行されているすべての時間は、PKCの領収書の確認はピアまたは（ピアの確認を転送する）管理者によってPKIに送り返さなければなりません。
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:
操作上、ピアはそれをロードし、PKCを受け取ったことを確認PKIに確認を送らなければなりませんし、IKE交換で効果的に使用することができます。この要件は、なるように存在します。
- 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
- そのPKCは、ピアで有効に利用することができるようになるまでPKIは、他のリポジトリに新しい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がPKCを生成することができませんでしたようにPKIの設定されたポリシーに違反していました。
- 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を送ったが、要求者（Adminまたはピア）がそれを受信しませんでした。
- The Requestor (Admin or Peer) received the PKC, but could not process it due to incorrect contents, or other PKC-construction-related problem.
- リクエスタ（Adminまたはピア）が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?
- ピア何をしますか？ - 管理者は何をしますか？ - 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を送信した後、およびピアがそれを受け取る前に障害が発生した場合、ピアは、同じ許可IDとワンタイム認証トークンで要求を再度しなければなりません。 PKIは、認証IDと認証トークンを見て、再び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.
失効要求は再入力、更新、および更新操作と同じプロトコルを使用するかもしれません。失効要求はまた、電子メールなど、電話、インスタントメッセージング、経由して発生してもよい（MAY）
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の有効期限が切れる前に、同じサブジェクト名とのSubjectAltName内容のための新しい公開鍵を持つ新しいPKCをエンドエンティティのPKCを置き換えます。
- 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と同じサブジェクト名とSubjectAlternativeNameの内容に同じ公開鍵で、エンドエンティティのPKCを置き換えます。
- 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の満了前に変更されたサブジェクト名または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.
リキー後の時間の持続のために、エンドエンティティの両方のPKC（新旧）が有効になり、更新、または更新が処理され、前にPKIは、新しい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.
再入力、更新、または更新が発生した後、質問は今、古いPKCについて何をすべきかのPKIのために存在します。古い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:
セクション3.2.4.2で述べたように、許可の時には、更新の受け入れに関する特定の詳細は、PKIに管理者によって搬送することができます。更新要求がために、元の承認に指定された条件に一致する必要があります。
- 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.
- キー：新しい、既存の、またはどちらか。 - リクエスタ：エンドエンティティピア、管理者、またはどちらか。 - 変更されている主題との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 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).
更新の許可は、元の承認の時に行われていなかった場合、1はPKCの有効寿命の間いつでも、管理者からのPKIにすることができます。このような更新を希望される場合は、管理者は、更新は、エンドエンティティのために許可されているPKIシステムに通知しなければなりませんし、新しい内容を指定する必要があります。管理者は次に、VPNシステムは、（管理者を介してエンドエンティティから、または直接管理から、エンドエンティティからPKIへの直接）を採用いずれ機構に与えられる内容で更新要求を開始します。
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と同様であり、そしてそれは、管理ポリシーに応じて、PKIも確認応答を送信する前に、元のPKCの失効を発行しなければなりません除いて3.4。
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への失効要求に署名しなければなりません。そのPKCによって識別されるPKIは、失効権限を持つ管理者（複数可）を構成する能力を持たなければなりません。 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.
- AFTER満了前に、RENEW：PKIは、更新トランザクション中にPKCの失効を担当しなければなりません。 PKIは、ピアから、およびピアに確認-ACKを送信する前に確認通知を受けた後に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は、ピアから、およびピアに確認-ACKを送信する前に確認通知を受けた後に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.
検索がCDPまたはAIAに示されているURLに直接かつ完全に解決するようにPKIシステムを構築する必要があります。 PKIは、このような紹介の検索がIKEネゴシエーションを完了するまでに時間が長くなり、タイムアウトに実装を引き起こす可能性として、URLの内容は、他のホストまたはURLへの紹介を含まないように構築する必要があります。
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メソッドは、メソッドでなければなりません。 LDAP（Lightweight Directory Access Protocol）のメソッドをサポートすることができます。
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は、単一のプロトコルを介して取得可能でなければなりません。最終的な仕様は、他のものは「任意」として表示されることがあり、「MUST」のような1つのプロトコルを識別する。
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.
中間のPKCは、CAの再キーイング、または複数のCAが存在PKIシステムの場合に必要とされるであろう。
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).
デフォルトの動作は（3.1.5.3を参照）、それらを使用しないことですけれどものPKCは、IPsecのための適切なPKCを識別するのに役立つextendedKeyUsageのを持っているかもしれません。
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のピアは、インターネットドメイン名を解決するので、彼らは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のピアが、これは操作上の問題ではなく、相互運用性の問題であることをフェーズ1注意をセットアップする際の待ち時間を減らすためのPKCをキャッシュする必要があります。
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は、二つの方法のうちの1つを介してピアに到着しなければなりません。
(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）は管理者が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）、または（[DOI] 4.6.2.1識別タイプ値ごとに）拡張のSubjectAltName内の特定のフィールドのいずれかを含むことができます。それぞれの使い方の説明が続きます。
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）サーバはこれを許可するPKCに必要な内容はプロファイル文書に列挙されますRFC 3280に従って、証明書パスを検証する必要があります。
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とピアを供給できなければなりません。テンプレートを確実にすることができる管理者は、パス検証を容易にする手段としてのPKCのAIA拡張機能を使用しています。
DNS MUST be supported by the Peers in order to support resolving URLs present in CDPs and AIA extensions.
DNSは、のCDPとAIAの拡張機能に存在する解決するURLをサポートするために、ピアによってサポートしなければなりません。
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システムは、ピアがIKE識別のためにそれに提示されるのPKCの失効ステータスを確認することができるメカニズムを提供しなければなりません。メカニズムは非常に新鮮な失効情報へのアクセスを可能にしなければなりません。 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のすべての受信者が失効が達成されるべきであり、そしてどこ失効情報を見つけるために、すぐにどのように知ることができるようになります。 AIAは、CAの複数の層が存在する環境およびCAキーロールオーバの場合に必要とされます。
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のシステムは、失効チェックをオフにするオプションを持っています。 2つのピアが実験室で、またはデモ環境では、このようなトレードショーでのように、CRLサービスにアクセスすることなく、ネットワークを介して通信している場合、このような所望されてもよいです。失効チェックがOFFの場合、実装は、交換に有効なIDとしてPKCを使用するように進み、いずれかのチェックを行う必要はありませんしなければなりません。
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の展開に階層化されなければなりません。そのような第2のメカニズムは、このプロファイルの範囲外です。 （例としては、などの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 WGの意図は、プロファイルと証明書を管理するための具体的なプロトコルを使用していた（例えば、暗号メッセージ構文（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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]パイパー、D.、RFC 2407 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、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.、フォード、W.、Sabett、R.、メリル、C.、およびS.ウー、 "インターネット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]コーバー、B.、進歩、2007年2月ワーク "のIKEv1 / ISAKMP、IKEv2の、およびPKIXのインターネットIPセキュリティPKIプロファイル"。
[IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKEv1の]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsecの]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年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によって開発された以前の文書に基づいています。その文書の原則エディタはグレゴリーM. Lebovitz（のNetScreen /ジュニパー）でした。貢献の著者はLebovitz、ポール・ホフマン（VPNコンソーシアム）、ハンク・モールディン（シスコシステムズ）、およびユッシKukkonen（SSHコミュニケーションズ・セキュリティ）を含んでいました。かなりの社説貢献はレオPluswick（ICSA）、ティム・ポーク（NIST）、クリス・ウェルズ（SafeNetの）、トーマス・Hardjono（ベリサイン）、カーライル・アダムス（トラスト）、そしてマイケルShieh（のNetScreen /ジュニパー）によって作られました。
Once brought to the IETF's PKI4IPSEC WG, the following people made substantial contributions: Jim Schaad and Stefan Santesson.
ジムSchaadとステファンSantesson：IETFのPKI4IPSEC WGに持ち込まれると、次の人はかなりの貢献をしました。
Editors' Addresses
エディタのアドレス
Chris Bonatti IECA, Inc. EMail: Bonattic@ieca.com
クリスBonatti IECA、株式会社Eメール：Bonattic@ieca.com
Sean Turner IECA, Inc. EMail: Turners@ieca.com
ショーン・ターナーIECA、株式会社Eメール：Turners@ieca.com
Gregory M. Lebovitz Juniper EMail: gregory.ietf@gmail.com
グレゴリーM. LebovitzジュニパーEメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。