RFC4809 日本語訳
4809 Requirements for an IPsec Certificate Management Profile. C.Bonatti, Ed., S. Turner, Ed., G. Lebovitz, Ed.. February 2007. (Format: TXT=98400 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Bonatti, Ed.
Request for Comments: 4809 S. Turner, Ed.
Category: Informational IECA
G. Lebovitz, Ed.
Juniper
February 2007
ワーキンググループC.Bonatti、エドをネットワークでつないでください。コメントのために以下を要求してください。 4809秒間エドターナー、カテゴリ: エド情報のIECA G.Lebovitz、杜松2007年2月
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).
IETFが信じる著作権(C)(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)と公開鍵暗号基盤(PKI)システムを使用することでインターネット・プロトコル・セキュリティー(IPsec)の仮想の兵士のNetwork(VPN)システムの間のPublic Key Certificate(PKC)lifecycleトランザクションを扱うという要件を説明して、特定します。これらの要件は、企業スケールIPsec VPN展開の需要を満たすように設計されています。 管理プロトコルの標準化過程プロフィールがこれらの要件の多くを扱うために作成されることを意図します。
Bonatti, et al. Informational [Page 1] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[1ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope ......................................................5
1.2. Non-Goals ..................................................6
1.3. Definitions ................................................6
1.4. Requirements Terminology ...................................8
2. Architecture ....................................................9
2.1. VPN System .................................................9
2.1.1. IPsec Peer(s) .......................................9
2.1.2. VPN Administration Function (Admin) .................9
2.2. PKI System ................................................10
2.3. VPN-PKI Interaction .......................................11
3. Requirements ...................................................13
3.1. General Requirements ......................................13
3.1.1. One Protocol .......................................13
3.1.2. Secure Transactions ................................13
3.1.3. Admin Availability .................................13
3.1.4. PKI Availability ...................................14
3.1.5. End-User Transparency ..............................14
3.1.6. PKC Profile for PKI Interaction ....................14
3.1.6.1. Identity ..................................15
3.1.6.2. Key Usage .................................15
3.1.6.3. Extended Key Usage ........................15
3.1.6.4. Revocation Information Location ...........15
3.1.7. Error Handling .....................................15
3.2. Authorization .............................................15
3.2.1. One Protocol .......................................15
3.2.2. Bulk Authorization .................................16
3.2.3. Authorization Scenario .............................16
3.2.4. Authorization Request ..............................17
3.2.4.1. Specifying Fields within the PKC ..........17
3.2.4.2. Authorizations for Rekey, Renewal,
and Update ................................18
3.2.4.3. Other Authorization Elements ..............18
3.2.4.4. Cancel Capability .........................19
3.2.5. Authorization Response .............................19
3.2.5.1. Error Handling for Authorization ..........20
3.3. Generation ................................................20
3.3.1. Generation Method 1: IPsec Peer Generates Key Pair,
Constructs PKC Request, and Signs PKC Request ......21
3.3.2. Generation Method 2: IPsec Peer Generates Key Pair,
Admin Constructs PKS Request, Admin Signs PKC
Request ............................................22
3.3.3. Generation Method 3: Admin Generates Key Pair,
Constructs PKC Request, and Signs PKC Request ......23
3.3.4. Method 4: PKI Generates Key Pair ...................24
3.3.5. Error Handling for Generation ......................25
1. 序論…4 1.1. 範囲…5 1.2. 非目標…6 1.3. 定義…6 1.4. 要件用語…8 2. アーキテクチャ…9 2.1. VPNシステム…9 2.1.1. IPsec同輩…9 2.1.2. VPN政権機能(アドミン)…9 2.2. PKIシステム…10 2.3. VPN-PKI相互作用…11 3. 要件…13 3.1. 一般要件…13 3.1.1. 1つのプロトコル…13 3.1.2. トランザクションを保証してください…13 3.1.3. アドミンの有用性…13 3.1.4. PKIの有用性…14 3.1.5. エンドユーザ透明…14 3.1.6. PKI相互作用のためのPKCプロフィール…14 3.1.6.1. アイデンティティ…15 3.1.6.2. 主要な用法…15 3.1.6.3. 主要な用法を広げています…15 3.1.6.4. 取消し情報位置…15 3.1.7. エラー処理…15 3.2. 承認…15 3.2.1. 1つのプロトコル…15 3.2.2. 承認を膨らませてください…16 3.2.3. 承認シナリオ…16 3.2.4. 承認要求…17 3.2.4.1. PKCの中で分野を指定します…17 3.2.4.2. Rekeyのための承認、更新、およびアップデート…18 3.2.4.3. 他のAuthorization Elements…18 3.2.4.4. 能力を取り消してください…19 3.2.5. 承認応答…19 3.2.5.1. 承認のためのエラー処理…20 3.3. 世代…20 3.3.1. 世代、メソッド1: IPsec同輩は、主要な組を生成して、PKCの要求を構成して、PKCの要求に署名します…21 3.3.2. 世代、メソッド2: アドミン構造物PKSは、IPsec同輩が主要な組を生成するよう要求して、アドミンはPKCの要求に署名します…22 3.3.3. 世代、メソッド3: アドミンは、主要な組を生成して、PKCの要求を構成して、PKCの要求に署名します…23 3.3.4. メソッド4: PKIは主要な組を生成します…24 3.3.5. 世代のためのエラー処理…25
Bonatti, et al. Informational [Page 2] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[2ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.4. Enrollment ................................................25
3.4.1. One Protocol .......................................25
3.4.2. On-line Protocol ...................................25
3.4.3. Single Connection with Immediate Response ..........25
3.4.4. Manual Approval Option .............................25
3.4.5. Enrollment Method 1: Peer Enrolls to PKI Directly ..26
3.4.6. Enrollment Method 2a: Peer Enrolls through Admin ...27
3.4.7. Enrollment Method 2b: Peer Enrolls through Admin ...28
3.4.8. Enrollment Method 3a: Admin Authorizes and
Enrolls Directly to PKI ............................30
3.4.9. Enrollment Method 3b: Admin Requests and PKI
Generates and Sends PKC ............................31
3.4.10. Confirmation Handshake ............................32
3.4.11. Error Handling for Enrollment .....................33
3.5. Lifecycle .................................................34
3.5.1. One Protocol .......................................34
3.5.2. PKC Rekeys, Renewals, and Updates ..................35
3.5.2.1. Rekey Request .............................36
3.5.2.2. Renew Request .............................36
3.5.2.3. Update Request ............................37
3.5.2.4. Error Handling for Rekey, Renewal,
and Update ................................38
3.5.2.5. Confirmation Handshakes ...................38
3.5.3. Revocation .........................................38
3.6. Repositories ..............................................39
3.6.1. Lookups ............................................39
3.6.2. Error Handling for Repository Lookups ..............40
3.7. Trust .....................................................40
3.7.1. Trust Anchor PKC Acquisition .......................40
3.7.2. Certification Path Validation ......................41
3.7.3. Revocation Checking and Status Information .........41
3.7.4. Error Handling in Revocation Checking and
Certificate Path Validation ........................42
4. Security Considerations ........................................42
5. References .....................................................43
5.1. Normative References ......................................43
5.2. Informative References ....................................43
6. Acknowledgements ...............................................43
3.4. 登録…25 3.4.1. 1つのプロトコル…25 3.4.2. オンラインで、議定書を作ってください…25 3.4.3. 即時型反応がある単独結合…25 3.4.4. 手動の承認のオプション…25 3.4.5. 登録メソッド1: 同輩は直接PKIに登録します。26 3.4.6. 登録メソッド2a: 同輩はアドミンを通して登録します…27 3.4.7. 登録メソッド2b: 同輩はアドミンを通して登録します…28 3.4.8. 登録メソッド3a: アドミンは、直接PKIに…を認可して、登録します…30 3.4.9. 登録メソッド3b: アドミン要求とPKIはPKCを生成して、送ります…31 3.4.10. 確認握手…32 3.4.11. 登録のためのエラー処理…33 3.5. Lifecycle…34 3.5.1. 1つのプロトコル…34 3.5.2. PKC Rekeys、更新、およびアップデート…35 3.5.2.1. Rekey要求…36 3.5.2.2. 要求を更新してください…36 3.5.2.3. 要求をアップデートしてください…37 3.5.2.4. Rekeyのためのエラー処理、更新、およびアップデート…38 3.5.2.5. 確認握手…38 3.5.3. 取消し…38 3.6. 倉庫…39 3.6.1. ルックアップ…39 3.6.2. 倉庫ルックアップのためのエラー処理…40 3.7. 信じます。40 3.7.1. アンカーPKCの獲得を信じてください…40 3.7.2. 証明経路合法化…41 3.7.3. 取消しの照合と状態情報…41 3.7.4. 取消しの照合と証明書経路合法化におけるエラー処理…42 4. セキュリティ問題…42 5. 参照…43 5.1. 標準の参照…43 5.2. 有益な参照…43 6. 承認…43
Bonatti, et al. Informational [Page 3] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[3ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
1. Introduction
1. 序論
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 Systemsを使用することで[IPsec]VPN Systemsの間のPKC lifecycleトランザクションを扱うという要件を説明して、特定します。このドキュメントはトランザクションベースのアプローチのための要件を含んでいます。 他のモデルが想像できる、例えば、ディレクトリ中心のアプローチ、しかし、彼らの要件はこのドキュメントの範囲を超えています。
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 SystemとPKI System製品の間のPublic Key Certificate(PKC)lifecycleトランザクションのための要件を列挙します。 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 Systemのための全体のPKC lifecycleのためにトランザクションを扱います: 承認(PKCの発行の)、世代(公共の秘密鍵組とPKCの要求)、登録(PKCの要求、PKCの応答、および確認)、メインテナンス(rekeyして、更新して、アップデートして、取り消して、確認する)、および倉庫ルックアップ。 これらのトランザクションは、以下のことをVPN Operatorは可能にします。
- 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政権機能(アドミン)を使用してください。(それは、PKC承認を管理して、ことによるとVPN SystemとPKI Systemのための唯一のインタフェースとして機能するように本書では導入されます)。
- 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 Peersへのマシンのアイデンティティ。
- Set the corresponding gateway or client authorization policy for
remote access and site-to-site connections.
- 遠隔アクセスとサイトからサイトとの接続のための対応するゲートウェイかクライアント承認方針を設定してください。
- Establish policies for automatic PKC rekeys, renewals, and
updates.
- 自動PKC「再-キー」、更新、およびアップデートのための方針を確立してください。
- Ensure timely revocation information is available for PKCs used
in IKE exchanges.
- タイムリーな取消し情報がIKE交換に使用されるPKCsに利用可能であることを確実にしてください。
Bonatti, et al. Informational [Page 4] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[4ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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 SystemがPKI Systemとコミュニケートするのに使用する証明書管理プロトコルの輪郭を描くのにこれらの要件が使用されることを意図します。 このプロフィールが別のドキュメントにあることに注意してください。 証明書管理プロフィールは、既存のPKIX(X.509 Certificatesのための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 System展開を可能にして、そうするために共同利用できる製品を作成するということです。 例えば、VPN Operatorは、VPN初公開と管理を実行するのに、どんな従っているPKIベンダーの実装と共にも証明書管理プロフィールのどんな従っているIPsec実装(VPN政権かIPsec Peer)も使用するはずであることができます。
1.1. Scope
1.1. 範囲
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 SystemsとPKI SystemsとVPN政権とIPsec Peersの間のトランザクションに関する要件を扱います。 要件は、大規模な展開(何千人ものすなわち、数百を含むVPNs、管理された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.
ゲートウェイからゲートウェイへのアクセスとエンドユーザ遠隔アクセス(ゲートウェイへの)はともに含まれています。 エンド・ツー・エンド通信は、必ず除かれるというわけではありませんが、故意に、どんなaも集中しないということです。
Only VPN-PKI transactions that ease and enable scalable PKI-enabled IPsec deployments are addressed.
スケーラブルなPKIによって可能にされたIPsec展開を緩和して、可能にするVPN-PKIトランザクションだけが扱われます。
Bonatti, et al. Informational [Page 5] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[5ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
1.2. Non-Goals
1.2. 非目標
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.
PeerトランザクションへのVPN Administratorのためのプロトコル仕様は扱われないでしょう。 これらの相互作用はベンダーであると独占である状態で考えられます。 これらの相互作用は後で異なったベンダーからVPN政権の機能ステーションとIPsec Peersの間の相互運用性を可能にするために標準化されるかもしれません、遠くにこの現在の取り組みの範囲を超えていて、本書では不透明なトランザクションとして記述されるのを除いて。
The protocol specification for Registration Authority - Certificate Authority (RA-CA), CA-Repository, and RA-Repository interactions will not be addressed.
Registration Authorityのためのプロトコル仕様--証明書Authority(RA-カリフォルニア)、カリフォルニア-倉庫、およびRA-倉庫相互作用は扱われないでしょう。
1.3. Definitions
1.3. 定義
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 System VPN SystemはVPN政権とIPsec Peersの間のVPN政権機能(以下では、定義される)、IPsec Peers、およびコミュニケーションメカニズムから成ります。 VPN Systemはさらに詳細にセクション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 System PKI System、または単にPKIがPKCsを認可して、発行して、管理するのが必要である関数群です。 PKI Systemはさらに詳細にセクション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.
Operatorが安全保障政策を定義する人々の人かグループであり、VPN Systemを構成する(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 Peer(ゲートウェイかClient)IPsec Peer、または単に「同輩」というはコミュニケーションのためのIPsec Security Associationを作成するためにIKEとIPsecを別のPeerに伝えるあらゆるVPN Systemの部品です。 それは、伝統的なセキュリティゲートウェイ(2つのネットワーク・インターフェース、保護されたネットワークのためのもの、および保護のないネットワークのためのものがある)かIPsecクライアントのどちらかであるかもしれません(単一のネットワーク・インターフェースがある)。 どちらの場合も、PeerはIPsec保護なしでトラフィックを通過できて、選ばれたトラフィックストリームにIPsec保護を加えることができます。その他の詳細に関してセクション2.1.1を見てください。
Bonatti, et al. Informational [Page 6] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[6ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
(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)アドミン、AdminはVPN接続のためのPKCの食糧を供給することを証明するためにPKI Systemと対話するVPN System機能です。 その他の詳細に関してセクション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).
終わりのEntity An終わりの実体は、PKCで特定される実体か対象です。 終わりの実体はデータにデジタルに署名するのに最終的にPKCに関連している秘密鍵を使用する1つの実体です。 本書では、IPsec Peerは確かに終わりの実体ですが、また、VPN Adminは終わりの実体を構成できます。 終わりの実体が異なる役割(例えば、署名、対主要な交換Admin-機能対Peer-機能)のための異なったPKCsを持つことができることに注意してください。
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 Rekey、同じ対象の名前のための新しい公開鍵がある新しい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 Renewal、既存の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のUpdateのA特別なケース。 例は終わりの実体の結婚によるアドレス、電話番号、または改名における変化を含むかもしれません。 更新処理は、新規加入のための認証を独力で進むために既存の主要な組を当てにすることができます。
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.
登録Authority(RA)は終わりの実体(対象のアイデンティティを確認して、PKCのために対象から公開鍵に関連している秘密鍵の所有物を要求することを確かめるとしてのそのようなもの)の登録で必要な管理業務のいくつかを実行することへのPKI System当然のことの責任で任意の実体です。
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.
Authority(カリフォルニア)の創造する1人以上のユーザによって信じられるPKI Systemの権威とサインPKCsを証明してください。 カリフォルニアは彼らを発行するだけ間責任があるのではなく、彼らの全体の生涯PKCsに責任があることに注意するのが重要です。
Bonatti, et al. Informational [Page 7] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[7ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
Repository An Internet-accessible server in a PKI System that stores and makes available for retrieval PKCs and Certificate Revocation Lists (CRLs).
それが検索PKCsとCertificate Revocation Lists(CRLs)に利用可能に保存して、するPKI Systemの倉庫のAnのインターネットアクセスしやすいサーバ。
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.
終わりの実体によって直接信じられるカリフォルニア/信頼Anchor Aカリフォルニアを根づかせてください。 あって、しっかりとRootカリフォルニア公開鍵の値を取得するのがバンドの外でいくつかを必要とするのが(s)を踏みます。 今期は、Rootカリフォルニアが必ずどんな階層構造の最上部にもあって、単に、問題のカリフォルニアが直接信じられるのを含意することになっていません。
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.
証明書Revocation List(CRL)A CRLは倉庫で取り消されたPKCsを特定して、自由に利用可能にされたカリフォルニアによって署名されて、timestampedされたリストです。 同輩は、IKEトランザクションにおけるアイデンティティとして彼らに提示されるPKCが取り消されていないことを確かめるためにCRLを検索します。
CRL Distribution Point (CDP) The CDP is a PKC extension that identifies the location from which end entities should retrieve CRLs to check status information.
CRL Distribution Point(CDP)CDPは終わりの実体が状態情報をチェックするためにCRLsを検索するべきである位置を特定する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.
権威Info Access(AIA)AIAは拡大が現れるPKCの発行人のためにカリフォルニア情報とサービスにアクセスする方法を示すPKCの拡大です。 情報とサービスはオンライン合法化サービスとCertificate Policy(CP)データを含むかもしれません。
1.4. Requirements Terminology
1.4. 要件用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[MUSTSHOULD]で説明されるように本書では解釈されることであるべきですか?
Bonatti, et al. Informational [Page 8] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[8ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
2. Architecture
2. アーキテクチャ
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 Systemに関する説明は提示されます。 2番目に、PKI Systemに関する要点は述べられています。 3番目に、VPN-PKIアーキテクチャは提示されます。
2.1. VPN System
2.1. VPNシステム
The VPN System consists of the IPsec Peers and the VPN Administration function, as depicted in Figure 1.
VPN Systemは図1に表現されるようにIPsec PeersとVPN政権機能から成ります。
+---------------------------------------------------+
| |
| +----------+ |
| | VPN | |
| +---------->| Admin |<-------+ |
| | | Function | | |
| | +----------+ | |
| v v |
| +---------+ +---------+ |
| | IPsec | | IPsec | |
| | Peer 1 |<=======================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+---------------------------------------------------+
+---------------------------------------------------+ | | | +----------+ | | | VPN| | | +---------->| アドミン| <、-、-、-、-、-、--+ | | | | 機能| | | | | +----------+ | | | vに対して| | +---------+ +---------+ | | | IPsec| | IPsec| | | | 同輩1|<============>| 同輩2| | | +---------+ +---------+ | | | | VPNシステム| +---------------------------------------------------+
Figure 1: VPN System
図1: VPNシステム
2.1.1. IPsec Peer(s)
2.1.1. IPsec同輩(s)
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.
PeersはIPsec Security Associationの設立が必要である2つの実体です。 2Peersが図1で見せられますが、実装は数百か数千における実数をサポートすることができます。 Peersはゲートウェイからゲートウェイであるかもしれません。リモートアクセス両方のゲートウェイかaミックスを主催します。 Peersは、IKE交渉でPKCsと共にPKI Systemから生成されたデジタル署名を使用することで自分たちを認証します。
2.1.2. VPN Administration Function (Admin)
2.1.2. VPN政権機能(アドミン)
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
このドキュメントは、今後Adminと呼ばれたVPN政権機能の概念を定義して、VPN Systemの中でAdmin重荷を与えます。 AdminはIPsec Peersのグループのために、PKI方針(例えば、アルゴリズム、キー長、lifecycleオプション、およびPKC分野)を証明するためにPKI Systemと対話するのにOperatorによって使用された集結された機能です。 Adminも
Bonatti, et al. Informational [Page 9] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[9ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
authorizes PKC issuance and can act as the Peer's PKI System interface, which allows the Admin to perform many RA-like functions.
PeerのPKI System(Adminに多くのRAのような機能を実行させる)が連結するとき、PKCの発行を認可して、行動できます。
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.
Adminがこのドキュメントの中のデバイスでなくてまた人でないことに注意するのは重要です。 むしろ、それは機能です。 あらゆる大規模なVPN展開がAdmin機能を含むでしょう。 スタンドアロンのワークステーション、または、ゲートウェイ、または、管理ソフトウェアコンポーネントに機能を実行できます。 また、Admin機能もゲートウェイ、クライアントデバイス、またはソフトウェアと全く同じである場合があります。 異なった機能として建築ダイヤグラムで表されますが、それらは異なった物理的実体である必要はありません。 そういうものとして、実装によってそれが参加しているIPsec Peersと対話するAdminのアーキテクチャと手段はばらつきが大きいでしょう。 しかしながら、Adminのいくつかの基本機能が想定されます。
- 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 Systemにおける使用のために、Certificate Policy(CP)[FRAME]を定義するでしょう。 PKCの特性とコンテンツはCPの機能です。 VPN Systemsでは、Operatorは、PKIを使用することによってVPNを強化するのを選びます。 PKIがaである、ボルトで留める、VPN System。 OperatorはAdminとその認可されたPKIによって可能にされたPeersを通して一部ローカルの安全保障政策を構成するでしょう。
- 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.
- それは、終わりの実体PKCsのためにあらかじめ同意されたテンプレートに基づくPKCsの個々のPKCsかバッチのためにパラメタとコンテンツを送ることによって承認を開始するために直接PKI Systemと対話するでしょう(すなわち両方のタイプの承認要求はあらかじめ同意されたテンプレートについて言及します)。 バンドで出ているメカニズムでVPN OperatorとPKI Operatorによってテンプレートは同意されるでしょう。 それはPKIからPeersがPKCを要求するのを認可する承認識別子と1回の承認トークンのユニークなtupleを受け返すでしょう。
- 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 Peersに提供するでしょう、そして、Peersはそれらの指示(例えばキーを生成するのに必要なPeer情報とPKCが要求するAdminパス)を行うでしょう。
2.2. PKI System
2.2. PKIシステム
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.
Operator(社内の)が図2に表現されるPKI Systemをセットアップして、操作できますか、第三者PKIプロバイダーで(管理されたPKIサービス)に食糧を供給する時点でどの接続性が利用可能であるか提供するか、またはVPN製品について統合してください。
Bonatti, et al. Informational [Page 10] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[10ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
+---------------------------------------------+
| +-------------------------+ |
| v | |
| +--------------+ v |
| | Repository | +----+ +----+ |
| | Certs & CRLs |<-> | CA |<->| RA | |
| +--------------+ +----+ +----+ |
| |
+---------------------------------------------+
+---------------------------------------------+ | +-------------------------+ | | v| | | +--------------+ v| | | 倉庫| +----+ +----+ | | | 本命とCRLs| <->| カリフォルニア| <->| 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共同体からPKCsを入手すると仮定します。 IPsec PeerはPKI共同体の外でカリフォルニアから来ているPeerからの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 Systemは取り扱いAdminの認可要求とPKCの登録のためのメカニズムを含んでいます。 このメカニズムはRegistration Authority(RA)と呼ばれます。 PKI SystemはPeersが互いのPKCsと取消し情報を検索するRepositoryを含んでいます。 最後に、PKI Systemは公衆と秘密鍵組を使用して、PKCsにサインするカリフォルニアのコア機能を含みます。
2.3. VPN-PKI Interaction
2.3. VPN-PKI相互作用
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 SystemとPKI Systemとの相互作用はこの要件ドキュメントの主要な焦点です、図3に示されるように。 したがって、1PeerのためにPKCsをセットアップして、使用して、管理するのに必要なステップが別のPeerとの協会を設立すると考えるのは分別があります。
Bonatti, et al. Informational [Page 11] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[11ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
+-----------------------------------------------+
| PKI System |
| |
| +--------------+ |
| | Repository | +----+ +----+ |
| | Certs & CRLs | | CA | | RA | |
| +--------------+ +----+ +----+ |
| |
+-----------------------------------------------+
^ ^ ^
|[G] |[A] |[G]
|[E] |[G] |[E]
|[L] |[E] |[L]
|[R] |[R] |[R]
| |[L] |
+-----+------------------+-------------------+-------+
| | v | |
| | +----------+ | |
| | [G][E][L][R]| VPN |[G][E][L][R] | |
| | +---------->| Admin |<----------+ | |
| | | | Function | | | |
| | | +----------+ | | |
| v v v v |
| +---------+ +---------+ |
| | IPsec | [I] | IPsec | |
| | Peer 1 |<========================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+----------------------------------------------------+
+-----------------------------------------------+ | PKIシステム| | | | +--------------+ | | | 倉庫| +----+ +----+ | | | 本命とCRLs| | カリフォルニア| | RA| | | +--------------+ +----+ +----+ | | | +-----------------------------------------------+ ^ ^ ^ |[G]|[A]|[G]|[E]|[G]|[E]|[L]|[E]|[L]|[R]|[R]|[R]| |[L]| +-----+------------------+-------------------+-------+ | | v| | | | +----------+ | | | | [G][E][L][R]| VPN|[G][E][L][R]| | | | +---------->| アドミン| <、-、-、-、-、-、-、-、-、--+ | | | | | | 機能| | | | | | | +----------+ | | | | v対vに| | +---------+ +---------+ | | | IPsec| [I]| IPsec| | | | 同輩1|<============>| 同輩2| | | +---------+ +---------+ | | | | VPNシステム| +----------------------------------------------------+
[A] = Authorization: PKC issuance
[G] = Generation: Public key, private key, and PKC request
[E] = Enrollment: Sending PKC request, verifying PKC response, and
confirming PKC response
[I] = IKE and IPsec communication
[L] = Lifecycle: Rekey, renewal, update, revocation, and confirmation
[R] = Repository: Posting and lookups
[A] =認可: PKC発行[G]=世代: 公開鍵、秘密鍵、およびPKCは、[E]が登録と等しいよう要求します: PKCの要求を送って、PKCの応答について確かめて、PKCの応答[I]を確認するのはIKEと等しいです、そして、IPsecコミュニケーション[L]はLifecycleと等しいです: Rekey、更新、アップデート、取消し、および確認[R]は倉庫と等しいです: 任命とルックアップ
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] 取引のための要件はこのドキュメントの範囲を超えています。 さらに、証明(すなわち、名前に公開鍵を縛る)の行為は、カリフォルニアで実行されて、図に示されません。
Bonatti, et al. Informational [Page 12] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[12ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3. Requirements
3. 要件
3.1. General Requirements
3.1. 一般要件
3.1.1. One Protocol
3.1.1. 1つのプロトコル
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]相互作用のそれぞれの主な要素のためのONE PROTOCOLかONE USE PROFILEを求めなければなりません。 複雑さを減少させて、相互運用性を改良するために、可能であるときはいつも、複数の競争しているプロトコルか同じ要件を解決するプロフィールを持っているのは避けられるべきです。
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.
必要条件のいくつかを満たすと、既存のプロトコルのための新しいプロトコルか新しい拡大の創造は必要とするかもしれません。 しかしながら、後者は非常に好まれます。
3.1.2. Secure Transactions
3.1.2. 安全な取引
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.
目標証明書管理プロフィールは[A]、[E]、[L]、およびVPNとPKI Systemsの間の[R]取引を指定しなければなりません。. これらの取引、Admin、PKI MUST為替政策の詳細、アイデンティティ、およびキーを支えるために。 そういうものとして、プライバシー、認証、およびメッセージデータ保全を確実にする方法で[A]、[E]、および[L]取引のための伝達方法を保証しなければなりません。 通信方式は、信頼関係がPKIとAdminの間で確立されるのを必要としなければなりません(セクション3.7.1を見てください)。 [R] 応答(すなわち、PKCsとCRLs)が既にデジタルにサインされるので、取引は認証かメッセージデータ保全を必要としません。 [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] 取引を指定しないでしょう。 しかしながら、これらの取引が他の取引の基礎であるのでプライバシー、認証、およびメッセージデータ保全を確実にする方法でこれらの取引を保証しなければなりません。
3.1.3. Admin Availability
3.1.3. アドミンの有用性
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
AdminはPeersで届いているに違いありません。 PeersがネットワークかインターネットでどこからでもAdminに接続できるのを確実にすることによって、ほとんどの実現がこの必要条件を満たすでしょう。 しかしながら、AdminとPeersとのコミュニケーションは「オフラインであることができます」。 いくつかの環境で、それは「メディアを動かすことができる」(すなわち、構成かデータが、フロッピーディスクか他のメディアにロードされて、物理的にIPsec Peersに動かされます)。 同様に、User Interface(UI)を通して直接IPsec Peerにそれを入れることができます。 この場合機能が共同見つけられているAdmin
Bonatti, et al. Informational [Page 13] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[13ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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.
Peer装置自体。 ほとんどの要件とシナリオが本書ではVPN Systemの人生のためのAdminのオンライン有用性を仮定します。
3.1.4. PKI Availability
3.1.4. PKIの有用性
Availability is REQUIRED initially for authorization transactions between the PKI and Admin. Further availability is required in most cases, but the extent of this availability is a decision point for the Operator. Most requirements and scenarios in this document assume on-line availability of the PKI for the life of the VPN System.
初めは、有用性はPKIとAdminの間の認可取引のためのREQUIREDです。 さらなる有用性が多くの場合必要ですが、この有用性の範囲はOperatorのための決定ポイントです。 ほとんどの要件とシナリオが本書ではVPN Systemの人生のための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 Systems(すなわち、物理的なメディアは輸送方法としてそこで使用される)とのオフライン相互作用はこのドキュメントの範囲を超えています。
3.1.5. End-User Transparency
3.1.5. エンドユーザ透明
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相互作用はユーザにとって透明であることになっています。 ユーザSHOULD NOT、PKIが使用中であることを意識さえしてください。 初めての接続SHOULDは何らかの識別とパス句のためのプロンプト、およびセットアップが進行しているようにユーザに通知するステータスバーだけから成ります。
3.1.6. PKC Profile for PKI Interaction
3.1.6. PKI相互作用のためのPKCプロフィール
A PKC used for identity in VPN-PKI transactions MUST include all the [CERTPROFILE] mandatory fields. It MUST also contain contents necessary to support path validation and certificate status checking.
VPN-PKI取引におけるアイデンティティに使用されるPKCはすべての[CERTPROFILE]義務的な分野を含めなければなりません。 また、それは経路合法化と証明書状態の照合を支持するのに必要なコンテンツを含まなければなりません。
It is preferable that the PKC profiles for IPsec transactions [IKECERTPROFILE] and VPN-PKI transactions (in the certificate management profile) are the same so that one PKC could be used for both transaction sets. If the profiles are inconsistent, then different PKCs (and perhaps different processing requirements) might be required. However, the authors urge that progress continue on other aspects of this standardization effort regardless of the status of efforts to achieve PKC profile consensus.
IPsec取引[IKECERTPROFILE]とVPN-PKI取引(証明書管理プロフィールの)のためのPKCプロフィールが両方の取引セットに1PKCを使用できるくらい同じであることは、望ましいです。 プロフィールが矛盾しているなら、異なったPKCs(そして、恐らく異なった処理所要)が必要であるかもしれません。 しかしながら、作者は、PKCプロフィールコンセンサスを達成するための努力の状態にかかわらずこの標準化の努力の他の局面で進歩を続けるよう促します。
Bonatti, et al. Informational [Page 14] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[14ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.1.6.1. Identity
3.1.6.1. アイデンティティ
PKCs MUST support identifying (i.e., naming) Peers and Admins. The following name forms MUST be supported:
PKCsは、(すなわち、命名)の同輩とAdminsを特定するのを支持しなければなりません。 以下の名前フォームを支持しなければなりません:
- Fully-Qualified Domain Name (FQDN)
- RFC 822 (also called USER FQDN)
- IPv4 Address
- IPv6 Address
- 完全に適切なDomain Name(FQDN)--RFC822(また、USER FQDNと呼ばれます)--IPv4 Address--IPv6 Address
3.1.6.2. Key Usage
3.1.6.2. 主要な用法
PKCs MUST support indicating the purposes for which the key (i.e., digital signature) can be used. Further, PKCs MUST always indicate that relying parties (i.e., Peers) need to understand the indication.
PKCsは、キー(すなわち、デジタル署名)を使用できる目的を示すのを支持しなければなりません。 さらに、PKCsはいつもパーティー(すなわち、Peers)が指示を理解するために必要とするその信用を示さなければなりません。
3.1.6.3. Extended Key Usage
3.1.6.3. 拡張主要な用法
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.
拡張Key Usage(EKU)指摘は必要ではありません。 EKU MUST NOTの存在か不足が実現がIKE接続に失敗されます。
3.1.6.4. Revocation Information Location
3.1.6.4. 取消し情報位置
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.
PKCsは、何か局所的にPKCを保持するPeerがちょうどどこに行くか、そして、どのようにCRLを要求するかを知るように、CRLの位置を示さなければなりません。
3.1.7. Error Handling
3.1.7. エラー処理
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 System製品の間の相互運用性の努力を大いに支援するでしょう。
3.2. Authorization
3.2. 認可
This section refers to the [A] elements labeled in Figure 3.
このセクションは図3をラベルされた[A]要素を示します。
3.2.1. One Protocol
3.2.1. 1つのプロトコル
One protocol MUST be specified for the Admin to PKI (RA/CA) interactions. This protocol MUST support privacy, authorization, authentication, and integrity. PKCs for authorization of the Admin can be initialized through an out-of-band mechanism.
PKI(RA/カリフォルニア)相互作用へのAdminに1つのプロトコルを指定しなければなりません。 このプロトコルはプライバシー、認可、認証、および保全を支持しなければなりません。 バンドで出ているメカニズムを通してAdminの認可のためのPKCsを初期化できます。
The transport used to carry the authorization SHOULD be reliable (TCP).
輸送は以前はよく認可SHOULDを運びました。信頼できてください(TCP)。
Bonatti, et al. Informational [Page 15] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[15ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
The protocol SHOULD be as lightweight as possible.
SHOULDについて議定書の中で述べてください。できるだけ軽量であってください。
3.2.2. Bulk Authorization
3.2.2. 大量の認可
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のAdmin要求であるときに、大量の認可は起こります。 最低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.
大量認可SHOULDは1つの単独結合でPKI(RA/カリフォルニア)に起こります、1以上である対象の数で。 実現SHOULD、バッチ認可で1,000個の対象を扱うことができてください。
3.2.3 Authorization Scenario
3.2.3 認可シナリオ
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は、認可取引を実行するために顕著な相互作用を示しています。
Bonatti, et al. Informational [Page 16] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[16ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
| 1
2 |
v
+-------+
| Admin |
+-------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+ ^ | 1 2 | +に対して-------+ | アドミン| +-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------------+ +--------+ | IPsec| | IPsec| | 同輩1| | 同輩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 Systemが登録を認可するように、アドミンはアイデンティティと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を見てください。
3.2.4. Authorization Request
3.2.4. 認可要求
3.2.4.1. Specifying Fields within the PKC
3.2.4.1. PKCの中で分野を指定します。
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.
Adminはあらかじめ同意されたテンプレートに基づくPKCの発行の個々のPKCsかバッチを認可します。 このテンプレートは、VPN OperatorとPKI Operatorによって同意されて、それぞれの認可要求で言及されます。 これはVPN Systemを支持するのに必要な最小量の情報量を含んでいるという認可要求を許します。
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."
Adminはそれが、PKIにIPsec Peersのグループに発行して欲しいPKCコンテンツのセットをPKI Systemに送ることができます。 言い換えれば、PKI Systemに言います、「あなたは、この人からこれに似ているPKCの要求を見て、それを処理して、PKCを発行する」なら。
Requirements for PKC fields used in IPsec transactions are specified in [IKECERTPROFILE].
IPsec取引に使用されるPKC分野のための要件は[IKECERTPROFILE]で指定されます。
Bonatti, et al. Informational [Page 17] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[17ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
Requirements for PKC fields used in VPN-PKI transactions are specified in Section 3.1.6.
VPN-PKI取引に使用されるPKC分野のための要件はセクション3.1.6で指定されます。
3.2.4.2. Authorizations for Rekey, Renewal, and Update
3.2.4.2. Rekey、更新、およびアップデートのための承認
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 OperatorとPKI Operatorがテンプレートの上にあらかじめ同意するとき、彼らは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.
- アドミンは、自動更新が許容されているかどうか指定しなければなりません、すなわち、AdminがPKIが指定されたPeer 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アップデートが許されているかどうか指定しなければなりません、すなわち、AdminがPKIが非キー関連の分野への変化で新しいPKCを求める今後の要求を受け入れるのを認可します。
If a PKC renewal is authorized, the Admin MUST further specify:
PKCの更新が認可されているなら、Adminはさらに指定しなければなりません:
- 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.
- 人(そうする)が更新できますか、Adminだけが更新要求を送ることができますか、またはPeerは直接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).
- PKIはPKC有効期限のずっと前に、どう、更新(すなわち、N%の有効期間、または更新が受入れられるUTC時)を受け入れて、処理するだろうか。
If a PKC update is authorized, the Admin MUST further specify:
PKCアップデートが認可されているなら、Adminはさらに指定しなければなりません:
- 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.
- Updateが要求するPKC、すなわち、Adminだけ、Peer、またはどちらかしか送ることができない実体。
- How long before the PKC expiration date the PKI will accept and
process an update (i.e., N% of validity period, or the UTC time
after which update is permitted).
- PKIはPKC有効期限のずっと前に、どう、アップデート(すなわち、N%の有効期間、またはアップデートが受入れられるUTC時)を受け入れて、処理するだろうか。
A new authorization by the Admin is REQUIRED for PKC rekey. No parameters of prior authorizations need be considered.
Adminによる新しい認可はPKC rekeyのためのREQUIREDです。 先の承認のパラメタは全く考えられる必要はありません。
3.2.4.3. Other Authorization Elements
3.2.4.3. 他のAuthorization Elements
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
Adminには、認可IDと1回の認可象徴に形式を指定する能力がなければなりません。 1回の認可象徴SHOULD、認可ID単位でユニークであってください。 認可IDとその1回の認可象徴との関係で達成できる偶発性が多ければ多いほど、より良いです。 避けるUTF-8形式には1回の認可象徴があるに違いありません。
Bonatti, et al. Informational [Page 18] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[18ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
incompatibilities that may occur due to international characters. It MUST support normalization as in [CERTPROFILE]. The Admin MUST have the ability to constrain the UTF-8 character set.
起こるかもしれない両立し難いことは国際的な人物がそうします。 それは[CERTPROFILE]のように正常化を支持しなければなりません。 Adminには、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回の認可象徴に合法化の期間を指定するオプションがあるに違いありません。 そのような合法化の期間が決められるなら、どんなPKCも低下しなければならない合法化の期間の外でPKIに届く認可IDと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.
プロトコルSHOULDは、Admin-求められた情報が要求された通りAdmin要求を出すことができない(例えば、Adminは3週間の合法化の期間=を要求します、そして、カリフォルニアは= 1週間合法化の期間を許容するだけであるために構成される)ようにPKI設定と衝突すると何が起こるかを考えます。 適切な闘争取り扱いを指定しなければなりません。
3.2.4.4. Cancel Capability
3.2.4.4. 能力を取り消してください。
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.
AdminかPeerのどちらかがキャンセル認可メッセージを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タイプは無くなっている接続シナリオをカバーするREQUIREDです)後に、PKIは取り消されたものと全く同じコンテンツで新しい認可要求を受け入れるでしょう、識別子が新しいに違いないのを除いて。 PKI MUST NOTは写し認可要求を処理します。
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を発行したなら認可のキャンセルが可能でないというメモと認可は、SHOULDがPKIによって拒否されるよう要求します。 PKCがいったん発行されると、セクション3.6によると、それを取り消さなければなりません。
3.2.5. Authorization Response
3.2.5. 認可応答
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はユニークな認可識別子が対象の認可単位で要求されているAdminと認可IDあたり1つの1回の認可象徴に応じるでしょう。 セクション3.2を見てください。.4 .3 追加認可IDと1回の認可象徴要件のために。
The PKI can alter parameters of the authorization request submitted by the Admin. In that event, the PKI MUST return all the contents of the authorization request (as modified) to the Admin with the confirmation of authorization success. This will allow the Admin to
PKIはAdminによって提出された認可要求のパラメタを変更できます。 その場合には、PKI MUSTは認可成功の確認で認可要求(変更されるとしての)のすべてのコンテンツをAdminに返します。 これはAdminを許容するでしょう。
Bonatti, et al. Informational [Page 19] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[19ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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.
「操作上のテスト」を実行して、発行されたPKCsが必要条件を満たすことを確かめてください。 Adminが、変更されたパラメタが容認できないことを決定するなら、セクション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.
大量の認可を受けた後に、Admin、PKI MUSTからそれが満たしたそれらの個々のPKC承認に関してはいと返答できてください、いいえよう要求してください。さもないと、それらのためのFAILEDは、それが満足することができないよう要求します、十分な理由かエラーコードと共に。
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設定にあるかを特定するREQUIREDです。
3.2.5.1. Error Handling for Authorization
3.2.5.1. 認可のためのエラー処理
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.
認可の過程における各取引のために徹底的なエラー条件記述と取扱上の注意事項をAdminに提供しなければなりません。 そのようなエラーコードを提供すると、PKIとIPsec製品の間の相互運用性の努力は大いに支援されるでしょう。
3.3. Generation
3.3. 世代
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 Systemが認可識別子と認可象徴で応じて(セクション3.2を見てください)、Adminにこの情報を受け取ると、次のステップは、それらの主要な組を使用することで公衆と秘密鍵組を発生させて、PKCの要求を構成することです。 地方の要件によって、キー生成は3つの場所の1つに起こることができます: IPsecでは、アドミンにおいて、または、PKIをじっと見てください。 PKCの要求はIPsec Peer、Peerの組み合わせ、およびAdminから来ることができますか、とんでもない。
Bonatti, et al. Informational [Page 20] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[20ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.3.1. Generation Method 1: IPsec Peer Generates Key Pair, Constructs
PKC Request, and Signs PKC Request
3.3.1. 世代、方法1: IPsec同輩は、主要な組を発生させて、PKCの要求を構成して、PKCの要求にサインします。
This option will be used most often in the field. This is the most secure method for keying, as the keys are generated on the end entity and the private key never leaves the end entity. However, it is the most computationally intensive for the Peer, as it must be "ASN.1 aware" to support generating and digitally signing the PKC request.
このオプションはたいてい分野で使用されるでしょう。 これは合わせる最も安全な方法です、キーが終わりの実体で発生して、秘密鍵が終わりの実体を決して残さないとき。 しかしながら、Peerには、それは最も計算上徹底的です、PKCの要求を発生して、デジタル、サインするのを支持するのが「ASN.1意識していなければならない」ように。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+
+-------+
+------>| Admin |
| +-------+
|
| 1
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+-------+ +------>| アドミン| | +-------+ | | 1 +に対して--------------------+ +--------+ 2 | IPsec| | IPsec| | 同輩1| | 同輩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の要求を発生させるようにPeerによって必要とされた認可識別子、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でこれらの前のステップを見つけることができます。 次のステップ(登録)はPeerとPKI(セクション3.4.5を見る)の直接間、または、Adminを通して起こることができます(セクション3.4.6を見てください)。
Bonatti, et al. Informational [Page 21] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[21ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.3.2. Generation Method 2: IPsec Peer Generates Key Pair, Admin
Constructs PKC Request, Admin Signs PKC Request
3.3.2. 世代、方法2: アドミン構造物PKCは、IPsec同輩が主要な組を発生させるよう要求して、アドミンはPKCの要求にサインします。
This option also supports IPsec Peer generation of a key pair, but removes the requirement for the Peer to be ASN.1 aware because it does not have to construct or digitally sign the PKC request. The drawback is that the key pair does need to be provided to the Admin. In the most probable cases where the Admin function is remotely located from the peer, this means that the private key will leave the cryptographic boundary of the peer, which is a significant security trade-off consideration. Whenever possible, it is always better to have private keys generated and never leave the cryptographic boundary of the generating system.
このオプションは、また、主要な組のIPsec Peer世代を支持しますが、PKCの要求に構成する必要はありませんし、またデジタル、サインする必要はないので、意識していた状態でPeerがASN.1であるという要件を取り除きます。 欠点は主要な組が、Adminに供給される必要があるということです。 Admin機能が同輩から離れて位置している最も多くの可能性例では、これは、秘密鍵が同輩の暗号の境界を残すことを意味します。(境界は重要なセキュリティトレードオフの考慮です)。 可能であるときはいつも、秘密鍵を発生させて、ゼネレーティングシステムの暗号の限界を決して残さないのはいつもより良いです。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+
3 +-------+
+------>| Admin | 4
| +-------+
|
| 1
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
3 +-------+ +------>| アドミン| 4 | +-------+ | | 1 +に対して--------------------+ +--------+ 2 | IPsec| | IPsec| | 同輩1| | 同輩2| +--------------------+ +--------+
Figure 6. Generation Interactions:
IPsec Peer Generates Key Pair, Admin Constructs PKC Request
図6。 世代相互作用: アドミン構造物PKCは、IPsec同輩が主要な組を発生させるよう要求します。
1) Opaque transaction [G]. Admin sends command to Peer to generate
key pair, based on parameters provided in the command.
1) 取引[G]について不透明にしてください。 アドミンは、コマンドに提供されたパラメタに基づいて主要な組を発生させるようにコマンドをPeerに送ります。
2) Generation [G]. Peer generates key pair.
2) 世代[G]。 同輩は主要な組を発生させます。
3) Opaque transaction [G]. Peer returns key pair to Admin.
3) 取引[G]について不透明にしてください。 同輩は主要な組をAdminに返します。
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でこれらの前のステップを見つけることができます。 次のステップ(登録)はAdminを通して起こります(セクション3.4.7を見てください)。
Bonatti, et al. Informational [Page 22] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[22ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.3.3. Generation Method 3: Admin Generates Key Pair, Constructs PKC
Request, and Signs PKC Request
3.3.3. 世代、方法3: アドミンは、主要な組を発生させて、PKCの要求を構成して、PKCの要求にサインします。
This option exists for deployments where Peers cannot generate their own key pairs. Some examples are for PDAs and handsets where to generate an RSA key would be operationally impossible due to processing and battery constraints. Another case covers key recovery requirements, where the same PKCs are used for other functions in addition to IPsec, and key recovery is required (e.g., local data encryption), therefore key escrow is needed from the Peer. If key escrow is performed then the exact requirements and procedures for it are beyond the scope of this document.
Peersがそれら自身の主要な組を発生させることができないところにこのオプションは展開のために存在しています。 いくつかの例がPDAと受話器のためにRSAキーを発生させるのが処理とバッテリー規制のために操作上不可能であるところにあります。 別のケースはキーリカバリー要件をカバーしています、同じPKCsがIPsecに加えた他の機能に使用されます、そして、キーリカバリーが必要です、そして、(例えば、地方のデータ暗号化)したがって、キーエスクローがPeerから必要です。 キーエスクローが実行されるなら、それのための正確な要件と手順はこのドキュメントの範囲を超えています。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+
+-------+
| Admin | 1
+-------+
+-------+ | アドミン| 1 +-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------------+ +--------+ | IPsec| | IPsec| | 同輩1| | 同輩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でこれらの前のステップを見つけることができます。 次のステップ(登録)はAdminを通して起こります(セクション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
また、Adminがキー生成を実行していますが、別々の承認ステップにはまだ価値があることに注意してください。 PKCテンプレート、Subject分野、SubjectAltName分野、およびその他を要求の一部であり、AdminからPKIへの何らかの方法で伝えなければなりません。 新しいメカニズムを作成することの代わりに、認可図式を再利用できます。 また、これは役割のベースの特徴を考慮します。
Bonatti, et al. Informational [Page 23] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[23ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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.
管理。(Operator1はAdmin機能がPKCsをあらかじめ認可できた唯一無二ですが、そこでは、Operator2はバッチ登録とVPN装置構成をするものです)。
3.3.4. Method 4: PKI Generates Key Pair
3.3.4. 方法4: PKIは主要な組を発生させます。
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.
終わりの実体がそれら自身の主要な組を発生させることができないところにこのオプションは展開のために存在しています、そして、Admin機能は最小限の器具です。 PKIとAdminは、PKIに主要な組とPKCsを発生させるのにあらかじめ同意します。 これは十中八九PKCsを配備する最も簡単な方法です、カリフォルニアとAdminの両方が秘密鍵に近づく手段を持っているので、何らかのセキュリティを犠牲にしますが。 しかしながら、キーエスクローが必要である場合では、これは許容できるかもしれません。 事実上、AdminはPeerのプロキシとしてPKC登録の過程で務めます。
+--------------+ +-----------------------+
| Repository | | CA/RA | 1
+--------------+ +-----------------------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| 1 +--------------+ +-----------------------+
+-------+
| Admin |
+-------+
+-------+ | アドミン| +-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------------+ +--------+ | IPsec| | IPsec| | 同輩1| | 同輩2| +--------------------+ +--------+
Figure 8. Generation Interactions:
IPsec Peer Generates Key Pair, Admin Constructs PKC Request
エイト環。 世代相互作用: アドミン構造物PKCは、IPsec同輩が主要な組を発生させるよう要求します。
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でこれらの前のステップを見つけることができます。 次のステップ(登録)はAdminを通して起こります(セクション3.4.9を見てください)。
Bonatti, et al. Informational [Page 24] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[24ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.3.5. Error Handling for Generation
3.3.5. 世代のためのエラー処理
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の要求を発生させたかにかかわらずエラー条件をAdminに伝えなければなりません。
3.4. Enrollment
3.4. 登録
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.
登録がPeerからPKIまでAdminからPKIまで起こるかどうかにかかわらずプロトコルはまさに同じでなければなりません。
3.4.1. One Protocol
3.4.1. 1つのプロトコル
One protocol MUST be specified for enrollment requests, responses, and confirmations.
登録要求、応答、および確認に1つのプロトコルを指定しなければなりません。
3.4.2. On-line Protocol
3.4.2. オンラインプロトコル
The protocol MUST support enrollment that occurs over the Internet and without the need for manual intervention.
プロトコルはインターネットの上と、そして、手動の介入の必要性なしで起こる登録を支持しなければなりません。
3.4.3. Single Connection with Immediate Response
3.4.3. 即時型反応がある単独結合
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).
登録要求と応答が1に起こることができなければならない、オンである、Peerを代表したAdminかPeer自身とPKI(RA/カリフォルニア)との接続を裏打ちしてください。
3.4.4. Manual Approval Option
3.4.4. 手動の承認のオプション
Manual approval of PKC enrollments is too time consuming for large scale implementations, and is therefore not required.
PKCの登録の手動の承認は、大規模実現において時間がかかり過ぎて、したがって、必要ではありません。
Bonatti, et al. Informational [Page 25] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[25ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.4.5. Enrollment Method 1: Peer Enrolls to PKI Directly
3.4.5. 登録方法1: 同輩は直接PKIに登録します。
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 PeerはAdminでそうすると命令された後に、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 Systemsには、安全なIPsecのために十分な力の公衆と秘密鍵組を発生させることができるくらいのCPUパワーがあります。 この場合、終わりの実体は、それにはそのような主要な組があるとPKIに立証する必要があります。 通常、これが、一回だけ(終わりの実体は、終わりの実体の公開鍵に伴うAdminにサインして、返す)を終わりの実体に送りながら、PKIによって行われます。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
1,3 |
|
|
| +-------+
| | Admin |
| +-------+
|
2,4 |
v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+ ^ 1,3 | | | | +-------+ | | アドミン| | +-------+ | 2,4 | +に対して--------------------+ +--------+ | IPsec| | IPsec| | 同輩1| | 同輩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 Peerは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]。 発生した新しいPKCか適当な誤り表示のどちらかを提供して、PKIは登録要求に応じます。
3) Enrollment Confirmation [E]. Peer positively acknowledges receipt
of new PKC back to the Admin.
3) 登録確認[E]。 同輩は明確に新しいPKCの領収書をAdminに受け取ったことを知らせて戻します。
Bonatti, et al. Informational [Page 26] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[26ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
4) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Peer.
4) 登録確認領収書[E]。 PKIは登録確認領収書をPeerに送り返します。
3.4.6 Enrollment Method 2a: Peer Enrolls through Admin
3.4.6 登録方法2a: 同輩はアドミンを通して登録します。
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 Peerは主要な組とPKCの要求を発生させましたが、直接PKI Systemに登録しません。 代わりに、自動的に要求をAdminに送ります、そして、AdminはPKI Systemに登録を向け直します。 PKI Systemは、それが有効な登録である限り、登録がどこから来るかを気にかけません。 AdminがいったんPKCの応答を受けると、それは自動的にそれをIPsec Peerに送ります。
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 Systemsには、安全なIPsecのために十分な力の公衆と秘密鍵組を発生させることができるくらいのCPUパワーがあります。 この場合、終わりの実体は、それにはそのような主要な組があるとAdminに立証する必要があります。 通常、これが、一回だけ(終わりの実体は、終わりの実体の公開鍵に伴うAdminにサインして、返す)を終わりの実体に送りながら、Adminによって行われます。
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 |
+--------------------+ +--------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+ ^ 2,6 | | v3、7 1、5+-------+ + >。| アドミン| | +-------+ | | 4、8対+--------------------+ +--------+ | IPsec| | IPsec| | 同輩1| | 同輩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 PeerはAdminからPKCを要求します。
Bonatti, et al. Informational [Page 27] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[27ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
2) Enrollment Request [E]. The Admin forwards the enrollment request
to the PKI.
2) 登録要求[E]。 Adminは登録要求を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]。 発生した新しいPKCか適当な誤り表示のどちらかを提供して、PKIは登録要求に応じます。
4) Opaque Transaction [E]. The Admin forwards the enrollment
response back to the IPsec Peer.
4) 取引[E]について不透明にしてください。 AdminはIPsec Peerへの登録応答を進めます。
5) Opaque Transaction [E]. Peer positively acknowledges receipt of
new PKC back to the Admin.
5) 取引[E]について不透明にしてください。 同輩は明確に新しいPKCの領収書をAdminに受け取ったことを知らせて戻します。
6) Enrollment Confirmation [E]. Admin forwards enrollment
confirmation back to the PKI.
6) 登録確認[E]。 アドミンは登録確認をPKIに送って戻します。
7) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Admin.
7) 登録確認領収書[E]。 PKIは登録確認領収書をAdminに送り返します。
8) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the Peer.
8) 取引[E]について不透明にしてください。 アドミンはPKIの登録確認領収書をPeerに転送して戻します。
3.4.7. Enrollment Method 2b: Peer Enrolls through Admin
3.4.7. 登録方法2b: 同輩はアドミンを通して登録します。
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 Peerが主要な組を発生させましたが、PKCの要求は、Adminによって構成されて、サインされます。 PKI Systemは、それが有効な登録である限り、登録がどこから来るかを気にかけません。 一度、AdminはPKCを検索して、次に、それは自動的に主要な組に伴うIPsec Peerにそれを送ります。
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 Systemsには、安全なIPsecのために十分な力の公衆と秘密鍵組を発生させることができるくらいのCPUパワーがありません。 この場合、Adminは、それにはそのような主要な組があるとPKIに立証する必要があります。 通常、これが、一回だけ(Adminは終わりの実体の公開鍵に伴うPKIにサインして、返す)をAdminに送りながら、PKIによって行われます。 本件への欠点が結局ワイヤの上に秘密鍵を送るということである、(希望をいだいて、しっかりと、そう) AdminからIPsec Peerまで。 可能であるときはいつも、起源の暗号の境界の中にキーを保つのが好ましいです。 そうしないのはかがれて、明察される秘密鍵のリスクにシステムを開けます。
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)ステップは示されません。
Bonatti, et al. Informational [Page 28] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[28ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+ ^ 1,5 | | v2、6 4+-------+ +->| アドミン| | +-------+ | | 3、7対+--------------------+ +--------+ | IPsec| | IPsec| | 同輩1| | 同輩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]。 発生している公開鍵を提供して、Adminは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]。 発生した新しいPKCか適当な誤り表示のどちらかを提供して、PKIは登録要求に応じます。
3) Opaque Transaction [E]. The Admin forwards the enrollment
response back to the IPsec Peer.
3) 取引[E]について不透明にしてください。 AdminはIPsec Peerへの登録応答を進めます。
4) Opaque Transaction [E]. Peer positively acknowledges receipt of
new PKC back to the Admin.
4) 取引[E]について不透明にしてください。 同輩は明確に新しいPKCの領収書をAdminに受け取ったことを知らせて戻します。
5) Enrollment Confirmation [E]. Admin forwards enrollment
confirmation back to the PKI.
5) 登録確認[E]。 アドミンは登録確認をPKIに送って戻します。
6) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Admin.
6) 登録確認領収書[E]。 PKIは登録確認領収書をAdminに送り返します。
7) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the Peer.
7) 取引[E]について不透明にしてください。 アドミンはPKIの登録確認領収書をPeerに転送して戻します。
Bonatti, et al. Informational [Page 29] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[29ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.4.8. Enrollment Method 3a: Admin Authorizes and Enrolls Directly to
PKI
3.4.8. 登録方法3a: アドミンは、直接PKIに認可して、登録します。
In this case, the Admin generates the key pair, PKC request, and digitally signs the PKC request. The PKI System does not care where the enrollment comes from, as long as it is a valid enrollment. Once the Admin retrieves the PKC, it then automatically forwards it to the IPsec Peer along with the key pair.
この場合、Adminが主要な組を発生させて、PKCは、PKCの要求を要求して、デジタル、サインします。 PKI Systemは、それが有効な登録である限り、登録がどこから来るかを気にかけません。 一度、AdminはPKCを検索して、次に、それは自動的に主要な組に伴うIPsec Peerにそれを送ります。
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 Systemsには、安全なIPsecのために十分な力の公衆と秘密鍵組を発生させることができるくらいのCPUパワーがありません。 この場合、Adminは、それにはそのような主要な組があるとPKIに立証する必要があります。 通常、これが、一回だけ(Adminは終わりの実体の公開鍵に伴うPKIにサインして、返す)をAdminに送りながら、PKIによって行われます。 本件への欠点が結局ワイヤの上に秘密鍵を送るということである、(希望をいだいて、しっかりと、そう) AdminからIPsec Peerまで。 可能であるときはいつも、起源の暗号の境界の中にキーを保つのが好ましいです。 そうしないのはかがれて、明察される秘密鍵のリスクにシステムを開けます。
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 |
+--------------------+ +--------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+ ^ 1,5 | | v2、6 4+-------+ +->| アドミン| | +-------+ | | 3、7対+--------------------+ +--------+ | IPsec| | IPsec| | 同輩1| | 同輩2| +--------------------+ +--------+
Figure 12. VPN-PKI Interaction Steps:
Admin Generates Keys and PKC Request, and Enrolls Directly
with PKI
図12。 以下のVPN-PKI相互作用ステップ: アドミンは、キーとPKCの要求を発生させて、直接PKIと共に登録されます。
Bonatti, et al. Informational [Page 30] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[30ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
1) Enrollment Request [E]. The Admin requests a PKC from the PKI,
providing the generated public key.
1) 登録要求[E]。 発生している公開鍵を提供して、Adminは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]。 発生した新しいPKCか適当な誤り表示のどちらかを提供して、PKIは登録要求に応じます。
3) Opaque Transaction [E]. The Admin forwards the enrollment
response back to the IPsec Peer, along with the keys.
3) 取引[E]について不透明にしてください。 Adminはキーに伴うIPsec Peerへの登録応答を進めます。
4) Opaque Transaction [E]. Peer positively acknowledges receipt of
new PKC back to the Admin.
4) 取引[E]について不透明にしてください。 同輩は明確に新しいPKCの領収書をAdminに受け取ったことを知らせて戻します。
5) Enrollment Confirmation [E]. Admin forwards enrollment
confirmation back to the PKI.
5) 登録確認[E]。 アドミンは登録確認をPKIに送って戻します。
6) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Admin.
6) 登録確認領収書[E]。 PKIは登録確認領収書をAdminに送り返します。
7) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the Peer.
7) 取引[E]について不透明にしてください。 アドミンはPKIの登録確認領収書をPeerに転送して戻します。
3.4.9. Enrollment Method 3b: Admin Requests and PKI Generates and
Sends PKC
3.4.9. 登録方法3b: アドミン要求とPKIはPKCを発生して、送ります。
In this instance, the PKI and Admin have previously agreed to have the PKI generate keys and certificates when the PKI receives an authorization request. The PKI returns to the IPsec Peer through the Admin, the final product of a key pair and PKC. Again, the mechanism for the Peer to Admin communication is opaque.
この場合、PKIとAdminは、以前に、PKIが認可要求を受け取るとき、PKIにキーと証明書を作らせるのに同意しました。 PKIはAdmin、主要な組とPKCの完成品を通してIPsec Peerに戻ります。 一方、AdminコミュニケーションへのPeerのためのメカニズムは不明瞭です。
A drawback to this case is that the private key will eventually be sent over the wire (though hopefully securely so) from Admin to the IPsec Peer; whenever possible, it is preferred to keep a key within its cryptographic boundary of origin. Failing to do so opens the system to risk of the private keys being sniffed and discerned.
本件への欠点が結局ワイヤの上に秘密鍵を送るということである、(希望をいだいて、しっかりと、そう) AdminからIPsec Peerまで。 可能であるときはいつも、起源の暗号の境界の中にキーを保つのが好ましいです。 そうしないのはかがれて、明察される秘密鍵のリスクにシステムを開けます。
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)ステップは示されません。
Bonatti, et al. Informational [Page 31] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[31ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 4
|
|
v 1,5
3 +-------+
+->| Admin |
| +-------+
|
|
2,6 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
+--------------+ +-----------------------+ | 倉庫| | カリフォルニア/RA| +--------------+ +-----------------------+ ^ 4 | | v1、5 3+-------+ +->| アドミン| | +-------+ | | 2、6対+--------------------+ +--------+ | IPsec| | IPsec| | 同輩1| | 同輩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]について不透明にしてください。 Adminはキーに伴うIPsec Peerへの登録応答を進めます。
3) Opaque Transaction [E]. Peer positively acknowledge receipt of
new PKC back to the Admin.
3) 取引[E]について不透明にしてください。 同輩は明確に新しいPKCの領収書をAdminに受け取ったことを知らせて戻します。
4) Enrollment Confirmation [E]. Admin forwards enrollment
confirmation back to the PKI.
4) 登録確認[E]。 アドミンは登録確認をPKIに送って戻します。
5) Enrollment Confirmation Receipt [E]. PKI sends enrollment
confirmation receipt back to the Admin.
5) 登録確認領収書[E]。 PKIは登録確認領収書をAdminに送り返します。
6) Opaque Transaction [E]. Admin forwards PKI's enrollment
confirmation receipt back to the Peer.
6) 取引[E]について不透明にしてください。 アドミンはPKIの登録確認領収書をPeerに転送して戻します。
3.4.10. Confirmation Handshake
3.4.10. 確認握手
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によって発行されて、PeerかAdminによるPKIをPKC領収書の確認に送り返さなければなりません(Peerの確認を進めて)。
Bonatti, et al. Informational [Page 32] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[32ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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:
操作上、Peerは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
- そしてPeerが有効にそのPKCが使用できるまでPKIが他のもののために倉庫で新しいPKCを発行しない。
- A revocation may be invoked if the PKC is not received and
operational within an allowable window of time.
- PKCが時間の許容できる窓の中で受け取られていて操作上でないなら、取消しは呼び出されるかもしれません。
To assert such proof, the Peer MUST sign a portion of data with the new key. The result MUST be sent to the PKI. The entity that actually sends the result to the PKI MAY be either the Peer (sending it directly to the PKI) or Admin (the Peer would send it to Admin, and Admin can, in turn, send it to the PKI).
そのような証拠について断言するために、Peerは新しいキーでデータの部分に署名しなければなりません。 結果をPKIに送らなければなりません。 どちらかがPeer(直接PKIにそれを送って)であったなら実際に結果をPKI MAYに送る実体かAdmin(PeerはそれをAdminに送るでしょう、そして、Adminは順番にそれを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.
Adminは確認のうまくいっている領収書を受け取ったことを知らせなければなりません、その結果、IKE接続にこのPKCを使用することでそれが続かせるかもしれないPeerに合図します。 PKI MUSTは確認承認を送る前に新しいPKC(例えば、倉庫へのPKCに書く)のPeerの操作上の使用を可能にするのに必要なすべての処理を終了します。 Peerは、PKIの確認承認を受けるまでPKCを使用し始めてはいけません。
3.4.11. Error Handling for Enrollment
3.4.11. 登録のためのエラー処理
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.
徹底的なエラー条件記述と取扱上の注意事項は登録の過程における各取引のためのREQUIREDです。 そのようなエラーコードを提供すると、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.
- アドミンかPeerが要求を送ることができません。
- Admin or Peer sent the request, but the PKI did not receive the
request.
- アドミンかPeerが要求を送りましたが、PKIは要求を受け取りませんでした。
- PKI received the request, but could not read it effectively.
- PKIは要求を受け取りましたが、有効にそれを読むことができませんでした。
- PKI received and read the request, but some contents of the
request violated the PKI's configured policy such that the PKI
was unable to generate the PKC.
- PKIが要求を受け取って、読みましたが、要求の何らかのコンテンツがPKIの構成された方針に違反したので、PKIはPKCを発生させることができません。
- The PKI System generated the PKC, but could not send it.
- PKI SystemはPKCを発生させましたが、それを送ることができませんでした。
Bonatti, et al. Informational [Page 33] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[33ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
- The PKI sent the PKC, but the requestor (Admin or Peer) did not
receive it.
- PKIはPKCを送りましたが、要請者(アドミンかPeer)はそれを受けませんでした。
- The Requestor (Admin or Peer) received the PKC, but could not
process it due to incorrect contents, or other PKC-construction-
related problem.
- 不正確なコンテンツ、または他のPKC-工事に関連する問題のためそれを処理できなかったのを除いて、Requestor(アドミンかPeer)はPKCを受けました。
- The Requestor failed trying to generate the confirmation.
- Requestorは、確認を発生させるようにトライに失敗しました。
- The Requestor failed trying to send the confirmation.
- Requestorは、確認を送るためにトライに失敗しました。
- The Requestor sent the confirmation, but the PKI did not receive
it.
- Requestorは確認を送りましたが、PKIはそれを受けませんでした。
- The PKI received the confirmation but could not process it.
- PKIは確認を受け取りましたが、それを処理できませんでした。
In each case the following questions MUST be addressed:
その都度以下の質問を記述しなければなりません:
- What does Peer do?
- What does Admin do?
- What does PKI do?
- Is Authorization used?
- Peerは何をしますか? - Adminは何をしますか? - PKIは何をしますか? - Authorizationは使用されますか?
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を送った後とPeerがそれを受ける前に失敗が起こるなら、Peerは同じ認可IDと1回の認可による再要求象徴がそうしなければなりません。 認可IDと認可象徴を見て、PKIは再びPKCを送らなければなりません。
Enrollment errors MUST be sent to the Admin regardless of the entity that generated the enrollment request.
登録要求を発生させた実体にかかわらず登録誤りをAdminに送らなければなりません。
3.5. Lifecycle
3.5. Lifecycle
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が終わりの実体PeerのためにいったんPKCを発行すると、Peerは直接かどんなその後の「再-キー」のためのAdminを通したPKI(更新)がアップデートする接触か取消しのどちらかにできるに違いありません。 PKI MUSTは更新、アップデート、および取消しのためにどちらのケースも支えます。 Rekeysは開始されたAdminです。 したがって、Peerは「再-キー」を開始しました。Adminを通して移さなければなりません。
3.5.1. One Protocol
3.5.1. 1つのプロトコル
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つのプロトコルが、rekeyに指定されて、更新して、要求、応答、および確認をアップデートしなければなりません。 それはセクション3.4で指定される同じプロトコルであるに違いありません。
Bonatti, et al. Informational [Page 34] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[34ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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と同じプロトコルを使用して、更新して、操作をアップデートするかもしれません。 また、取消し要求はメール、電話、Instant Messagingなどで現れるかもしれません。
3.5.2. PKC Rekeys, Renewals, and Updates
3.5.2. PKC Rekeys、更新、およびアップデート
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が期限が切れる前にPKC rekeyは同じSubjectNameとSubjectAltNameコンテンツのために終わりの実体のPKCを新しい公開鍵を持っている新しいPKCに取り替えます。
- A PKC renewal replaces an end entity's PKC with the same public
key for the same SubjectName and SubjectAlternativeName contents
as an existing PKC before that PKC expires.
- そのPKCが期限が切れる前にPKCの更新は同じSubjectNameとSubjectAlternativeNameコンテンツのために既存の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の満了の前に変えられたSubjectNameかSubjectAlternativeNameのために同じ公開鍵で新しいPKCの発行と定義されます。
When sending rekey, renew, or update requests, the entire contents of the PKC request needs to be sent to the PKI, not just the changed elements.
rekeyを送るときには更新するか、または要求(変えられた要素だけではなく、PKIに送られるべきPKC要求の必要性の全体のコンテンツ)をアップデートしてください。
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して、更新して、古い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.
新しいキーがaの新しいPKCに使用されるか否かに関係なく、更新してくださいか、アップデートシナリオをローカルの安全保障政策の問題であり、Adminはオリジナルの認可要求におけるPKIに指定しなければなりません。 同じキーを再利用するのは、受入れられますが、奨励されません。 更新してください。または、新しいキーはaであるなら使用されています、アップデート、両方の古いキーで要求にサインしなければなりません--要求(新しいキー)をする権利が新しい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.
rekeyから生じる新しさ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.
rekeyの後の時間の持続時間のために、更新するか、またはアップデートを処理してあります、そして、PKIがPeerの新しいPKCのうまくいっている領収書の確認を受け取る前に終わりの実体のための両方のPKCs(古くて新しい)は有効になるでしょう。 これで、rekey、更新、または更新処理が現れている間、Peerは前のPKCとのとぎれないIKE接続を続行できるでしょう。
Bonatti, et al. Informational [Page 35] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[35ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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.
rekey、更新、またはアップデートが現れた後に、質問は現在、古いPKCに関してするべきことに関するPKIのために存在します。 古いPKCを使用不可能にするつもりであると、PKIは、倉庫から取り除かれた取消しリストにそれを追加する必要があるでしょう。 しかしながら、古いPKCを使用したすべての接続がいったん呼吸が絶えると、これは起こるだけであるべきです。 老人であるならPKCを使用不可能にするべきです。決定、ローカルの方針でほとんど決定します。 PKIかAdminのどちらかが認可段階の間、このパラメタを指定しなければなりません。 また、この場合、PKIかAdminがPKIがいつまでの古いPKCがされる終わりの実体Peerの確認(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.
新しいキーがaのために発生した場合では、要求を更新するか、またはアップデートしてください。そうすれば、古い主要な組ができるだけ早く滅ぼされるのは、PeerがPKIから確認承認をいったん受けたあとに、rekey要求のための、良い習慣です。 古いPKCを使用したすべての接続がいったん呼吸が絶えると、削除は起こることができます。
If a PKC has been revoked, it MUST NOT be allowed a rekey, renewal, or update.
PKCが取り消されたなら、rekey、更新、またはアップデートをそれに許してはいけません。
Should the PKC expire without rekey, renewal, or update, an entirely new request MUST be made.
PKCがrekeyも、更新も、またはアップデートなしで期限が切れるなら、完全に新しい要求をしなければなりません。
3.5.2.1. Rekey Request
3.5.2.1. Rekey要求
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.
アドミンは、新しいキーでPeersによるVPNのとぎれない使用を確実にするために「再-キー」を管理します。 Adminが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.
セクション3.2、3.3、および3.4からオリジナルのPKCの登録に使用される同じシナリオを使用するとき、rekeyのためのシナリオは省略されます。
3.5.2.2. Renew Request
3.5.2.2. 要求を更新してください。
Admins manage renewals to ensure uninterrupted use of the VPN by Peers with the same key pair.
アドミンは、同じ主要な組と共にPeersによる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:
認可時点で、更新承認に関する、ある詳細はAdminによってPKIに伝えられるでしょう、セクション3.2.4で.2に述べられているように 更新要求は以下のためにオリジナルの認可で指定された状態に合わなければなりません。
- 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.
- キー: 新しい、存在、またはどちらか。 - 要請者: 実体Peer、Admin、またはどちらかを終わらせてください。 - 以上: どれくらい早さ、PKC満期の前に。 - 時間: 古いPKCを使用不可能にする前の時間の長さ。
Bonatti, et al. Informational [Page 36] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[36ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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の登録に使用される同じシナリオを使用するとき、更新のためのシナリオは省略されます。
3.5.2.3. Update Request
3.5.2.3. 更新要求
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.
終わりの実体Peerのアイデンティティに関する詳細が変化するとき、PKCのコンテンツへのアップデートは必要になるでしょうが、Operatorは最初から新しいPKCを発生させたがっていません、真新しい認可を必要として。 例えば、ゲートウェイ装置は1つのサイトから別のものに移されるかもしれません。 IPv4 AddressはSubjectAltName拡張子で変化するでしょうが、他のすべての情報が同じ状態で残ることができました。 別の例は結婚して、姓を変えるか、または1つの部から別の部まで移るエンドユーザです。 どちらの場合ではも、1つの分野(DNのSurnameかOrganizational Unit(OU))だけが変化しなければなりません。
An update differs from a rekey or a renewal in a few ways:
アップデートはいくつかの方法でrekeyか更新と異なっています:
- 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:
認可時点で、Adminはアップデート承認に関する、ある詳細をPKIに伝えることができます、セクション3.2.4で.2に述べられているように 更新要求は以下のためにオリジナルの認可で指定された状態に合わなければなりません。
- Keys: new, existing, or either.
- Requestor: End entity Peer, Admin, or either.
- The fields in the Subject and SubjectAltName that are changeable.
- Time: Length of time before making the old PKC unusable.
- キー: 新しい、存在、またはどちらか。 - 要請者: 実体Peer、Admin、またはどちらかを終わらせてください。 - 変わりやすいSubjectとSubjectAltNameの分野。 - 時間: 古いPKCを使用不可能にする前の時間の長さ。
If any of these conditions are not met, the PKI MUST reject the update and log the event.
これらの状態のいずれも満たされないなら、PKI MUSTはアップデートを拒絶して、出来事を登録します。
If an update authorization was not made at the time of original authorization, one can be made from Admin to the PKI at any time during the PKC's valid life. When such an update is desired, Admin
オリジナルの認可時点でアップデート認可をしなかったなら、いつでも、PKCの有効な人生の間、AdminからPKIまで1つを作ることができます。 Admin、そのようなアップデートが望まれているとき
Bonatti, et al. Informational [Page 37] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[37ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
must notify the PKI System that an update is authorized for the end entity and must specify the new contents. Admin then initiates the update request with the given contents in whichever mechanism the VPN System employs (direct from end entity to PKI, from end entity through Admin, or directly from Admin).
アップデートが終わりの実体のために認可されるようにPKI Systemに通知しなければならなくて、新しいコンテンツを指定しなければなりません。 そして、与えられたコンテンツがVPN Systemが使う(Adminを通した終わりの実体か、直接Adminから終わりの実体からPKIまでダイレクトな)メカニズムにある状態で、アドミンは更新要求を開始します。
Scenarios for update are omitted as they use the same scenarios used in the original PKC enrollment from Sections 3.2, 3.3, and 3.4.
セクション3.2、3.3、および3.4からオリジナルのPKCの登録に使用される同じシナリオを使用するとき、アップデートのためのシナリオは省略されます。
3.5.2.4. Error Handling for Rekey, Renewal, and Update
3.5.2.4. Rekey、更新、およびアップデートのためのエラー処理
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製品の間の相互運用性の努力は大いに支援されるでしょう。
3.5.2.5. Confirmation Handshakes
3.5.2.5. 確認握手
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.
Administrative方針によって、また、確認応答を送る前にPKI MUSTがオリジナルのPKCで取消しを発行するのを除いて、確認握手要件はセクション3.2、3.3、および3.4と同じです。
3.5.3. Revocation
3.5.3. 取消し
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.
Peerはそれ自身のPKCのために取消しを開始できなければなりません。 この場合、Peerの現在の主要な組はそれが取り消したがっているPKCのために取消し要求にサインしなければなりません。 実際の取消し要求取引を直接PKIと共に起こるか、または最初にAdminに送る、(だれ、プロキシかフォワード、PKIへの要求) 実現がaの件がありますか?
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).
Adminはそれが制御するテンプレートの下で発行されたどんなPKCのためにも取消しを開始できなければなりません。 Adminはそれ自身のPKCの使用でPKIにそれ自体を特定するでしょう。 それはそれ自身のPKCから秘密鍵をPKIへのどんな取消し要求とも契約しなければなりません。 PKI MUSTには、PKCによって特定されるように取消し権威でAdmin(s)を構成する能力があります。 何かPKC承認が、前述のPKCがAdminによって取り消されるかもしれないかどうか指定しなければならない、(セクション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つのプロトコルを特定しなければならない、さもなければ、PeerとAdminの両方に使用されるべきプロトコルの中の取引は取消しを開始しました。
The profile MUST identify the size of CRL the client will be prepared to support.
プロフィールはクライアントが支持する用意ができているCRLのサイズを特定しなければなりません。
Bonatti, et al. Informational [Page 38] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[38ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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 MUST、aの間のPKCの取消しが取引を更新するので、責任があってください。 PKI MUSTが受信した後にPKCを取り消す、Peerと、ackをPeerに確認させる前に、通知を確認してください。 Peerはこの場合それ自身の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 MUST、アップデート取引の間、PKCの取消しに責任があってください。 PKI MUSTが受信した後にPKCを取り消す、Peerと、ackをPeerに確認させる前に、通知を確認してください。 Peerはこの場合それ自身のPKCを取り消してはいけません。
3.6. Repositories
3.6. 倉庫
This section refers to the [R] elements labeled in Figure 3.
このセクションは図3をラベルされた[R]要素を示します。
3.6.1. Lookups
3.6.1. ルックアップ
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 System SHOULD、ルックアップが直接と完全にCDPかAIAで示されたURLで決議するそうは建てられてください。 PKI SHOULDはそのような紹介ルックアップがIKE交渉を終了する時間を増加させるのに従ってURL内容が紹介を含んでいないようなものが他のホストかURLに建てられて、タイムアウトに実現を引き起こす場合があります。
CDP MUST be flagged as required in the authorization request. The method MUST also be specified: the HTTP method MUST be method; the Lightweight Directory Access Protocol (LDAP) method MAY be supported.
CDP MUST、必要に応じて認可要求で旗を揚げられてください。 また、方法を指定しなければなりません: HTTP方法は方法であるに違いありません。 ライトウェイト・ディレクトリ・アクセス・プロトコル(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取引の間に送られたPKCsで適切にこれらの検索を実行する情報を伝えなければなりません。
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".
すべてのPKCsがただ一つのプロトコルを通して回収可能であるに違いありません。 最終的な仕様は、1つのプロトコルが“MUST"であると認識して、他のものは「任意である」として記載されているかもしれません。
The general requirements for the retrieval protocol include:
検索プロトコルのための一般的な要件は:
- The protocol can be easily firewalled (including Network Address
Translation (NAT) or Port Address Translation (PAT)).
- 容易にプロトコルをfirewalledされることができます(Network Address Translation(NAT)かPort Address Translation(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要素の上のリモート倉庫に対して何らかの質問を実行できます。
Bonatti, et al. Informational [Page 39] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[39ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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.
中間的PKCsがカリフォルニアを再の合わせるのに関するケース、または複数のCAsが存在するPKI Systemに必要でしょう。
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).
見てください。PKCsにはIPsecのために適切なPKCを特定するのを助けるextendedKeyusageがあるかもしれません、デフォルトの振舞いが彼らを使用しないことですが(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 Peersは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 Peersは、Phase1をセットアップしながら潜在を下げるためにPKCsをキャッシュするはずです。 これが相互運用性問題ではなく、操作上の問題であることに注意してください。
The use case for accomplishing lookups when PKCs are not sent in IKE is a stated non-goal of the profile at this time.
このとき、ルックアップいつPKCsを達成するかためのケースがIKEで送られない使用はプロフィールの述べられた非目標です。
3.6.2. Error Handling for Repository Lookups
3.6.2. 倉庫ルックアップのためのエラー処理
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製品の間の相互運用性の努力は大いに支援されるでしょう。
3.7. Trust
3.7. 信用
3.7.1. Trust Anchor PKC Acquisition
3.7.1. 信用アンカーPKCの獲得
The root PKC MUST arrive on the Peer via one of two methods:
根のPKCは2つの方法の1つを通してPeerで到着しなければなりません:
(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) 同輩はAdminとの安全なコミュニケーションで根のPKCを得ることができます。 これは、PeerがPKIとの相互作用に関してそれほど知らないのを必要とします。
(b) Admin can command Peer to retrieve the root cert directly from
the PKI. How retrieval of the root cert takes place is beyond
the scope of this document, but is assumed to occur via an
unauthenticated but confidential enrollment protocol.
(b) アドミンは、Peerが直接PKIから根の本命を救済すると命令することができます。 根の本命の検索がどう行われるかは、このドキュメントの範囲を超えていますが、非認証されましたが、秘密の登録プロトコルで起こると思われます。
Bonatti, et al. Informational [Page 40] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[40ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
3.7.2. Certification Path Validation
3.7.2. 証明経路合法化
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 PeerはPKCの分野に基づくアイデンティティ検証とVPN Security Associationに適切なパラメタを実行しなければなりません。 検証に使用されるPKCの分野はSubject Nameの中のX.500 Distinguished Name(DN)かExtension SubjectAltName([DOI]4.6.2.1Identification Type Valuesあたりの)の中の特定の分野のどちらかを含むかもしれません。 それぞれのための用法記述は続きます。
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.
PeersかSimple Certificate Validationプロトコル(SCVP)サーバがRFC3280に従って証明経路を有効にしなければなりません。 これを許容する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.
Peerには、証明経路自体を構成する能力があるかもしれません。 しかしながら、信用アンカーとどんな推論PKCsも必要な状態でAdminはPeersを供給できなければなりません。 Adminは、テンプレートが経路合法化を容易にする手段としてPKCsでAIA拡張子を使用するのを確実にするかもしれません。
DNS MUST be supported by the Peers in order to support resolving URLs present in CDPs and AIA extensions.
DNS MUST、CDPsの現在のURLとAIA拡張子を決議するのを支持するためにPeersによって支持されてください。
3.7.3. Revocation Checking and Status Information
3.7.3. 取消しの照合と状態情報
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 SystemはPeersがIKEのアイデンティティのためにそれに寄贈されるPKCsの取消し状態をチェックできるメカニズムを提供しなければなりません。 メカニズムは非常に新鮮な取消し情報へのアクセスを考慮するはずです。 CRLsはこの情報を伝えるためのメカニズムとして選ばれました。 オペレータは同じくらいしばしば同じくらいロジスティックに可能なCRLsをリフレッシュするRECOMMENDEDです。
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.
イケで使用されるすべてのPKCsが有効なURLでcRLDistributionPointとauthorityInfoAccess分野を居住させなければなりません。 これで、PKCのすべての受取人がすぐに、取消しがどのように優れるかことであり、どこで取消し情報を見つけるかを知ることができるでしょう。 AIAが環境でCAsの複数の層が存在するところとカリフォルニアの主要なロールオーバーに関するケースに必要です。
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 Systemsは取消しをオフにするOPTIONにチェックさせます。 2Peersがネットワークの上で見本市における、または、研究室や、デモ環境などのCRLサービスへのアクセスなしで交信する予定であるとき、そのようなものは望まれるかもしれません。 取消しの照合がOFFであるなら、実現は、有効なアイデンティティとして交換にPKCを使用しなければならなくしかけて、どんなチェックも実行する必要はありません。
Bonatti, et al. Informational [Page 41] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[41ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
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の取消しがPeer(または、ユーザ)にアクセス認可の非活性化の唯一の手段として使用されると、非活性化の速度はPKIによって発行されて、発行されたCRLのリフレッシュレートと同じくらい急速でしょう。 アクセスの、より即座の非活性化が必要であるなら、より即座のアクセス非活性化を提供する認可のための別のメカニズムはCRLリフレッシュが提供できるよりVPN展開に層にされるべきです。 このプロフィールの範囲の外にそのような2番目のメカニズムはあります。 (例はXauth、L2TPの認証ですなど)
3.7.4. Error Handling in Revocation Checking and Certificate Path
Validation
3.7.4. 取消しの照合と証明書経路合法化におけるエラー処理
Thorough error condition descriptions and handling instructions are required for each transaction in the revocation checking and path validation process. Providing such error codes will greatly aid interoperability efforts between the PKI and IPsec products.
徹底的なエラー条件記述と取扱上の注意事項が取消しの照合と経路合法化の過程における各取引に必要です。 そのようなエラーコードを提供すると、PKIとIPsec製品の間の相互運用性の努力は大いに支援されるでしょう。
4. Security Considerations
4. セキュリティ問題
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の意図は、証明書管理(例えば、Cryptographic Message Syntax(CMS)、CMSの上のCertificate Management(CMC)、Certificate Request Message Format(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.
さらに、このドキュメントはPeerとAdminの役割の間の機能の配分における重要な柔軟性を許容します。 この機能配分はうまくいっている展開を達成することと、そして、PKI登録と管理過程の保全を維持することに重要です。 しかしながら、この配分への責任の多くが必ず製品implementersまで下がります、そして、適切の選択によるシステムオペレーターは安全保障政策規制のケースと開発を使用します。 PKI4IPSEC証明書管理のセキュリティを確実にすると慎重にこれらの要素を考えなければなりません。
Bonatti, et al. Informational [Page 42] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[42ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
5.2. Informative References
5.2. 有益な参照
[CERTPROFILE] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[CERTPROFILE] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、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.
[フレーム]Chokhani、S.、フォード、W.、Sabett、R.、メリル、C.、およびS.ウー、「インターネットX.509公開鍵暗号基盤証明書方針と証明は枠組みを練習します」、RFC3647、2003年11月。
[IKECERTPROFILE] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress,
February 2007.
B.と、「IKEv1/ISAKMPのインターネットIPセキュリティPKIプロフィール、IKEv2、およびPKIX」という[IKECERTPROFILE]Korverは進歩、2007年2月に働いています。
[IKEv1] Harkins, D. and D. Carrel, "The Internet Key
Exchange (IKE)", RFC 2409, November 1998.
[IKEv1]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[IPsec] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
6. Acknowledgements
6. 承認
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 Dployによって開発された先のドキュメントに基づいています。 そのドキュメントの原則エディタはグレゴリーM.Lebovitz(NetScreen/杜松)でした。 作者を寄付すると、Lebovitz、ポールホフマン(VPN Consortium)、ハンクモールディン(シスコシステムズ)、およびユシKukkonen(SSH Communications Security)は包含しました。 かなりの編集の貢献がレオPluswick(ICSA)、ティム・ポーク(NIST)、クリス・ウェルズ(SafeNet)、トーマスHardjono(ベリサイン)、カーライルアダムス(ゆだねる)、およびマイケルShieh(NetScreen/杜松)によってされました。
Bonatti, et al. Informational [Page 43] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[43ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
Once brought to the IETF's PKI4IPSEC WG, the following people made substantial contributions: Jim Schaad and Stefan Santesson.
一度IETFのPKI4IPSEC WGに持って来られて、以下の人々は多大な貢献をしました: ジムSchaadとステファンSantesson。
Editors' Addresses
エディタのアドレス
Chris Bonatti IECA, Inc. EMail: Bonattic@ieca.com
クリスBonatti IECA Inc.EMail: Bonattic@ieca.com
Sean Turner IECA, Inc. EMail: Turners@ieca.com
ショーンターナーIECA Inc.EMail: Turners@ieca.com
Gregory M. Lebovitz Juniper EMail: gregory.ietf@gmail.com
グレゴリーM.Lebovitz杜松メール: gregory.ietf@gmail.com
Bonatti, et al. Informational [Page 44] RFC 4809 Reqs for IPsec Certificate Mgmt Profile February 2007
Bonatti、他 IPsecのための情報[44ページ]のRFC4809Reqsはプロフィール2007年2月に管理を証明します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bonatti, et al. Informational [Page 45]
Bonatti、他 情報[45ページ]
一覧
スポンサーリンク
