[要約] RFC 4809は、IPsec証明書管理プロファイルの要件を定義しています。その目的は、IPsecネットワークでの証明書の効果的な管理を確保することです。
Network Working Group C. Bonatti, Ed.
Request for Comments: 4809 S. Turner, Ed.
Category: Informational IECA
G. Lebovitz, Ed.
Juniper
February 2007
Requirements for an IPsec Certificate Management Profile
IPSEC証明書管理プロファイルの要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この情報文書では、インターネットキーエクスチェンジ（IKE）（バージョン1および2）と公開キーを使用して、インターネットプロトコルセキュリティ（IPSEC）仮想プライベートネットワーク（VPN）システム間の公開キー証明書（PKC）ライフサイクルトランザクションを処理するためのトランザクションの要件を説明および特定しますインフラストラクチャ（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:
要件は、PKI対応VPNシステムのPKCライフサイクル全体のトランザクションに対処します：認証（PKC発行の）、生成（官民キーペアおよびPKCリクエスト）、登録（PKCリクエスト、PKC応答、確認）、メンテナンス（Rekey、更新、更新、取り消し、および確認）、およびリポジトリルックアップ。これらのトランザクションにより、VPNオペレーターは次のようになります。
- Use a VPN Administration function (Admin), which is introduced in this document, to manage PKC authorization and possibly act as the sole interface for the VPN System and the PKI System.
- このドキュメントで紹介されているVPN管理機能（Admin）を使用して、PKC認証を管理し、VPNシステムとPKIシステムの唯一のインターフェイスとして機能します。
- Authorize individual or batches of PKC issuances based on a pre-agreed template (i.e., both types of authorization requests refer to the pre-agreed template). These authorizations can occur either prior to the enrollment or in the same transaction as the enrollment.
- 承認済みのPKC発行の個別またはバッチを、事前にアグレッドテンプレートに基づいて（つまり、両方のタイプの承認要求が事前に合わせたテンプレートを参照）。これらの承認は、登録前または登録と同じ取引で発生する可能性があります。
- Provision PKI-based user or machine identity to IPsec Peers, on a large scale.
- PKIベースのユーザーまたはマシンのアイデンティティを大規模にIPSECピアに提供します。
- 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 Rekey、更新、更新のポリシーを確立します。
- 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オペレーターは、適合のPKIベンダーの実装を使用して、VPNロールアウトと管理を実行するために、証明書管理プロファイルの適合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％を満たすよう努めています。大規模な展開ツールが望まれる環境は当然のことながら存在しますが、ローカルセキュリティポリシーの厳格性は、そのような商用ツールの使用を許可しません。このソリューションは、おそらく、ストリンシンシーの最高10％と利便性の要件の最低10％のニーズを逃す可能性があります。この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.
スケーラブルなPKI対応のIPSEC展開を容易にし、有効にするVPN-PKIトランザクションのみに対処します。
The scenario for PKC cross-certification will not be addressed.
PKC相互認証のシナリオには対処されません。
The protocol specification for the VPN-PKI interactions will not be addressed.
VPN-PKI相互作用のプロトコル仕様には対処されません。
The protocol specification for the VPN Administrator to Peer transactions will not be addressed. These interactions are considered vendor proprietary. These interactions may be standardized later to enable interoperability between VPN Administration function stations and IPsec Peers from different vendors, but are far beyond the scope of this current effort, and will be described as opaque transactions in this document.
VPN管理者のピアトランザクションのプロトコル仕様には対処されません。これらの相互作用は、ベンダー専有と見なされます。これらの相互作用は、VPN管理機能ステーションとさまざまなベンダーのIPSECピア間の相互運用性を可能にするために後で標準化される場合がありますが、この現在の取り組みの範囲をはるかに超えており、このドキュメントの不透明なトランザクションとして説明されます。
The protocol specification for Registration Authority - Certificate Authority (RA-CA), CA-Repository, and RA-Repository interactions will not be addressed.
登録機関のプロトコル仕様 - 証明書権限（RA-CA）、CA-Repository、およびRA-Repositoryの相互作用は対処されません。
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ピア、または単に「ピア」は、IKESCセキュリティ協会を作成するためにIKEとIPSECを別のピアに伝えるVPNシステムコンポーネントです。これは、従来のセキュリティゲートウェイ（2つのネットワークインターフェイス、1つは保護されたネットワーク用、もう1つは保護されていないネットワーク用）またはIPSECクライアント（単一のネットワークインターフェイスを使用）です。どちらの場合も、ピアはIPSEC保護なしでトラフィックを渡すことができ、選択したトラフィックストリームにIPSEC保護を追加できます。詳細については、セクション2.1.1を参照してください。
(VPN) Admin The Admin is the VPN System function that interacts with the PKI System to establish PKC provisioning for the VPN connections. See Section 2.1.2 for more details.
（VPN）管理者管理者は、PKIシステムと相互作用してVPN接続のPKCプロビジョニングを確立する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で識別されるエンティティまたは主題です。End Entityは、PKCに関連付けられた秘密鍵を最終的に使用してデータをデジタルに署名するエンティティです。このドキュメントでは、IPSECピアは確かに最終エンティティですが、VPN管理者はエンティティを構成することもできます。End Entitiesは、さまざまな目的で異なる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を交換するためのルーチン手順を再キーします。Rekeyプロセスは、既存のキーペアに依存して、新しい登録のために認証をブートストラップすることができます。
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）PKCSを作成および署名するために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および証明書の取り消しリスト（CRLS）を保存および利用できるようにする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/トラストアンカーは、最終エンティティによって直接信頼されている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に署名されたタイムスタンプ付きリストであり、リポジトリで自由に利用可能になります。ピアはCRLを取得して、IKEトランザクションのアイデンティティとしてPKCが提示されていることを確認しています。
CRL Distribution Point (CDP) The CDP is a PKC extension that identifies the location from which end entities should retrieve CRLs to check status information.
CRL分布ポイント（CDP）CDPは、ステータス情報を確認するためにEndエンティティが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.
Authority Info Access（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[必須]に記載されているように解釈される。
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システム内で管理者に大きな責任を与えます。管理者は、PKIシステムと対話するためにオペレーターがPKIポリシー（例えば、アルゴリズム、キー長、ライフサイクルオプション、およびPKCフィールド）をIPSECピアのグループに確立するために使用する集中機能です。管理者はまた、PKCの発行を承認し、PeerのPKIシステムインターフェイスとして行動することができます。これにより、管理者は多くのRAのような機能を実行できます。
It is important to note that, within this document, the Admin is neither a device nor a person; rather, it is a function. Every large-scale VPN deployment will contain the Admin function. The function can be performed on a stand-alone workstation, on a gateway, or on an administration software component. The Admin function can also be one and the same as the gateway, client device, or software. They are represented in the architectural diagram as different functions, but they need not be different physical entities. As such, the Admin's architecture and the means by which it interacts with the participating IPsec Peers will vary widely from implementation to implementation. However, some basic functions of the Admin are assumed.
このドキュメント内では、管理者はデバイスでも人でもないことに注意することが重要です。むしろ、それは関数です。すべての大規模なVPN展開には、管理機能が含まれます。この機能は、スタンドアロンのワークステーション、ゲートウェイ、または管理ソフトウェアコンポーネントで実行できます。管理者機能は、ゲートウェイ、クライアントデバイス、またはソフトウェアと同じである可能性があります。それらはさまざまな機能として建築図に表されていますが、異なる物理エンティティである必要はありません。そのため、管理者のアーキテクチャと、参加するIPSECピアと対話する手段は、実装ごとに大きく異なります。ただし、管理者のいくつかの基本的な機能が想定されています。
- It, and not the PKI, will define the Certificate Policy (CP) [FRAME] for use in a VPN System. The PKC's characteristics and contents are a function of the CP. In VPN Systems, the Operator chooses to strengthen the VPN by using PKI; PKI is a bolt-on to the VPN System. The Operator will configure local security policy in part through the Admin and its authorized PKI-enabled Peers.
- PKIではなく、VPNシステムで使用するための証明書ポリシー（CP）[フレーム]を定義します。PKCの特性と内容は、CPの関数です。VPNシステムでは、オペレーターはPKIを使用してVPNを強化することを選択します。PKIは、VPNシステムのボルトオンです。オペレーターは、管理者とその認可されたPKI対応のピアを通じて、一部はローカルセキュリティポリシーを構成します。
- It will interact directly with the PKI System to initiate authorization for end entity PKCs by sending the parameters and contents for individual PKCs or batches of PKCs based on a pre-agreed template (i.e., both types of authorization requests refer to the pre-agreed template). Templates will be agreed in an out-of-band mechanism by the VPN Operator and the PKI Operator. It will receive back from the PKI a unique tuple of authorization identifiers and one-time authorization tokens that will authorize Peers to request a PKC.
- PKIシステムと直接相互作用して、事前にアグリーされたテンプレートに基づいて個々のPKCまたはPKCのバッチまたはバッチのパラメーターと内容を送信することにより、End Entity PKCの承認を開始します（つまり、両方のタイプの承認リクエストは、事前に合ったテンプレートを指します）。テンプレートは、VPNオペレーターとPKI演算子による帯域外のメカニズムで合意されます。PKIから、PKCをリクエストするためにピアを許可する1回限りの認証識別子と1回限りの承認トークンを受け取ります。
- It will deliver instructions to the IPsec Peers, and the Peers will carry out those instructions (e.g., Admin passes Peer information necessary to generate keys and PKC request).
- IPSECピアに手順を提供し、ピアはそれらの指示を実行します（たとえば、管理者とPKCリクエストを生成するために必要なピア情報を渡す管理者）。
The PKI System, as depicted in Figure 2, can be set up and operated by the Operator (in-house), be provided by third party PKI providers to which connectivity is available at the time of provisioning (managed PKI service), or be integrated with the VPN product.
図2に示すように、PKIシステムは、オペレーター（社内）によって設定および操作できます。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
Figure 3. Architectural Framework for VPN-PKI Interaction
図3. VPN-PKI相互作用のアーキテクチャフレームワーク
Requirements for each of the interactions, [A], [G], [E], [L], and [R], are addressed in Sections 3.2 through 3.6. However, only requirements for [A], [E], [L], and [R] will be addressed by the certificate management profile. Requirements for [I] transactions are beyond the scope of this document. Additionally, the act of certification (i.e., binding the public key to the name) is performed at the CA and is not shown in the figure.
各相互作用の要件[a]、[g]、[e]、[l]、および[r]は、セクション3.2〜3.6で説明されています。ただし、[a]、[e]、[l]、および[r]の要件のみが、証明書管理プロファイルによって対処されます。[i]トランザクションの要件は、このドキュメントの範囲を超えています。さらに、認証の行為（つまり、公開鍵を名前に結合する）がCAで実行され、図には示されていません。
The target profile, to be based on this requirements document, MUST call for ONE PROTOCOL or ONE USE PROFILE for each main element of the [A], [E], [L], and [R] interactions. In order to reduce complexity and improve interoperability, having multiple competing protocols or profiles to solve the same requirement should be avoided whenever possible.
ターゲットプロファイルは、この要件ドキュメントに基づくには、[a]、[e]、[l]、および[r]相互作用の各主要要素の1つのプロトコルまたは1つの使用プロファイルを呼び出す必要があります。複雑さを軽減し、相互運用性を向上させるために、同じ要件を解決するために複数の競合プロトコルまたはプロファイルを持つことは、可能な限り回避する必要があります。
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はポリシーの詳細、ID、およびキーを交換する必要があります。そのため、[a]、[e]、および[l]トランザクションの通信方法は、プライバシー、認証、およびメッセージデータの整合性を保証する方法で保護する必要があります。通信方法では、PKIと管理者の間に相互信頼を確立する必要があります（セクション3.7.1を参照）。[R]トランザクションは、応答（つまり、PKCとCRL）がすでにデジタル署名されているため、認証またはメッセージのデータの整合性を必要としません。[R]トランザクションがプライバシーを必要とするかどうかは、ローカルセキュリティポリシーによって決定されます。
The target certificate management profile will not specify [G] transactions. However, these transactions MUST be secured in a manner that ensures privacy, authentication, and message data integrity because these transactions are the basis for the other transactions.
ターゲット証明書管理プロファイルは、[G]トランザクションを指定しません。ただし、これらのトランザクションは他のトランザクションの基礎であるため、これらのトランザクションはプライバシー、認証、およびメッセージデータの整合性を保証する方法で保護する必要があります。
The Admin MUST be reachable by the Peers. Most implementations will meet this requirement by ensuring Peers can connect to the Admin from anywhere on the network or Internet. However, communication between the Admin and Peers can be "off-line". It can, in some environments, be "moving media" (i.e., the configuration or data is loaded on to a floppy disk or other media and physically moved to the IPsec Peers). Likewise, it can be entered directly on the IPsec Peer via a User Interface (UI). In this case, the Admin function is co-located on 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と管理者の間の承認取引のために、最初は可用性が必要です。ほとんどの場合、さらなる可用性が必要ですが、この可用性の範囲はオペレーターの決定ポイントです。このドキュメントのほとんどの要件とシナリオは、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トランザクションのIDに使用されるPKCには、すべての[certprofile]必須フィールドを含める必要があります。また、パスの検証と証明書のステータスチェックをサポートするために必要なコンテンツを含める必要があります。
It is preferable that the PKC profiles for IPsec transactions [IKECERTPROFILE] and VPN-PKI transactions (in the certificate management profile) are the same so that one PKC could be used for both transaction sets. If the profiles are inconsistent, then different PKCs (and perhaps different processing requirements) might be required. However, the authors urge that progress continue on other aspects of this standardization effort regardless of the status of efforts to achieve PKC profile consensus.
IPSECトランザクション[IKECERTPROFILE]およびVPN-PKIトランザクション（証明書管理プロファイル）のPKCプロファイルは同じであるため、両方のトランザクションセットに1つの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（ユーザー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.
1つのプロトコルを、管理者から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つの値（さらに多くの値も受け入れられます）が異なります。キーが生成される前に承認が発生する可能性があるため、一意の承認識別子が発行されるようにする唯一の方法は、被験者ごとに少なくとも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.
大量認証は、PKI（RA/CA）に1つの接続で発生する必要があり、被験者の数は1つ以上です。実装は、バッチ承認で1,000の被験者を処理できるはずです。
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システムのIDと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回限りの承認トークンのリストを返します（1）。応答は、特定の承認の成功、失敗、またはエラーを示している場合があります。セクション3.2.5を参照してください。
The Admin authorizes individual PKCs or batches of PKC issuances based on a pre-agreed template. This template is agreed by the VPN Operator and PKI Operator and is referred to in each authorization request. This allows the authorization requests to include the minimal amount of information necessary to support a VPN System.
管理者は、事前にアグリーされたテンプレートに基づいて、個々のPKCまたはPKC発行のバッチを承認します。このテンプレートは、VPNオペレーターとPKIオペレーターによって合意されており、各承認リクエストで言及されています。これにより、承認要求は、VPNシステムをサポートするために必要な最小限の情報を含めることができます。
The Admin can send the PKI System the set of PKC contents that it wants the PKI to issue to a group of IPsec Peers. In other words, it tells the PKI System, "if you see a PKC request that looks like this, from this person, process it and issue the PKC."
管理者は、PKIシステムに、PKIがIPSECピアのグループに発行することを望むPKCコンテンツのセットを送信できます。言い換えれば、PKIシステムに、「この人からこのように見えるPKCリクエストが表示された場合、それを処理し、PKCを発行する」と伝えます。
Requirements for PKC fields used in IPsec transactions are specified in [IKECERTPROFILE].
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.
- 管理者は、自動更新が許可されているかどうかを指定する必要があります。つまり、管理者はPKIが指定されたピアPKCの将来の更新を処理することを許可します。
- Admin MUST specify if PKC update is allowed, that is, the Admin authorizes the PKI to accept a future request for a new PKC with changes to non-key-related fields.
- 管理者は、PKCアップデートが許可されているかどうかを指定する必要があります。つまり、管理者はPKIが非キー関連フィールドの変更を伴う新しいPKCの将来の要求を受け入れることを許可します。
If a PKC renewal is authorized, the Admin MUST further specify:
PKC更新が承認されている場合、管理者はさらに指定する必要があります。
- Who can renew, that is, can only the Admin send a renewal request or can the Peer send a request directly to the PKI, or either.
- 誰が更新するか、つまり、管理者は更新リクエストを送信することしかできません。または、ピアがPKIに直接リクエストを送信することができます。
- How long before the PKC expiration date the PKI will accept and process a renewal (i.e., N% of validity period, or the UTC time after which renewal is permitted).
- PKCの有効期限の日付までの期間、PKIは更新を受け入れて処理します（つまり、有効性の期間のn％、または更新が許可されてからUTC時間）。
If a PKC update is authorized, the Admin MUST further specify:
PKCアップデートが承認されている場合、管理者はさらに指定する必要があります。
- The aspects of non-key-related fields that are changeable.
- 変更可能な非キー関連フィールドの側面。
- The entity that can send the PKC Update request, that is, only the Admin, only the Peer, or either.
- PKCアップデートリクエストを送信できるエンティティ、つまり、管理者、ピア、またはどちらの場合ものみです。
- How long before the PKC expiration date the PKI will accept and process an update (i.e., N% of validity period, or the UTC time after which update is permitted).
- PKCの有効期限の日付の期間まで、PKIは更新を受け入れて処理します（つまり、有効性期間のn％、または更新が許可されたUTC時間）。
A new authorization by the Admin is REQUIRED for PKC rekey. No parameters of prior authorizations need be considered.
PKC Rekeには、管理者による新しい承認が必要です。事前の承認のパラメーターを考慮する必要はありません。
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および1回限りの承認トークンの形式を指定する機能を備えている必要があります。1回限りの承認トークンは、承認IDごとに一意である必要があります。承認IDとその1回限りの承認トークンとの関係で達成できるランダム性が高いほど、より良い。1回限りの認証トークンは、国際的なキャラクターのために発生する可能性のある非互換性を避けるために、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およびその1回限りの承認トークンの検証期間を指定するオプションが必要です。そのような検証期間が設定されている場合、承認IDを使用してPKC要求と、検証期間以外のPKIに到達する1回限りの承認トークンを削除する必要があり、イベントが記録されます。
The Protocol SHOULD consider what happens when Admin-requested information conflicts with PKI settings such that the Admin request cannot be issued as requested (e.g., Admin requests validation period = 3 weeks and CA is configured to only allow validation periods = 1 week). Proper conflict handling MUST be specified.
プロトコルは、管理者が要求されたとおりに発行できないように、管理者が要求することがPKI設定と競合する場合に何が起こるかを考慮する必要があります（たとえば、管理要求検証期間= 3週間、CAは検証期間= 1週間のみを許可するように構成されます）。適切な競合処理を指定する必要があります。
Either the Admin or the Peer can send a cancel authorization message to PKI. The canceling entity MUST provide the authorization ID and one-time authorization token in order to cancel the authorization. At that point, the authorization will be erased from the PKI, and a log entry of the event written.
管理者またはピアのいずれかが、PKIにキャンセル承認メッセージを送信できます。キャンセルエンティティは、承認をキャンセルするために、承認IDおよび1回限りの承認トークンを提供する必要があります。その時点で、許可は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ごとに1回限りの承認トークンを使用して管理者に応答します。追加の承認IDおよび1回限りの承認トークン要件については、セクション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認可に「はい」と返信できる必要があります。
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要求を構築することです。重要な世代は、現地の要件に応じて、3つの場所のいずれかで発生する可能性があります。IPSECピア、管理者、またはPKIです。PKCリクエストは、ピアと管理者の組み合わせであるIPSECピアのいずれかから得られます。
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.
このオプションは、最も頻繁にフィールドで使用されます。これはキーイングの最も安全な方法です。キーは最終エンティティで生成され、秘密鍵が終了エンティティを離れることはありません。ただし、PKCリクエストの生成とデジタル署名をサポートするために「ASN.1認識」でなければならないため、ピアにとって最も計算的に集中的です。
+--------------+ +-----------------------+
| 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要求を生成するためにピアが必要とする承認識別子、1回限りの承認トークン、およびその他のパラメーターを送信します。
2) Generation [G]. Peer receives authorization identifier, one-time authorization token, and any parameters. Peer generates key pair and constructs PKC request.
2) 生成[G]。ピアは、承認識別子、1回限りの承認トークン、およびパラメーターを受け取ります。ピアはキーペアを生成し、PKCリクエストを構築します。
Steps prior to these can be found in Section 3.2. The next step, enrollment, can occur either directly between the Peer and PKI (see Section 3.4.5) or through the Admin (see Section 3.4.6).
これらの前の手順は、セクション3.2にあります。次のステップである登録は、ピアとPKI（セクション3.4.5を参照）の間で直接発生するか、管理者を介して発生する可能性があります（セクション3.4.6を参照）。
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を参照）。
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と携帯電話の場合、処理とバッテリーの制約のために動作的に不可能です。別のケースは、IPSECに加えて他の機能に同じPKCが使用され、キーリカバリが必要である主要な回復要件をカバーします（例：ローカルデータ暗号化）。したがって、ピアからキーエスクローが必要です。キーエスクローが実行された場合、そのための正確な要件と手順は、このドキュメントの範囲を超えています。
+--------------+ +-----------------------+
| 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を事前に許可することを許可されている唯一の1つですが、オペレーター2はバッチ登録とVPNデバイス構成を実行するものです。
This option exists for deployments where end entities cannot generate their own key pairs and the Admin function is a minimal implementation. The PKI and Admin pre-agree to have the PKI generate key pairs and PKCs. This is, in all likelihood, the easiest way to deploy PKCs, though it sacrifices some security since both the CA and the Admin have access to the private key. However, in cases where key escrow is required, this may be acceptable. The Admin effectively acts as a proxy for the Peer in the PKC enrollment process.
このオプションは、終了エンティティが独自の重要なペアを生成できず、管理機能が最小限の実装である展開に存在します。PKIと管理者は、PKIにキーペアとPKCを生成するための事前アグリです。これは、おそらく、PKCを展開する最も簡単な方法ですが、CAと管理者の両方が秘密鍵にアクセスできるため、セキュリティを犠牲にします。ただし、キーエスクローが必要な場合は、これが許容される場合があります。管理者は、PKC登録プロセスのピアのプロキシとして効果的に機能します。
+--------------+ +-----------------------+
| Repository | | CA/RA | 1
+--------------+ +-----------------------+
+-------+
| 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.
登録リクエスト、応答、および確認には、1つのプロトコルを指定する必要があります。
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にこのような重要なペアを持っていることを証明する必要があります。これは通常、最終エンティティに非CEを送信する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
図9. VPN-PKI相互作用手順：IPSECピアはキーとPKCリクエストを生成し、PKIに直接登録します
1) Enrollment Request [E]. The IPsec Peer sends PKC requests to the PKI, providing the generated public key.
1) 登録リクエスト[e]。IPSECピアはPKCリクエストをPKIに送信し、生成された公開キーを提供します。
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パワーがあります。この場合、最終エンティティは、そのような重要なペアを持っていることを管理者に証明する必要があります。これは通常、管理者が最終エンティティに非CEを送信することによって行われます。これは、End Entityの公開キーとともに、End Entityが管理者に署名して戻ります。
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
図10. VPN-PKI相互作用手順：IPSECピアはキーとPKCリクエストを生成し、管理者を介して登録します
1) Opaque Transaction [E]. The IPsec Peer requests a PKC from the Admin, providing the generated public key.
1) 不透明なトランザクション[E]。IPSECピアは管理者からPKCを要求し、生成された公開キーを提供します。
2) Enrollment Request [E]. The Admin forwards the enrollment request to the PKI.
2) 登録リクエスト[e]。管理者は、登録要求をPKIに転送します。
3) Enrollment Response [E]. The PKI responds to the enrollment request, providing either the new PKC that was generated or a suitable error indication.
3) 登録応答[E]。PKIは登録要求に応答し、生成された新しいPKCまたは適切なエラー表示を提供します。
4) Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer.
4) 不透明なトランザクション[E]。管理者は、登録応答をIPSECピアに転送します。
5) Opaque Transaction [E]. Peer positively acknowledges receipt of new PKC back to the Admin.
5) 不透明なトランザクション[E]。ピアは、新しいPKCの受領を管理者に積極的に認めています。
6) Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI.
6) 登録確認[E]。admin Forwards登録確認は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が管理者にノンセを送信することによって行われます。これは、管理者がEnd Entityの公開キーとともに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
図11. VPN-PKI相互作用手順：IPSECピアは、キー、管理者コンストラクト、および署名PKCリクエストを生成し、管理者を介して登録します
1) Enrollment Request [E]. The Admin requests a PKC from the PKI, providing the generated public key.
1) 登録リクエスト[e]。管理者は、PKIからPKCを要求し、生成された公開キーを提供します。
2) Enrollment Response [E]. The PKI responds to the enrollment request, providing either the new PKC that was generated or a suitable error indication.
2) 登録応答[E]。PKIは登録要求に応答し、生成された新しいPKCまたは適切なエラー表示を提供します。
3) Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer.
3) 不透明なトランザクション[E]。管理者は、登録応答をIPSECピアに転送します。
4) Opaque Transaction [E]. Peer positively acknowledges receipt of new PKC back to the Admin.
4) 不透明なトランザクション[E]。ピアは、新しいPKCの受領を管理者に積極的に認めています。
5) Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI.
5) 登録確認[E]。admin Forwards登録確認は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の登録確認領収書をピアに転送します。
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が管理者にノンセを送信することによって行われます。これは、管理者がEnd Entityの公開キーとともに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]。admin Forwards登録確認は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の登録確認領収書をピアに転送します。
In this instance, the PKI and Admin have previously agreed to have the PKI generate keys and certificates when the PKI receives an authorization request. The PKI returns to the IPsec Peer through the Admin, the final product of a key pair and PKC. Again, the mechanism for the Peer to Admin communication is opaque.
この例では、PKIと管理者は、PKIが承認要求を受け取ったときに、PKIにキーと証明書を生成することに以前に合意しています。PKIは、キーペアと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
図13. VPN-PKI相互作用手順：PKIはキー、PKCリクエストを生成し、PKIに直接登録します
1) Enrollment Response [E]. The PKI responds to the authorization request sent, providing either the new PKC and public-private key pair that were generated or a suitable error indication.
1) 登録応答[E]。PKIは送信された承認要求に応答し、生成された新しいPKCと官民のキーペアまたは適切なエラー表示のいずれかを提供します。
2) Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer, along with the keys.
2) 不透明なトランザクション[E]。管理者は、登録応答をキーとともにIPSECピアに転送します。
3) Opaque Transaction [E]. Peer positively acknowledge receipt of new PKC back to the Admin.
3) 不透明なトランザクション[E]。ピアは、新しいPKCの受領を管理者に戻すことを積極的に認めます。
4) Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI.
4) 登録確認[E]。admin Forwards登録確認は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を受け取ったことを確認し、ロードし、IKE交換で効果的に使用できることを確認して、PKIに確認を送信する必要があります。この要件は次のように存在します。
- The PKI does not publish the new PKC in the repository for others until that PKC is able to be used effectively by the Peer, and
- PKIは、PKCがピアによって効果的に使用できるようになるまで、他の人のためにリポジトリに新しいPKCを公開しません。
- A revocation may be invoked if the PKC is not received and operational within an allowable window of time.
- PKCが許容される時間の窓内で受信され、動作可能になっていない場合、取り消しが呼び出される場合があります。
To assert such proof, the Peer MUST sign a portion of data with the new key. The result MUST be sent to the PKI. The entity that actually sends the result to the PKI MAY be either the Peer (sending it directly to the PKI) or Admin (the Peer would send it to Admin, and Admin can, in turn, send it to the PKI).
そのような証拠を主張するには、ピアはデータの一部に新しいキーを使用して署名する必要があります。結果はPKIに送信する必要があります。実際にPKIに結果を送信するエンティティは、ピア（PKIに直接送信）または管理者（ピアが管理者に送信し、管理者がPKIに送信できます）のいずれかです。
The Admin MUST acknowledge the successful receipt of the confirmation, thus signaling to the Peer that it may proceed using this PKC in IKE connections. The PKI MUST complete all the processing necessary to enable the Peer's operational use of the new PKC (for example, writing the PKC to the repository) before sending the confirmation acknowledgement. The Peer MUST NOT begin using the PKC until the PKI's confirmation acknowledgement has been received.
管理者は、確認の成功した受領を認めなければならないため、このPKCを使用してIKE接続を使用して進行する可能性があることをピアに知らせなければなりません。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を送信しましたが、要求者（管理者またはピア）はそれを受け取りませんでした。
- The Requestor (Admin or Peer) received the PKC, but could not process it due to incorrect contents, or other PKC-construction-related problem.
- リクエスター（管理者またはピア）はPKCを受け取りましたが、誤った内容または他のPKC構成関連の問題のために処理できませんでした。
- The Requestor failed trying to generate the confirmation.
- 要求者は、確認を生成しようとして失敗しました。
- The Requestor failed trying to send the confirmation.
- 要求者は、確認を送信しようとして失敗しました。
- The Requestor sent the confirmation, but the PKI did not receive it.
- 要求者は確認を送信しましたが、PKIはそれを受け取りませんでした。
- The PKI received the confirmation but could not process it.
- PKIは確認を受けましたが、処理できませんでした。
In each case the following questions MUST be addressed:
いずれの場合も、次の質問に対処する必要があります。
- What does Peer do? - What does Admin do? - What does PKI do? - Is Authorization used?
- ピアは何をしますか？ - 管理者は何をしますか？ - 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と1回限りの承認トークンで再リケストする必要があります。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がEnd Entity PeerのPKCを発行したら、ピアは、その後のRekey、更新、更新、または取消しについて、PKIに直接または管理者を介して連絡できる必要があります。PKIは、更新、更新、および取り消しのいずれかのケースをサポートする必要があります。Rekeysは管理されています。したがって、ピアが開始されたRekeysは、管理者を介して転送されなければなりません。
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.
1つのプロトコルを、リクエー、更新、および更新するために指定する必要があります。セクション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.
取り消しリクエストは、Rekey、Renew、および更新操作と同じプロトコルを使用する場合があります。取り消しリクエストは、電子メール、電話、インスタントメッセージングなどでも発生する場合があります。
Rekeys, renewals, and updates are variants of a PKC enrollment request scenario with unique operational and management requirements.
Rekeys、更新、および更新は、独自の運用および管理要件を備えた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 Rekeyは、End EntityのPKCを、End Entityが現在保持されているPKCの有効期限が切れる前に、同じ件名とsubjectaltnameコンテンツの新しい公開キーを持つ新しい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と同じ件名および件名のアルタルティブヴィンゲームのコンテンツについて、エンドエンティティの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の有効期限の前に、件名または件名の変更されたAlternativenameの同じ公開キーを使用した新しい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.
Rekey、更新、または更新リクエストを送信する場合、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.
Rekey、Renew、および更新リクエストは、古いPKCの秘密鍵によって署名する必要があります。これにより、PKIは要求者の身元を検証し、攻撃者がリクエストを送信せず、別のエンティティの身元を持つPKCを受け取ることができます。
Whether or not a new key is used for the new PKC in a renew or update scenario is a matter of local security policy, and MUST be specified by the Admin to the PKI in the original authorization request. Reusing the same key is permitted, but not encouraged. If a new key is used, the update or renew request must be signed by both the old key -- to prove the right to make the request -- and the new key -- to use for the new PKC.
更新または更新シナリオで新しいPKCに新しいキーが使用されるかどうかは、ローカルセキュリティポリシーの問題であり、元の承認要求で管理者によってPKIに指定する必要があります。同じキーを再利用することは許可されていますが、奨励されていません。新しいキーを使用する場合、更新または更新リクエストは、新しいPKCに使用するリクエストと新しいキーを作成する権利を証明するために、古いキーの両方によって署名する必要があります。
The new PKC resulting from a rekey, renew, or update will be retrieved in-band, using the same mechanism as a new PKC request.
再キー、更新、または更新に起因する新しいPKCは、新しいPKC要求と同じメカニズムを使用して、帯域内で取得されます。
For the duration of time after a rekey, renew, or update has been processed and before PKI has received confirmation of the Peer's successful receipt of the new PKC, both PKCs (the old and the new) for the end entity will be valid. This will allow the Peer to continue with uninterrupted IKE connections with the previous PKC while the rekey, renewal, or update process occurs.
再キー、更新、または更新後の期間中、PKIがピアの新しいPKCの成功した受領の確認を受ける前に、最終エンティティのPKC（古いものと新しい）の両方が有効になります。これにより、ピアは、再キー、更新、または更新プロセスが発生しながら、以前のPKCとの途切れない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がEnd Entity Peerの確認（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.
更新または更新リクエストのために新しいキーが生成された場合、Rekeyリクエストの場合、ピアが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.
管理者はRekeysを管理して、新しいキーを持つピアによるVPNの途切れない使用を確保します。管理者がREKEYの新しい承認を開始するように構成されている場合、Rekeysは自動的に発生する可能性があります。
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.
Rekeyのシナリオは、セクション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.
- キー：新しい、既存、またはどちらか。-liesceor：エンティティのピア、管理者、またはいずれか。 - 期間：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の内容の更新は、End Entity PeerのIDの変更に関する詳細が必要な場合に必要ですが、オペレーターはゼロから新しいPKCを生成したくないため、まったく新しい承認が必要です。たとえば、ゲートウェイデバイスをあるサイトから別のサイトに移動できます。そのIPv4アドレスは、subjectaltname拡張機能で変更されますが、他のすべての情報は同じままである可能性があります。別の例は、結婚して姓を変更するか、ある部門から別の部門に移動するエンドユーザーです。どちらの場合でも、DNの1つのフィールド（姓または組織ユニット（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.
- 更新イベントのタイミングは予測できません。スケジュールされたRekeyまたは更新の場合のように。
- 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.
- キー：新しい、既存、またはどちらか。-liesceor：エンティティのピア、管理者、またはいずれか。 - 変更可能なサブジェクトおよび主題のフィールド。 - 時間：古い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).
元の認可時に更新承認が行われなかった場合、PKCの有効な寿命の間、いつでも管理者からPKIに行うことができます。このような更新が必要な場合、管理者は更新が最終エンティティに対して許可されていることをPKIシステムに通知する必要があり、新しいコンテンツを指定する必要があります。その後、管理者は、VPNシステムが採用するメカニズム（End End EntityからPKIへの直接、Endエンティティから管理者、または直接管理者から）で与えられたコンテンツを使用して更新要求を開始します。
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.
REKEY、更新、または更新プロセスの各トランザクションには、徹底的なエラー状態の説明と処理手順が必要です。このようなエラーコードを提供することで、PKI製品とIPSEC製品間の相互運用性の取り組みが大幅に支援されます。
The confirmation handshake requirements are the same as in Sections 3.2, 3.3, and 3.4 except that depending on the Administrative policy the PKI MUST also issue a revocation on the original PKC before sending the confirmation response.
確認補助金の要件は、セクション3.2、3.3、および3.4と同じです。
The Peer MUST be able to initiate revocation for its own PKC. In this case the revocation request MUST be signed by the Peer's current key pair for the PKC it wishes to revoke. Whether the actual revocation request transaction occurs directly with the PKI or is first sent to Admin (who proxies or forwards the request to the PKI) is a matter of implementation.
ピアは、独自のPKCの取り消しを開始できる必要があります。この場合、取り消し要求は、取り消したいPKCのピアの現在のキーペアによって署名されなければなりません。実際の取り消し要求トランザクションがPKIで直接発生するか、最初に管理者に送信されるか（リクエストをPKIに依頼または転送する）かどうかは、実装の問題です。
The Admin MUST be able to initiate revocation for any PKC issued under a template it controls. The Admin will identify itself to the PKI by use of its own PKC; it MUST sign any revocation request to the PKI with the private key from its own PKC. The PKI MUST have the ability to configure Admin(s) with revocation authority, as identified by its PKC. Any PKC authorizations must specify if said PKC may be revoked by the Admin (see Section 3.2.3.2 for more details).
管理者は、制御するテンプレートで発行されたPKCの取り消しを開始できる必要があります。管理者は、独自のPKCを使用することにより、PKIに自分自身を識別します。独自のPKCからの秘密鍵を使用して、PKIへの取り消しリクエストに署名する必要があります。PKIには、PKCで識別されるように、取り消し当局で管理者を構成する機能が必要です。PKCの承認は、上記のPKCが管理者によって取り消される可能性があるかどうかを指定する必要があります（詳細については、セクション3.2.3.2を参照）。
The profile MUST identify the one protocol or transaction within a protocol to be used for both Peer and Admin initiated revocations.
プロファイルは、ピアと管理者が開始された回収の両方に使用されるプロトコル内の1つのプロトコルまたはトランザクションを識別する必要があります。
The profile MUST identify the size of CRL the client will be prepared to support.
プロファイルは、クライアントがサポートする準備をするCRLのサイズを識別する必要があります。
Below are guidelines for revocation in specific transactions:
以下は、特定のトランザクションにおける取り消しのガイドラインです。
- AFTER RENEW, BEFORE EXPIRATION: The PKI MUST be responsible for the PKC revocation during a renew transaction. PKI MUST revoke the PKC after receiving the confirm notification from the Peer, and before sending the confirm-ack to the Peer. The Peer MUST NOT revoke its own PKC in this case.
- 更新後、有効期限：PKIは、更新トランザクション中のPKC取り消しの責任を負わなければなりません。PKIは、ピアから確認通知を受け取った後、およびピアに確認済みを送信する前に、PKCを取り消す必要があります。この場合、ピアは独自のPKCを取り消してはなりません。
- AFTER UPDATE, BEFORE EXPIRATION: The PKI MUST be responsible for the PKC revocation during an update transaction. PKI MUST revoke the PKC after receiving the confirm notification from the Peer, and before sending the confirm-ack to the Peer. The Peer MUST NOT revoke its own PKC in this case.
- 更新後、有効期限：PKIは、更新トランザクション中のPKC失効の責任を負わなければなりません。PKIは、ピアから確認通知を受け取った後、およびピアに確認済みを送信する前に、PKCを取り消す必要があります。この場合、ピアは独自のPKCを取り消してはなりません。
This section refers to the [R] elements labeled in Figure 3.
このセクションでは、図3にラベル付けされている[R]要素について説明します。
The PKI System SHOULD be built so that lookups resolve directly and completely at the URL indicated in a CDP or AIA. The PKI SHOULD be built such that URL contents do not contain referrals to other hosts or URLs, as such referral lookups will increase the time to complete the IKE negotiation, and can cause implementations to timeout.
PKIシステムは、CDPまたはAIAに示されているURLで直接かつ完全に解決できるように、構築する必要があります。PKIは、URLの内容に他のホストまたはURLへの紹介が含まれていないように構築する必要があります。そのような紹介の検索により、IKEの交渉を完了する時間が増え、実装がタイムアウトを引き起こす可能性があります。
CDP MUST be flagged as required in the authorization request. The method MUST also be specified: the HTTP method MUST be method; the Lightweight Directory Access Protocol (LDAP) method MAY be supported.
CDPは、承認リクエストで必要に応じてフラグを立てる必要があります。メソッドも指定する必要があります。HTTPメソッドはメソッドでなければなりません。Lightweight Directory Access Protocol（LDAP）メソッドがサポートされる場合があります。
The complete hierarchical PKC chain (except the trust anchor) MUST be able to be searched in their respective repositories. The information to accomplish these searches MUST be adequately communicated in the PKCs sent during the IKE transaction.
完全な階層PKCチェーン（トラストアンカーを除く）は、それぞれのリポジトリで検索できる必要があります。これらの検索を達成するための情報は、IKEトランザクション中に送信されたPKCで適切に伝達される必要があります。
All PKCs must be retrievable through a single protocol. The final specification will identify one protocol as a "MUST", others MAY be listed as "OPTIONAL".
すべてのPKCは、単一のプロトコルを介して取得できる必要があります。最終的な仕様では、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.
CAまたは複数のCAが存在するPKIシステムを再キーする場合には、中間PKCが必要になります。
PKCs MAY have extendedKeyusage to help identify the proper PKC for IPsec, though the default behavior is to not use them (see 3.1.5.3).
PKCは、IPSecの適切なPKCを特定するのに役立つKeyUsageを拡張している可能性がありますが、デフォルトの動作はそれらを使用しないことです（3.1.5.3を参照）。
IPsec Peers MUST be able to resolve Internet domain names and support the mandatory repository access protocol at the time of starting up so they can perform the PKC lookups.
IPSECピアは、インターネットドメイン名を解決し、開始時に必須のリポジトリアクセスプロトコルをサポートして、PKCルックアップを実行できる必要があります。
IPsec Peers should cache PKCs to reduce latency in setting up Phase 1. Note that this is an operational issue, not an interoperability issue.
IPSECピアは、PKCをキャッシュしてフェーズ1を設定する際の遅延を減らす必要があります。これは、相互運用性の問題ではなく、運用上の問題であることに注意してください。
The use case for accomplishing lookups when PKCs are not sent in IKE is a stated non-goal of the profile at this time.
IKEでPKCが送信されない場合にルックアップを達成するためのユースケースは、現時点ではプロファイルの記載されていないものです。
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は、2つの方法のいずれかを介してピアに到着する必要があります。
(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セキュリティ協会に適用されるパラメーターに基づいてID検証を実行する必要があります。検証に使用されるPKCのフィールドには、サブジェクト名内のx.500著作権名（DN）、または拡張件名内の特定のフィールド（[doi] 4.6.2.1識別タイプ値）のいずれかを含めることができます。それぞれの使用の説明。
The Peers or a Simple Certificate Validation Protocol (SCVP) server MUST validate the certification path, as per RFC 3280. The contents necessary in the PKC to allow this will be enumerated in the profile document.
ピアまたは単純な証明書検証プロトコル（SCVP）サーバーは、RFC 3280に従って、PKCで必要な内容をプロファイルドキュメントに列挙します。
The Peer MAY have the ability to construct the certification path itself; however, Admin MUST be able to supply Peers with the trust anchor and any chaining PKCs necessary. The Admin MAY ensure the template uses the AIA extension in PKCs as a means of facilitating path validation.
ピアは、認証パス自体を構築する機能を持っている場合があります。ただし、管理者は、信頼のアンカーと必要なチェーンPKCを仲間に提供できる必要があります。管理者は、パス検証を促進する手段として、テンプレートがPKCSのAIA拡張機能を使用することを確認できます。
DNS MUST be supported by the Peers in order to support resolving URLs present in CDPs and AIA extensions.
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 IDのために提示されている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とauthoridinfoaccessフィールドが必要です。これにより、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サービスにアクセスせずにネットワークを介して通信している場合に望まれる場合があります。取り消しチェックがオフの場合、実装はPKCを交換で有効なIDとして使用するように進む必要があり、チェックを実行する必要はありません。
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の認証などです。）
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.
[必須] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[CERTPROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[CertProfile] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[doi] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[Frame] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C。、およびS. Wu、「インターネットX.509公開キーインフラストラクチャ証明書ポリシーおよび認証慣行フレームワーク」、RFC 3647、2003年11月。
[IKECERTPROFILE] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, February 2007.
[IkecertProfile] Korver、B。、「IKEV1/ISAKMP、IKEV2、およびPKIXのインターネットIPセキュリティPKIプロファイル」、2007年2月、進行中のWork。
[IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKEV1] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC] Kent、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は、Project Dpolieによって開発された以前のドキュメントに実質的に基づいています。そのドキュメントの主要な編集者は、Gregory M. Lebovitz（Netscreen/Juniper）でした。寄稿者には、Lebovitz、Paul Hoffman（VPN Consortium）、Hank Mauldin（Cisco Systems）、Jussi Kukkonen（SSH Communications Security）が含まれます。レオ・プラスウィック（ICSA）、ティム・ポーク（NIST）、クリス・ウェルズ（セーフェネット）、トーマス・ハードジョノ（ヴェリシン）、カーライル・アダムス（委託）、マイケル・シー（ネットシュリーン/ジュニパー）によって大幅な編集上の貢献が行われました。
Once brought to the IETF's PKI4IPSEC WG, the following people made substantial contributions: Jim Schaad and Stefan Santesson.
IETFのPKI4IPSEC WGに持ち込まれると、次の人々はJim SchaadとStefan Santessonの大きな貢献をしました。
Editors' Addresses
編集者のアドレス
Chris Bonatti IECA, Inc. EMail: Bonattic@ieca.com
Chris Bonatti Ieca、Inc。電子メール：bonattic@ieca.com
Sean Turner IECA, Inc. EMail: Turners@ieca.com
Sean Turner IECA、Inc。電子メール：Tunlers@ieca.com
Gregory M. Lebovitz Juniper EMail: gregory.ietf@gmail.com
GREGORY M. LEBOVITZ JUNIPERメール：gregory.ietf@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。