Network Working Group B. Korver
Request for Comments: 4945 Network Resonance, Inc.
Category: Standards Track August 2007
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
IKEv1の/ ISAKMP、IKEv2の、およびPKIXのインターネットIPセキュリティPKIプロフィール
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec.
インターネット鍵交換（IKE）とX.509（PKIX）証明書プロファイルのための公開鍵インフラストラクチャは、両方の与えられたアプリケーションで使用するためにプロファイルされなければならないフレームワークを提供します。この文書では、IKE / IPsecの文脈の中でPKI技術を使用するための要件を定義しIKEとPKIXのプロファイルを提供します。文書は、明示的にPKIの問題に対処していない公開鍵証明書および関連キーイング材料の存在を前提とし、そのようなのIKEv1とIKEv2のようプロトコル仕様を、補完します。この文書では、これらの問題に対処します。対象読者は、IPsecのためのPKIの実装です。
Table of Contents
目次
1. Introduction ....................................................4
2. Terms and Definitions ...........................................4
3. Use of Certificates in RFC 2401 and IKEv1/ISAKMP ................5
3.1. Identification Payload .....................................5
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR .......................7
3.1.2. ID_FQDN .............................................9
3.1.3. ID_USER_FQDN .......................................10
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET,
ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE .............11
3.1.5. ID_DER_ASN1_DN .....................................11
3.1.6. ID_DER_ASN1_GN .....................................12
3.1.7. ID_KEY_ID ..........................................12
3.1.8. Selecting an Identity from a Certificate ...........12
3.1.9. Subject for DN Only ................................12
3.1.10. Binding Identity to Policy ........................13
3.2. Certificate Request Payload ...............................13
3.2.1. Certificate Type ...................................14
3.2.2. X.509 Certificate - Signature ......................14
3.2.3. Revocation Lists (CRL and ARL) .....................14
3.2.4. PKCS #7 wrapped X.509 certificate ..................15
3.2.5. Location of Certificate Request Payloads ...........15
3.2.6. Presence or Absence of Certificate Request
Payloads ...........................................15
3.2.7. Certificate Requests ...............................15
3.2.8. Robustness .........................................18
3.2.9. Optimizations ......................................18
3.3. Certificate Payload .......................................19
3.3.1. Certificate Type ...................................20
3.3.2. X.509 Certificate - Signature ......................20
3.3.3. Revocation Lists (CRL and ARL) .....................20
3.3.4. PKCS #7 Wrapped X.509 Certificate ..................20
3.3.5. Location of Certificate Payloads ...................21
3.3.6. Certificate Payloads Not Mandatory .................21
3.3.7. Response to Multiple Certification
Authority Proposals ................................21
3.3.8. Using Local Keying Materials .......................21
3.3.9. Multiple End-Entity Certificates ...................22
3.3.10. Robustness ........................................22
3.3.11. Optimizations .....................................23
4. Use of Certificates in RFC 4301 and IKEv2 ......................24
4.1. Identification Payload ....................................24
4.2. Certificate Request Payload ...............................24
4.2.1. Revocation Lists (CRL and ARL) .....................24
4.3. Certificate Payload .......................................25
4.3.1. IKEv2's Hash and URL of X.509 Certificate ..........25
4.3.2. Location of Certificate Payloads ...................25
4.3.3. Ordering of Certificate Payloads ...................25
5. Certificate Profile for IKEv1/ISAKMP and IKEv2 .................26
5.1. X.509 Certificates ........................................26
5.1.1. Versions ...........................................26
5.1.2. Subject ............................................26
5.1.3. X.509 Certificate Extensions .......................27
5.2. X.509 Certificate Revocation Lists ........................33
5.2.1. Multiple Sources of Certificate Revocation
Information ........................................34
5.2.2. X.509 Certificate Revocation List Extensions .......34
5.3. Strength of Signature Hashing Algorithms ..................35
6. Configuration Data Exchange Conventions ........................36
6.1. Certificates ..............................................36
6.2. CRLs and ARLs .............................................37
6.3. Public Keys ...............................................37
6.4. PKCS#10 Certificate Signing Requests ......................37
7. Security Considerations ........................................37
7.1. Certificate Request Payload ...............................37
7.2. IKEv1 Main Mode ...........................................37
7.3. Disabling Certificate Checks ..............................38
8. Acknowledgements ...............................................38
9. References .....................................................38
9.1. Normative References ......................................38
9.2. Informative References ....................................39
Appendix A. The Possible Dangers of Delta CRLs ....................40
Appendix B. More on Empty CERTREQs ................................40
IKE [1], ISAKMP [2], and IKEv2 [3] provide a secure key exchange mechanism for use with IPsec [4] [14]. In many cases, the peers authenticate using digital certificates as specified in PKIX [5]. Unfortunately, the combination of these standards leads to an underspecified set of requirements for the use of certificates in the context of IPsec.
IKE [1]、ISAKMP [2]及びIKEv2の[3]のIPsecで使用するための安全な鍵交換メカニズムを提供する[4] [14]。多くの場合、ピアはPKIX [5]で指定されるようにデジタル証明書を用いて認証を行います。残念ながら、これらの規格の組み合わせは、IPsecの文脈における証明書の使用のための要件の不足のセットにつながります。
ISAKMP references the PKIX certificate profile but, in many cases, merely specifies the contents of various messages without specifying their syntax or semantics. Meanwhile, the PKIX certificate profile provides a large set of certificate mechanisms that are generally applicable for Internet protocols, but little specific guidance for IPsec. Given the numerous underspecified choices, interoperability is hampered if all implementers do not make similar choices, or at least fail to account for implementations that have chosen differently.
ISAKMPは、PKIX証明書プロファイルを参照しますが、多くの場合、単にその構文やセマンティクスを指定せずに様々なメッセージの内容を指定します。一方、PKIX証明書プロファイルは、IPsecのためのインターネットプロトコルのために一般的に適用されている証明書のメカニズムの大規模なセットが、少し具体的なガイダンスを提供します。すべての実装者が同様の選択を行う、あるいは少なくとも異なっ選択した実装を説明するために失敗しない場合、多くの不足の選択肢を考えると、相互運用性が妨げられています。
This profile of the IKE and PKIX frameworks is intended to provide an agreed-upon standard for using PKI technology in the context of IPsec by profiling the PKIX framework for use with IKE and IPsec, and by documenting the contents of the relevant IKE payloads and further specifying their semantics.
IKEとPKIXの枠組みのこのプロファイルは、IKEおよびIPsecで使用するためのPKIXの枠組みをプロファイリングすることにより、および関連するIKEペイロードの内容を文書化することにより、IPsecののコンテキストでPKI技術を使用するための合意された標準を提供することを目的とし、さらにれます彼らのセマンティクスを指定します。
In addition to providing a profile of IKE and PKIX, this document attempts to incorporate lessons learned from recent experience with both implementation and deployment, as well as the current state of related protocols and technologies.
IKEとPKIXのプロファイルを提供することに加えて、この文書は実装と展開だけでなく、関連するプロトコルや技術の現在の状態の両方での最近の経験から学んだ教訓を組み込むしようとします。
Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and readers of this document are assumed to have read and understood those documents. The requirements and security aspects of those documents are fully relevant to this document as well.
ISAKMP、IKEv1の、IKEv2の、またはPKIXからの材料はここでは繰り返されていない、と本書の読者が読んで、それらの文書を理解していると想定されています。それらの文書の要件とセキュリティ面も同様に、この文書に完全に関連しています。
This document is organized as follows. Section 2 defines special terminology used in the rest of this document, Section 3 provides the profile of IKEv1/ISAKMP, Section 4 provides a profile of IKEv2, and Section 5 provides the profile of PKIX. Section 6 covers conventions for the out-of-band exchange of keying materials for configuration purposes.
次のようにこの文書は、組織化されています。第2節では、セクション4のIKEv2のプロファイルを提供し、第3のIKEv1 / ISAKMPのプロファイルを提供し、本文書の残りの部分で使用される特殊な用語を定義し、セクション5は、PKIXのプロファイルを提供します。第6節では、構成の目的のための材料をキーイングのアウトオブバンド交換のための規則をカバーしています。
Except for those terms that are defined immediately below, all terms used in this document are defined in either the PKIX [5], ISAKMP [2], IKEv1 [1], IKEv2 [3], or Domain of Interpretation (DOI) [6] documents.
すぐ下に定義されるこれらの用語を除き、本書で使用されるすべての用語は、いずれかのPKIX [5]、ISAKMP [2]、IKEv1の[1]のIKEv2 [3]、または解釈のドメイン（DOI）[6で定義されています]ドキュメント。
o Peer source address: The source address in packets from a peer. This address may be different from any addresses asserted as the "identity" of the peer.
Oピア送信元アドレス：ピアからのパケットのソースアドレス。このアドレスは、ピアの「アイデンティティ」としてアサート任意のアドレスと異なる場合があります。
o FQDN: Fully qualified domain name.
O FQDN：完全修飾ドメイン名。
o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both are referred to as ID_USER_FQDN in this document.
O ID_USER_FQDN：IKEv2のはID_RFC822_ADDRにID_USER_FQDNの名前を変更しました。どちらも、この文書でID_USER_FQDNと呼ばれています。
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 RFC 2119 [7].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[7]。
The Identification (ID) Payload indicates the identity claimed by the sender. The recipient can then use the ID as a lookup key for policy and for certificate lookup in whatever certificate store or directory that it has available. Our primary concern in this section is to profile the ID payload so that it can be safely used to generate or lookup policy. IKE mandates the use of the ID payload in Phase 1.
識別（ID）ペイロードは、送信者によって要求されたアイデンティティを示しています。受信者は、ポリシーのルックアップキーとして、それが利用できる持っているものは何でも証明書ストアまたはディレクトリに証明書の検索のためのIDを使用することができます。このセクションでは私たちの最大の関心事は、安全に生成したり、検索ポリシーに使用することができるようにIDペイロードをプロファイリングすることです。 IKEは、フェーズ1のIDペイロードの使用を義務付け。
The DOI [6] defines the 11 types of Identification Data that can be used and specifies the syntax for these types. These are discussed below in detail.
DOIは、[6]を使用することができる識別データの11種類を定義し、これらのタイプの構文を指定します。これらは、以下に詳細に説明されています。
The ID payload requirements in this document cover only the portion of the explicit policy checks that deal with the Identification Payload specifically. For instance, in the case where ID does not contain an IP address, checks such as verifying that the peer source address is permitted by the relevant policy are not addressed here, as they are out of the scope of this document.
この原稿カバーにIDペイロード要件具体的に識別ペイロードを取り扱う明確なポリシーチェックの一部のみ。これらはこの文書の範囲外であるとして、例えば、IDがIPアドレスを含まない場合には、そのようなピアの送信元アドレスは、関連ポリシーによって許可されていることを確認するようなチェックは、ここで対処されていません。
Implementations SHOULD populate ID with identity information that is contained within the end-entity certificate. Populating ID with identity information from the end-entity certificate enables recipients to use ID as a lookup key to find the peer end-entity certificate. The only case where implementations may populate ID with information that is not contained in the end-entity certificate is when ID contains the peer source address (a single address, not a subnet or range).
実装は、エンドエンティティ証明書内に含まれているID情報とIDを投入すべきです。エンドエンティティ証明書からID情報とIDを移植するには、ピア・エンドエンティティ証明書を見つけるために、検索キーとしてIDを使用する受信者を可能にします。 IDがピア送信元アドレス（単一アドレスではなく、サブネットまたは範囲）を含有する場合に実装がエンドエンティティ証明書に含まれていない情報とIDを読み込むことができる場合のみです。
Because implementations may use ID as a lookup key to determine which policy to use, all implementations MUST be especially careful to verify the truthfulness of the contents by verifying that they correspond to some keying material demonstrably held by the peer.
実装が使用するポリシーを決定するためにルックアップキーとしてIDを使用することができるので、すべての実装は、それらが明らかピアによって保持されているいくつかの鍵材料に対応することを確認することによってコンテンツの真実性を検証することは、特に注意しなければなりません。
Failure to do so may result in the use of an inappropriate or insecure policy. The following sections describe the methods for performing this binding.
これを怠ると、不適切または不安定なポリシーの使用をもたらすことができます。以下のセクションでは、この結合を行うための方法を記載しています。
The following table summarizes the binding of the Identification Payload to the contents of end-entity certificates and of identity information to policy. Each ID type is covered more thoroughly in the following sections.
次の表は、エンドエンティティ証明書のと政策へのアイデンティティ情報の内容にIDペイロードの結合要約したものです。各IDのタイプは、次のセクションでさらに詳細に説明されて。
ID type | Support | Correspond | Cert | SPD lookup
| for send | PKIX Attrib | matching | rules
-------------------------------------------------------------------
| | | |
IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | iPAddress | |
| | | |
FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | dNSName | |
| | | |
USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | rfc822Name | |
| | | |
IP range | MUST NOT | n/a | n/a | n/a
| | | |
DN | MUST [a] | Entire | MUST [b] | MUST support lookup
| | Subject, | | on any combination
| | bitwise | | of C, CN, O, or OU
| | compare | |
| | | |
GN | MUST NOT | n/a | n/a | n/a
| | | |
KEY_ID | MUST NOT | n/a | n/a | n/a
| | | |
[a] = Implementation MUST have the configuration option to send this ID type in the ID payload. Whether or not the ID type is used is a matter of local configuration.
[A] =実装IDペイロードにこのIDタイプを送信するための設定オプションを持たなければなりません。 IDタイプが使用されているかどうかは、ローカル設定の問題です。
[b] = The ID in the ID payload MUST match the contents of the corresponding field (listed) in the certificate exactly, with no other lookup. The matched ID MAY be used for Security Policy Database (SPD) lookup, but is not required to be used for this.
[B] = IDペイロード内のIDは他のルックアップと、正確に証明書に（記載されている）対応するフィールドの内容と一致しなければなりません。マッチしたIDは、セキュリティポリシーデータベース（SPD）のルックアップのために使用することができるが、このために使用する必要がありません。
[c] = At a minimum, Implementation MUST be capable of being configured to perform exact matching of the ID payload contents to an entry in the local SPD.
[C] =最低でも、実装は、ローカルSPD内のエントリにIDペイロードの内容の正確なマッチングを実行するように構成することができなければなりません。
[d] = In addition, the implementation MAY also be configurable to perform substring or wildcard matches of ID payload contents to entries in the local SPD. (More on this in Section 3.1.5.)
[D] =さらに、実装は、ローカルSPD内のエントリにIDペイロードの内容のストリングまたはワイルドカードマッチを実行するために構成可能です。 （セクション3.1.5でこれについての詳細。）
When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, implementations MUST be able to be configured to send the same string as it appears in the corresponding SubjectAltName extension. This document RECOMMENDS that deployers use this configuration option. All these ID types are treated the same: as strings that can be compared easily and quickly to a corresponding string in an explicit value in the certificate. Of these types, FQDN and USER_FQDN are RECOMMENDED over IP addresses (see discussion in Section 3.1.1).
IPV4_ADDR、IPV6_ADDR、FQDN、またはUSER_FQDNを送信する場合、実装は、それが対応するsubjectAltName拡張に表示される同じ文字列を送信するように構成することができなければなりません。この文書では、デプロイヤは、この設定オプションを使用することをお勧めします。これらのすべてのIDタイプが同じに扱われる：証明書に明示的な値に対応する文字列に簡単かつ迅速に比較することができる文字列として。これらのタイプの、FQDNとUSER_FQDNは（セクション3.1.1で議論を参照）IPアドレス上で推奨されています。
When sending a Distinguished Name (DN) as ID, implementations MUST send the entire DN in ID. Also, implementations MUST support at least the C, CN, O, and OU attributes for SPD matching. See Section 3.1.5 for more details about DN, including SPD matching.
IDとして識別名（DN）を送信する場合、実装は、ID全体DNを送らなければなりません。また、実装は、少なくともC、CN、O、およびOUはSPDマッチング属性サポートしなければなりません。 SPDのマッチングなど、DNについて詳しくは、3.1.5項を参照してください。
Recipients MUST be able to perform SPD matching on the exact contents of the ID, and this SHOULD be the default setting. In addition, implementations MAY use substrings or wildcards in local policy configuration to do the SPD matching against the ID contents. In other words, implementations MUST be able to do exact matches of ID to SPD, but MAY also be configurable to do substring or wildcard matches of ID to SPD.
受信者は、IDの正確な内容にSPDマッチングを実行できる必要があり、これがデフォルトの設定であるべきです。また、実装は、IDのコンテンツに対してSPDマッチングを行うために、ローカルポリシー設定にサブストリングまたはワイルドカードを使用するかもしれ。換言すれば、実装は、SPDにIDの正確なマッチを行うことができなければならないだけでなく、SPDにIDのストリングまたはワイルドカードマッチを行うことが設定可能です。
Implementations MUST support at least the ID_IPV4_ADDR or ID_IPV6_ADDR ID type, depending on whether the implementation supports IPv4, IPv6, or both. These addresses MUST be encoded in "network byte order", as specified in IP [8]: The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For the ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8]. For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen octets [10].
実装は、実装は、IPv4、IPv6の、または両方をサポートしているかどうかに応じて、少なくともID_IPV4_ADDR又はID_IPV6_ADDR IDタイプをサポートしなければなりません。これらのアドレス「ネットワークバイト順」に符号化されなければならない、IPで指定されるように[8]：各オクテットの最下位ビット（LSB）ネットワークアドレスに対応するバイトのLSBです。 ID_IPV4_ADDRタイプの場合、ペイロードは正確に4オクテット[8]を含まなければなりません。 ID_IPV6_ADDRタイプの場合、ペイロードは正確に16オクテット[10]を含まなければなりません。
Implementations SHOULD NOT populate ID payload with IP addresses due to interoperability issues such as problems with Network Address Translator (NAT) traversal, and problems with IP verification behavior.
実装は、このようなIPの検証の動作とネットワークアドレス変換（NAT）トラバーサル、および問題を抱える問題として、相互運用性の問題に起因するIPアドレスを持つIDペイロードを投入すべきではありません。
Deployments may only want to consider using the IP address as ID if all of the following are true:
配備は、次のすべてに該当する場合、IDとIPアドレスを使用して検討する必要があります。
o the peer's IP address is static, not dynamically changing
OピアのIPアドレスは静的ではなく動的に変化あり
o the peer is NOT behind a NAT'ing device o the administrator intends the implementation to verify that the peer source address matches the IP address in the ID received, and that in the iPAddress field in the peer certificate's SubjectAltName extension.
管理者は、ピア送信元アドレスがIDでIPアドレスが受信一致し、ピア証明書のsubjectAltName拡張でIPアドレスフィールドにそのことを確認するために実施を予定でoをピアoをNAT'ingデバイスの背後ではありません。
Implementations MUST be capable of verifying that the IP address presented in ID matches via bitwise comparison the IP address present in the certificate's iPAddress field of the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the iPAddress field in the SubjectAltName extension for equality, binary comparison MUST be performed. Note that certificates may contain multiple address identity types -- in which case, at least one must match the source IP. If the default is enabled, then a mismatch between the two addresses MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability as current implementations vary greatly in how they behave on this topic.
実装はIDに提示したIPアドレスは、ビット単位の比較を経てsubjectAltName拡張の証明書のIPアドレスのフィールドに存在するIPアドレスと一致することを確認することができなければなりません。実装は、デフォルトでは、この検証を実行しなければなりません。平等のためのsubjectAltName拡張内のIPアドレスフィールドとIDの内容を比較すると、バイナリ比較が行われなければなりません。その場合には、少なくとも一つの送信元IPと一致しなければなりません - 証明書を使用すると、複数のアドレスのIDタイプが含まれていてもよいことに注意してください。デフォルトが有効になっている場合、2つのアドレス間の不一致はエラーとして扱わなければならない、とセキュリティアソシエーションの設定は中止されなければなりません。このイベントは、監査対象にすべきです。実装は（すなわち、ローカルポリシー設定を有効にすることができます）その検証ステップをスキップする設定オプションを提供することができるが、そのオプションはデフォルトでオフでなければなりません。私たちは、現在の実装では、彼らがこのトピックにどのように振る舞うかで大きく異なるよう、より良い相互運用性を可能にするためには、「オプション・ツー・スキップ・検証」が挙げられます。
In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the address contained in the IP header. Implementations SHOULD be able to check the address in either the outermost or innermost IP header and MAY provide a configuration option for specifying which is to be checked. If there is no configuration option provided, an implementation SHOULD check the peer source address contained in the outermost header (as is the practice of most of today's implementations). If ID is one of the IP address types, then implementations MUST perform this verification by default. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e. local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on the topic of verification of source IP.
また、実装は、IDに含まれるアドレスは、IPヘッダに含まれるアドレスと同じであることを確認することができなければなりません。実装は、いずれかの最も外側または最も内側のIPヘッダーでアドレスを確認することができるべきであると確認される指定のための設定オプションを提供してもよいです。ありません設定オプションがない場合、実装は、（今日の実装のほとんどの慣行であるように）最も外側のヘッダに含まれるピア送信元アドレスを確認してください。 IDは、IPアドレスの種類のいずれかである場合、実装は、デフォルトでは、この検証を実行しなければなりません。このデフォルトが有効になっている場合、不一致はエラーとして扱わなければならない、とセキュリティアソシエーションの設定は中止されなければなりません。このイベントは、監査対象にすべきです。実装はその検証ステップをスキップする（有効にすることができ、すなわちローカルポリシーの設定）に設定オプションを提供することができるが、そのオプションはデフォルトでオフでなければなりません。私たちは、現在の実装では、彼らが元IPの検証の話題にどのように動作するかで大きく異なるよう、よりよい相互運用性を可能にするためには、「オプション・ツー・スキップ・検証」が挙げられます。
If the default for both the verifications above are enabled, then, by transitive property, the implementation will also be verifying that the peer source IP address matches via a bitwise comparison the contents of the iPAddress field in the SubjectAltName extension in the certificate. In addition, implementations MAY allow administrators to configure a local policy that explicitly requires that the peer source IP address match via a bitwise comparison the contents of the iPAddress field in the SubjectAltName extension in the certificate. Implementations SHOULD allow administrators to configure a local policy that skips this validation check.
上記の検証が有効になっている両方のデフォルトは、その後、推移プロパティで、実装はまた、ピア送信元IPアドレスは、ビット単位の比較を経て一致していることを検証する場合、証明書内のsubjectAltName拡張でIPアドレスフィールドの内容。また、実装は、管理者が明示的に証明書のSubjectAltName拡張のビット単位の比較IPアドレスフィールドの内容を経由してピアの送信元IPアドレスが一致している必要がローカルポリシーを設定することを可能にします。実装は、管理者は、この検証チェックをスキップするローカルポリシーを設定できるようにする必要があります。
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up the policy in the SPD, and such would be a matter of local security policy configuration.
実装はSPDにポリシーをルックアップするために、サブストリング、ワイルドカード、またはIDの内容の正規表現のマッチングをサポートしてもよく、このような、ローカルセキュリティポリシーの設定の問題でしょう。
Implementations MAY use the IP address found in the header of packets received from the peer to look up the policy, but such implementations MUST still perform verification of the ID payload. Although packet IP addresses are inherently untrustworthy and must therefore be independently verified, it is often useful to use the apparent IP address of the peer to locate a general class of policies that will be used until the mandatory identity-based policy lookup can be performed.
実装は、ポリシーをルックアップするためにピアから受信したパケットのヘッダに見られるIPアドレスを使用することができるが、そのような実装はまだIDペイロードの検証を実行しなければなりません。パケットのIPアドレスは、本質的に信頼できないであるため、個別に検証する必要がありますが、多くの場合、必須のアイデンティティベースのポリシーのルックアップを実行できるようになるまで使用されるポリシーの一般的なクラスを見つけるためにピアの見かけ上のIPアドレスを使用すると便利です。
For instance, if the IP address of the peer is unrecognized, a VPN gateway device might load a general "road warrior" policy that specifies a particular Certification Authority (CA) that is trusted to issue certificates that contain a valid rfc822Name, which can be used by that implementation to perform authorization based on access control lists (ACLs) after the peer's certificate has been validated. The rfc822Name can then be used to determine the policy that provides specific authorization to access resources (such as IP addresses, ports, and so forth).
例えば、ピアのIPアドレスが認識されない場合は、VPNゲートウェイデバイスが有効なrfc822Nameでが含まれている証明書を発行する信頼されている特定の認証局（CA）を指定し、一般的な「道の戦士」ポリシーをロードするかもしれない、とすることができますピアの証明書が検証された後に、アクセス制御リスト（ACL）に基づいて認可を実行するためにその実装によって使用されます。 rfc822Nameでは、次いで、（例えば等々IPアドレス、ポート、など）リソースにアクセスするための特定の許可を提供するポリシーを決定するために使用することができます。
As another example, if the IP address of the peer is recognized to be a known peer VPN endpoint, policy may be determined using that address, but until the identity (address) is validated by validating the peer certificate, the policy MUST NOT be used to authorize any IPsec traffic.
別の例として、ピアのIPアドレスが既知のピアVPNエンドポイントであると認識されている場合、ポリシーは、そのアドレスを使用して決定することができるが、ピアの証明書を検証することによって検証されるアイデンティティ（アドレス）まで、ポリシーを使用してはいけませんすべてのIPsecトラフィックを認可します。
Implementations MUST support the ID_FQDN ID type, generally to support host-based access control lists for hosts without fixed IP addresses. However, implementations SHOULD NOT use the DNS to map the FQDN to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example, if DNSSEC [11] were employed for that FQDN.
実装は、固定IPアドレスをせずにホスト用のホストベースのアクセス制御リストをサポートするために、一般的に、ID_FQDN IDの種類をサポートしなければなりません。しかし、実装は、そのマッピングが安全であると知られていない限りDNSSEC [11]そのFQDNのために使用された場合、例えば、任意の政策決定への入力のためのIPアドレスにFQDNをマッピングするためにDNSを使用しないでください。
If ID contains an ID_FQDN, implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the dNSName field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the dNSName field in the SubjectAltName extension for equality, case-insensitive string comparison MUST be performed. Note that case-insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic.
IDがID_FQDNが含まれている場合、実装は、IDペイロードに含まれる識別情報がsubjectAltName拡張内のdNSName分野におけるピアエンドエンティティ証明書に含まれる識別情報と一致することを確認できなければなりません。実装は、デフォルトでは、この検証を実行しなければなりません。平等のためのsubjectAltName拡張内のdNSNameフィールドとIDの内容を比較するとき、大文字と小文字を区別しない文字列比較を実行しなければなりません。 （IDN [12]を参照してください）その大文字小文字を区別しない文字列比較が同様に国際化ドメイン名（IDN）で動作します。サブストリング、ワイルドカード、または正規表現マッチングは、この比較のために行ってはなりません。このデフォルトが有効になっている場合、不一致はエラーとして扱わなければならない、とセキュリティアソシエーションの設定は中止されなければなりません。このイベントは、監査対象にすべきです。実装は（すなわち、ローカルポリシー設定を有効にすることができます）その検証ステップをスキップする設定オプションを提供することができるが、そのオプションはデフォルトでオフでなければなりません。私たちは、現在の実装では、彼らがこのトピックにどのように振る舞うかで大きく異なるよう、よりよい相互運用性を可能にするためには、「オプション・ツー・スキップ・検証」が挙げられます。
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up the policy in the SPD, and such would be a matter of local security policy configuration.
実装はSPDにポリシーをルックアップするために、サブストリング、ワイルドカード、またはIDの内容の正規表現のマッチングをサポートしてもよく、このような、ローカルセキュリティポリシーの設定の問題でしょう。
Implementations MUST support the ID_USER_FQDN ID type, generally to support user-based access control lists for users without fixed IP addresses. However, implementations SHOULD NOT use the DNS to map the FQDN portion to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example, if DNSSEC [11] were employed for that FQDN.
実装は、固定IPアドレスを持たないユーザのためのユーザベースのアクセス制御リストをサポートするために、一般的に、ID_USER_FQDN IDの種類をサポートしなければなりません。しかし、実装は、そのマッピングが安全であると知られていない限りDNSSEC [11]そのFQDNのために使用された場合、例えば、任意の政策決定への入力のためのIPアドレスにFQDN部分をマッピングするためにDNSを使用しないでください。
Implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the rfc822Name field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the rfc822Name field in the SubjectAltName extension for equality, case-insensitive string comparison MUST be performed. Note that case-insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic.
実装は、IDペイロードに含まれる識別情報がsubjectAltName拡張にrfc822Nameでフィールドに、ピア・エンドエンティティ証明書に含まれる識別情報と一致することを確認することができなければなりません。実装は、デフォルトでは、この検証を実行しなければなりません。平等のためのsubjectAltName拡張にrfc822NameでフィールドとIDの内容を比較するとき、大文字と小文字を区別しない文字列比較を実行しなければなりません。 （IDN [12]を参照してください）その大文字小文字を区別しない文字列比較が同様に国際化ドメイン名（IDN）で動作します。サブストリング、ワイルドカード、または正規表現マッチングは、この比較のために行ってはなりません。このデフォルトが有効になっている場合、不一致はエラーとして扱わなければならない、とセキュリティアソシエーションの設定は中止されなければなりません。このイベントは、監査対象にすべきです。実装は（すなわち、ローカルポリシー設定を有効にすることができます）その検証ステップをスキップする設定オプションを提供することができるが、そのオプションはデフォルトでオフでなければなりません。私たちは、現在の実装では、彼らがこのトピックにどのように振る舞うかで大きく異なるよう、よりよい相互運用性を可能にするためには、「オプション・ツー・スキップ・検証」が挙げられます。
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up policy in the SPD, and such would be a matter of local security policy configuration.
実装はSPDにポリシーをルックアップするために、サブストリング、ワイルドカード、またはIDの内容の正規表現のマッチングをサポートしてもよく、このような、ローカルセキュリティポリシーの設定の問題でしょう。
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE
3.1.4. ID_IPV4_ADDR_SUBNET、ID_IPV6_ADDR_SUBNET、ID_IPV4_ADDR_RANGE、ID_IPV6_ADDR_RANGE
Note that RFC 3779 [13] defines blocks of addresses using the certificate extension identified by:
そのRFC 3779 [13]によって識別証明書拡張を使用して、アドレスのブロックを定義することに注意してください。
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
although use of this extension in IKE is considered experimental at this time.
IKEでこの拡張の使用は、この時点で実験的な考えられるが。
Implementations MUST support receiving the ID_DER_ASN1_DN ID type. Implementations MUST be capable of generating this type, and the decision to do so will be a matter of local security policy configuration. When generating this type, implementations MUST populate the contents of ID with the Subject field from the end-entity certificate, and MUST do so such that a binary comparison of the two will succeed. If there is not a match, this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
実装はID_DER_ASN1_DN IDタイプを受け取るサポートしなければなりません。実装は、このタイプを生成することができなければなりませんし、そうする決定は、ローカルセキュリティポリシーの設定の問題になります。このタイプを生成する場合、実装は、エンドエンティティ証明書の件名フィールドにIDの内容を移入する必要があり、二つのバイナリ比較が成功するように、そのような行う必要があります。一致がない場合、これはエラーとして扱わなければならない、とセキュリティアソシエーションの設定は中止されなければなりません。このイベントは、監査対象にすべきです。
Implementations MUST NOT populate ID with the Subject from the end-entity certificate if it is empty, even though an empty certificate Subject is explicitly allowed in the "Subject" section of the PKIX certificate profile.
それは空の証明書のサブジェクトが明示的PKIX証明書プロファイルの「件名」のセクションでは許可されていても、空の場合、実装は、エンドエンティティ証明書のSubjectにIDを移入してはなりません。
Regarding SPD matching, implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. However, operational experience has shown that using the entire DN in local configuration is difficult, especially in large-scale deployments. Therefore, implementations also MUST be able to perform SPD matches of any combination of one or more of the C, CN, O, OU attributes within Subject DN in the ID to the same in the SPD. Implementations MAY support matching using additional DN attributes in any combination, although interoperability is far from certain and is dubious. Implementations MAY also support performing substring, wildcard, or regular expression matches for any of its supported DN attributes from ID, in any combination, to the SPD. Such flexibility allows deployers to create one SPD entry on the gateway for an entire department of a company (e.g., O=Foobar Inc., OU=Engineering) while still allowing them to draw out other details from the DN (e.g., CN=John Doe) for auditing purposes. All the above is a matter of local implementation and local policy definition and enforcement capability, not bits on the wire, but will have a great impact on interoperability.
SPDのマッチングについては、実装は、SPD内のエントリにID全体DNのビット単位の比較に基づいてマッチングを行うことができなければなりません。しかし、運用経験は、ローカル設定にDN全体を使用すると、特に大規模な展開では、困難であることが示されています。したがって、実装はまた、C、CNの一つ以上の任意の組み合わせのSPDの一致を実行できる必要があり、O、OUは、SPDに同じにIDにサブジェクトDN内の属性。相互運用性はあるから遠いと疑わしいですが、実装は、追加のDNは、任意の組み合わせで属性を使用してマッチングをサポートするかもしれません。また、実装は、サブストリング、ワイルドカードを実行するサポートすることができ、またはそのサポートDNのいずれかがSPDに、任意の組み合わせで、IDから属性の正規表現は一致しています。このような柔軟性は、デプロイヤは、まだ彼らはDN（例えば、CN =ジョンから他の細部を引き出すために可能にしながら、会社（例えば、O = FOOBAR株式会社、OU =エンジニアリング）の部門全体のためのゲートウェイ上の1つのSPDエントリを作成することができます監査目的のためにDOE）。上記のすべてのローカル実装およびローカルポリシーの定義と執行機能の問題ではなく、ワイヤ上のビットですが、相互運用性に大きな影響を持つことになります。
Implementations MUST NOT generate this type, because the recipient will be unlikely to know how to use it.
受信者がそれを使用する方法を知っている可能性は低いだろうので、実装は、このタイプを生成してはなりません。
The ID_KEY_ID type used to specify pre-shared keys and thus is out of scope.
ID_KEY_IDタイプは、事前共有キーを指定するために使用されるので、範囲外です。
Implementations MUST support certificates that contain more than a single identity, such as when the Subject field and the SubjectAltName extension are both populated, or the SubjectAltName extension contains multiple identities irrespective of whether or not the Subject is empty. In many cases, a certificate will contain an identity, such as an IP address, in the SubjectAltName extension in addition to a non-empty Subject.
実装は、件名フィールドとsubjectAltName拡張の両方移入され、またはsubjectAltName拡張に関係なく件名が空であるか否かの複数のIDが含まれている場合のような単一のアイデンティティ以上を含む証明書を、サポートしなければなりません。多くの場合、証明書は、空でない件名に加えて、subjectAltName拡張には、IPアドレスなど、アイデンティティーが含まれています。
Implementations should populate ID with whichever identity is likely to be named in the peer's policy. In practice, this generally means FQDN, or USER_FQDN, but this information may also be available to the administrator through some out-of-band means. In the absence of such out-of-band configuration information, the identity with which an implementation chooses to populate the ID payload is a local matter.
実装は、ピアのポリシーで指定される可能性が高い方のIDとIDを移入する必要があります。実際には、これは一般的にFQDN、またはUSER_FQDNを意味しますが、この情報はまた、いくつかのアウトオブバンド手段を通じて管理者が利用できます。そのようなアウトオブバンド構成情報が存在しない状態で、実装はIDペイロードを移入することを選択したと同一のローカルの問題です。
If an FQDN is intended to be processed as an identity for the purposes of ID matching, it MUST be placed in the dNSName field of the SubjectAltName extension. Implementations MUST NOT populate the Subject with an FQDN in place of populating the dNSName field of the SubjectAltName extension.
FQDNは、ID照合の目的のためのIDとして処理されることが意図されている場合は、subjectAltName拡張ののdNSName分野に置かなければなりません。実装はsubjectAltName拡張ののdNSName分野を取り込むの代わりにFQDNと件名を移入してはなりません。
While nothing prevents an FQDN, USER_FQDN, or IP address information from appearing somewhere in the Subject contents, such entries MUST NOT be interpreted as identity information for the purposes of matching with ID or for policy lookup.
何も件名内容のどこかに現れるのFQDN、USER_FQDN、またはIPアドレス情報を妨げないが、そのようなエントリは、IDまたはポリシー検索のためのマッチングのためにID情報として解釈してはなりません。
In the presence of certificates that contain multiple identities, implementations should select the most appropriate identity from the certificate and populate the ID with that. The recipient MUST use the identity sent as a first key when selecting the policy. The recipient MUST also use the most specific policy from that database if there are overlapping policies caused by wildcards (or the implementation can de-correlate the policy database so there will not be overlapping entries, or it can also forbid creation of overlapping policies and leave the de-correlation process to the administrator, but, as this moves the problem to the administrator, it is NOT RECOMMENDED).
複数のIDを含む証明書の存在下で、実装は証明書から最も適切なIDを選択する必要がありますし、それにIDを取り込みます。受信者は、ポリシーを選択する際に、最初のキーとして送信アイデンティティを使用しなければなりません。受信者は、ワイルドカード（または実装に起因するオーバーラップポリシーができる無相関ポリシーデータベースがある場合、その重複したエントリがないだろうか、それはまた、オーバーラップポリシーの作成を禁止しておくことができ、そのデータベースから最も特定のポリシーを使用しなければなりません非相関の管理者へのプロセス、しかし、これは管理者に問題を移動すると、それが推奨されていません）。
For example, imagine that an implementation is configured with a certificate that contains both a non-empty Subject and a dNSName. The sender's policy may specify which of those to use, and it indicates the policy to the other end by sending that ID. If the recipient has both a specific policy for the dNSName for this host and generic wildcard rule for some attributes present in the Subject field, it will match a different policy depending on which ID is sent. As the sender knows why it wanted to connect the peer, it also knows what identity it should use to match the policy it needs to the operation it tries to perform; it is the only party who can select the ID adequately.
例えば、実装は空でないサブジェクトとのdNSName両方を含む証明書で構成されていることを想像します。送信者のポリシーは、それらのどれを使用することを指定することができ、そしてそれはそのIDを送信することによって、もう一方の端にポリシーを示します。受信者は件名フィールドに存在するいくつかの属性については、このホストおよび一般的なワイルドカードルールのためのdNSNameのための特定のポリシーの両方がある場合、それはIDが送信されるに応じて、異なるポリシーと一致します。それはピアを接続したい理由、送信者が知っているように、それはまた、それは、それが実行しようとする操作に必要方針を一致させるために使用すべきかのアイデンティティを知っています。それが適切にIDを選択することができる唯一の政党です。
In the event that the policy cannot be found in the recipient's SPD using the ID sent, then the recipient MAY use the other identities in the certificate when attempting to match a suitable policy. For example, say the certificate contains a non-empty Subject field, a dNSName and an iPAddress. If an iPAddress is sent in ID but no specific entry exists for the address in the policy database, the recipient MAY search in the policy database based on the Subject or the dNSName contained in the certificate.
適したポリシーと一致しようとしたときにポリシーが送信されたIDを使用して、受信者のSPDで見つけることができない場合には、その後、受信者は、証明書内の他のアイデンティティを使用するかもしれません。たとえば、証明書が空でないサブジェクトフィールド、のdNSNameとIPアドレスが含まれていると言います。 IPアドレスがIDに送信されますが、具体的なエントリがポリシーデータベース内のアドレスのために存在しない場合、受信者は件名または証明書に含まれているのdNSNameに基づいてポリシーデータベースで検索することができます。
The Certificate Request (CERTREQ) Payload allows an implementation to request that a peer provide some set of certificates or certificate revocation lists (CRLs). It is not clear from ISAKMP exactly how that set should be specified or how the peer should respond. We describe the semantics on both sides.
証明書要求（CERTREQ）ペイロードは、実装は、ピアが証明書や証明書失効リスト（CRL）のいくつかのセットを提供することを要求することができます。そのセットを指定する必要があります正確にどのようにか、ピアが応答すべきかISAKMPから明らかではありません。私たちは、両側の意味を説明します。
The Certificate Type field identifies to the peer the type of certificate keying materials that are desired. ISAKMP defines 10 types of Certificate Data that can be requested and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
証明書の種類フィールドは、ピアに望まれている証明書キーイング材料のタイプを識別する。 ISAKMPを要求することができる証明書データの10種類を定義し、これらのタイプのための構文を指定します。このドキュメントの目的のために、唯一の次のタイプは関連しています。
o X.509 Certificate - Signature o Revocation Lists (CRL and ARL) o PKCS #7 wrapped X.509 certificate
O X.509証明書 - PKCS＃7 O失効リスト（CRLとARL）O署名X.509証明書を包ん
The use of the other types are out of the scope of this document:
他のタイプの使用は、この文書の範囲外です：
o X.509 Certificate - Key Exchange o PGP (Pretty Good Privacy) Certificate o DNS Signed Key o Kerberos Tokens o SPKI (Simple Public Key Infrastructure) Certificate o X.509 Certificate Attribute
O X.509証明書 - DNSは、X.509証明書の属性oをSPKI（簡易公開鍵基盤）証明書oをケルベロストークンOキーを締結oをPGP Oキー交換（プリティグッドプライバシー）証明書
This type requests that the end-entity certificate be a certificate used for signing.
このタイプは、エンドエンティティ証明書が署名に使用する証明書を要求します。
ISAKMP does not support Certificate Payload sizes over approximately 64K, which is too small for many CRLs, and UDP fragmentation is likely to occur at sizes much smaller than that. Therefore, the acquisition of revocation material is to be dealt with out-of-band of IKE. For this and other reasons, implementations SHOULD NOT generate CERTREQs where the Certificate Type is "Certificate Revocation List (CRL)" or "Authority Revocation List (ARL)". Implementations that do generate such CERTREQs MUST NOT require the recipient to respond with a CRL or ARL, and MUST NOT fail when not receiving any. Upon receipt of such a CERTREQ, implementations MAY ignore the request.
ISAKMPは、証明書のペイロードが多くのCRLには小さすぎるの上に約64Kを、サイズサポートしていない、とUDPの断片化は、それよりもはるかに小さいサイズで発生する可能性があります。したがって、失効材料の取得は、アウトオブバンドIKEの扱われるべきです。このおよびその他の理由により、実装は証明書の種類があるCERTREQsを生成するべきではありません「証明書失効リスト（CRL）」または「認証局失効リスト（ARL）」。このようCERTREQsを生成しない実装はCRLまたはARLで応答する受信者を要求してはなりませんし、いずれかを受信していない時に失敗してはなりません。そのようなCERTREQを受信すると、実装が要求を無視するかもしれません。
In lieu of exchanging revocation lists in-band, a pointer to revocation checking SHOULD be listed in either the CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) certificate extensions (see Section 5 for details). Unless other methods for obtaining revocation information are available, implementations SHOULD be able to process these attributes, and from them be able to identify cached revocation material, or retrieve the relevant revocation material from a URL, for validation processing. In addition, implementations MUST have the ability to configure validation checking information for each certification authority. Regardless of the method (CDP, AIA, or static configuration), the acquisition of revocation material SHOULD occur out-of-band of IKE. Note, however, that an inability to access revocation status data through out-of-band means provides a potential security vulnerability that could potentially be exploited by an attacker.
インバンド失効リストを交換する代わりに、失効確認へのポインタCRLDistributionPoints（CDP）またはAuthorityInfoAccess（AIA）証明書拡張のいずれかで表示される必要があり（詳細については、セクション5を参照）。失効情報を取得するための他の方法が用意されていない限り、実装はこれらの属性を処理することが可能であるべきであり、それから、キャッシュされた失効材料を特定することができ、または検証処理のために、URLから関連失効材料を取り出します。また、実装は各認証局の検証チェックの情報を設定する機能を持たなければなりません。かかわらず、方法（CDP、AIA、又は静的な構成）の、失効材料の取得は、アウトオブバンドIKEの起こるべきです。攻撃者によって悪用される可能性が潜在的なセキュリティ脆弱性を提供できないことを意味するが、アウトオブバンドを介して失効ステータスデータにアクセスすること、しかし、注意してください。
This ID type defines a particular encoding (not a particular certificate type); some current implementations may ignore CERTREQs they receive that contain this ID type, and the editors are unaware of any implementations that generate such CERTREQ messages. Therefore, the use of this type is deprecated. Implementations SHOULD NOT require CERTREQs that contain this Certificate Type. Implementations that receive CERTREQs that contain this ID type MAY treat such payloads as synonymous with "X.509 Certificate - Signature".
このIDのタイプは、特定の符号化（ない特定の証明書の種類）を定義します。いくつかの現在の実装では、このIDタイプが含まれている、彼らが受け取るCERTREQsを無視することができ、そして編集者は、このようなCERTREQメッセージを生成する任意の実装を知りません。したがって、このタイプの使用が推奨されていません。実装は、この証明書の種類が含まれているCERTREQsを必要とすべきではありません。このIDタイプが含まれているCERTREQsを受け取る実装は、「 - 署名X.509証明書」の代名詞のようなペイロードを扱うかもしれ。
In IKEv1 Main Mode, the CERTREQ payload MUST be in messages 4 and 5.
IKEv1のメインモードでは、CERTREQペイロードはメッセージ4と5でなければなりません。
When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ. In other words, an implementation that does not send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads.
インバンド証明書キーイング材料の交換が望まれる場合、インプリメンテーションは、少なくとも一つのCERTREQを送信することにより、このピアに通知しなければなりません。言い換えれば、交換の間に任意のCERTREQsを送信しない実装は任意のCERTペイロードを受信するために期待するべきではありません。
When requesting in-band exchange of keying materials, implementations SHOULD generate CERTREQs for every peer trust anchor that local policy explicitly deems trusted during a given exchange. Implementations SHOULD populate the Certification Authority field with the Subject field of the trust anchor, populated such that binary comparison of the Subject and the Certification Authority will succeed.
キーイング材料のインバンド交換を要求する場合、実装は、ローカルポリシーが明示的に与えられた交換中に、信頼できると判断したすべてのピア・トラストアンカーのためのCERTREQsを生成する必要があります。実装は、件名と認証局のバイナリ比較が成功するような人口、トラストアンカーの件名フィールドに認証局のフィールドを埋めるべきです。
Upon receipt of a CERTREQ, implementations MUST respond by sending at least the end-entity certificate corresponding to the Certification Authority listed in the CERTREQ unless local security policy configuration specifies that keying materials must be exchanged out-of-band. Implementations MAY send certificates other than the end-entity certificate (see Section 3.3 for discussion).
ローカルセキュリティポリシーの設定がキーイング材料がアウトオブバンドに交換しなければならないことを指定しない限りCERTREQを受信すると、実装がCERTREQに記載されている認証局に対応する少なくともエンドエンティティ証明書を送信することによって応答しなければなりません。実装は（議論については、3.3節を参照）エンドエンティティ証明書以外の証明書を送信することができます。
Note that, in the case where multiple end-entity certificates may be available that chain to different trust anchors, implementations SHOULD resort to local heuristics to determine which trust anchor is most appropriate to use for generating the CERTREQ. Such heuristics are out of the scope of this document.
複数のエンドエンティティ証明書は、異なるトラストアンカーへのチェーン利用可能である場合には、実装はCERTREQを生成するために使用することが最も適切であるトラストアンカーを決定するためにローカルヒューリスティックに頼るべきであることに留意されたいです。このような経験則は、この文書の範囲外です。
Implementations SHOULD generate CERTREQs where the Certificate Type is "X.509 Certificate - Signature" and where the Certification Authority field is not empty. However, implementations MAY generate CERTREQs with an empty Certification Authority field under special conditions. Although PKIX prohibits certificates with an empty Issuer field, there does exist a use case where doing so is appropriate, and carries special meaning in the IKE context. This has become a convention within the IKE interoperability tests and usage space, and so its use is specified, explained here for the sake of interoperability.
および認証局のフィールドが空ではありません - 証明書の種類は、「署名X.509証明書」です実装はCERTREQsを生成する必要があります。しかし、実装は特別な条件の下で、空の認証局のフィールドを持つCERTREQsを生成してもよいです。 PKIXは、空のIssuerフィールドで証明書を禁止しますが、そうすることが適切であり、かつIKEコンテキストで特別な意味を運ぶユースケースが存在しません。これは、IKE相互運用性テストと使用空間内で慣例となっている、などの使用が指定され、相互運用性のために、ここで説明しました。
USE CASE: Consider the rare case where you have a gateway with multiple policies for a large number of IKE peers: some of these peers are business partners, some are remote-access employees, some are teleworkers, some are branch offices, and/or the gateway may be simultaneously serving many customers (e.g., Virtual Routers). The total number of certificates, and corresponding trust anchors, is very high -- say, hundreds. Each of these policies is configured with one or more acceptable trust anchors, so that in total, the gateway has one hundred (100) trust anchors that could possibly used to authenticate an incoming connection. Assume that many of those connections originate from hosts/gateways with dynamically assigned IP addresses, so that the source IP of the IKE initiator is not known to the gateway, nor is the identity of the initiator (until it is revealed in Main Mode message 5). In IKE main mode message 4, the responder gateway will need to send a CERTREQ to the initiator. Given this example, the gateway will have no idea which of the hundred possible Certification Authorities to send in the CERTREQ. Sending all possible Certification Authorities will cause significant processing delays, bandwidth consumption, and UDP fragmentation, so this tactic is ruled out.
ユースケース：、いくつかの支店がいくつかは在宅勤務している、いくつかは、リモートアクセス従業員は、これらのピアのいくつかは、ビジネスパートナーである、および/または：あなたはIKEピアの数が多いため、複数のポリシーを持つゲートウェイを持っているまれなケースを考えてみましょうゲートウェイは、同時に多くの顧客（例えば、仮想ルーター）を提供することができます。証明書、および対応するトラストアンカーの総数は、非常に高いです - 何百、と言います。合計で、ゲートウェイは、おそらく着信接続を認証するために使用される可能性が百（100）トラストアンカーを有するように、これらのポリシーの各々は、一つ以上の許容されるトラストアンカーで構成されています。 IKE開始のソースIPは、ゲートウェイに知られないように、それらの接続の多くは、動的に割り当てられたIPアドレスを持つホスト/ゲートウェイを起源と仮定し、またそれは、メインモードメッセージ5で明らかにされるまで、イニシエータのアイデンティティは、（あります）。 IKEメインモードメッセージ4において、レスポンダゲートウェイがイニシエータにCERTREQを送信する必要があります。この例で考えると、ゲートウェイはCERTREQに送信するために百台の可能な証明機関の見当がつかないでしょう。すべての可能な証明機関を送信すると、重要な処理の遅延、帯域幅の消費、およびUDP断片化の原因となりますので、この戦術は除外されます。
In such a deployment, the responder gateway implementation should be able to do all it can to indicate a Certification Authority in the CERTREQ. This means the responder SHOULD first check SPD to see if it can match the source IP, and find some indication of which CA is associated with that IP. If this fails (because the source IP is not familiar, as in the case above), then the responder SHOULD have a configuration option specifying which CAs are the default CAs to indicate in CERTREQ during such ambiguous connections (e.g., send CERTREQ with these N CAs if there is an unknown source IP). If such a fall-back is not configured or impractical in a certain deployment scenario, then the responder implementation SHOULD have both of the following configuration options:
そのような展開では、応答者のゲートウェイの実装はCERTREQで認証局を示すために、それができるすべてを行うことができるはず。これは、応答者が最初にそれがソースIPと一致し、CAはそのIPに関連付けられているいくつかの兆候を見つけることができるかどうかを確認するためにSPDをチェックする必要がありますを意味します。 （ソースIPは、上記の場合のように、ではない慣れているので）これが失敗した場合、レスポンダはCAがCAは、このようなあいまいな接続中にCERTREQに示すために、既定されている設定オプションの指定を持っているべきである（例えば、これらのNとCERTREQを送信CAは、未知の送信元IPがある場合）。このようフォールバックは、特定の展開シナリオで構成されるか、または非現実的されていない場合は、応答者の実装は次の設定オプションの両方を持っている必要があります。
o send a CERTREQ payload with an empty Certification Authority field, or
O空の認証局のフィールドでCERTREQペイロードを送ったり、
o terminate the negotiation with an appropriate error message and audit log entry.
O適切なエラーメッセージと監査ログエントリとのネゴシエーションを終了します。
Receiving a CERTREQ payload with an empty Certification Authority field indicates that the recipient should send all/any end-entity certificates it has, regardless of the trust anchor. The initiator should be aware of what policy and which identity it will use, as it initiated the connection on a matched policy to begin with, and can thus respond with the appropriate certificate.
空の認証局のフィールドでCERTREQペイロードを受信すると、受信者はトラストアンカーに関係なく、すべての/それが持っている任意のエンドエンティティ証明書を送信する必要があることを示します。イニシエータは、それがそもそもマッチした政策への接続を開始したとして、それが使用するどのような政策とそのアイデンティティを認識しておく必要があり、したがって、適切な証明書で応答することができます。
If, after sending an empty CERTREQ in Main Mode message 4, a responder receives a certificate in message 5 that chains to a trust anchor that the responder either (a) does NOT support, or (b) was not configured for the policy (that policy was now able to be matched due to having the initiator's certificate present), this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
、メインモードメッセージ4で空CERTREQを送信した後、応答者は（そのトラストアンカーにチェーンが応答者がどちらかの（a）はサポートしていないこと、または（b）はポリシーのために設定されていないことを示すメッセージ5で証明書を受信した場合ポリシー）は今によるイニシエータの証明書本を有することに一致させることができた、これはエラーとして扱う必要があり、セキュリティアソシエーションの設定は中止されなければなりません。このイベントは、監査対象にすべきです。
Instead of sending an empty CERTREQ, the responder implementation MAY be configured to terminate the negotiation on the grounds of a conflict with locally configured security policy.
代わりに、空のCERTREQを送信、応答の実装は、ローカルに設定されたセキュリティポリシーとの競合を理由に交渉を終了するように構成されるかもしれません。
The decision of which to configure is a matter of local security policy; this document RECOMMENDS that both options be presented to administrators.
設定するの決定は、ローカルセキュリティポリシーの問題です。この文書では、両方のオプションは、管理者に提示することをお勧めします。
More examples and explanation of this issue are included in "More on Empty CERTREQs" (Appendix B).
より多くの例と、この問題の説明は「上の複数の空CERTREQs」（付録B）に含まれています。
Implementations MUST be able to deal with receiving CERTREQs with unsupported Certificate Types. Absent any recognized and supported CERTREQ types, implementations MAY treat them as if they are of a supported type with the Certification Authority field left empty, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing.
実装はサポートされていない証明書の種類とCERTREQsを受けるに対処できなければなりません。不在任意の認識とサポートCERTREQタイプ、彼らは認証局のフィールドでサポートされているタイプであるかのように、実装はそれらを扱うかもしれローカルポリシーに応じて、空のまま。 ISAKMP [2]のセクション5.10、「証明書要求ペイロード処理」、追加の処理を指定します。
Implementations MUST be able to deal with receiving CERTREQs with undecodable Certification Authority fields. Implementations MAY ignore such payloads, depending on local policy. ISAKMP specifies other actions which may be taken.
実装は、復号不能認証局のフィールドでCERTREQsを受けるに対処できなければなりません。実装はローカルポリシーに応じて、そのようなペイロードを無視するかもしれません。 ISAKMPをとることができる他のアクションを指定します。
Implementations MUST NOT assume that CERTREQs are ordered in any way.
実装はCERTREQsは、どのような方法で順序付けられていると仮定してはいけません。
Implementations SHOULD NOT send duplicate CERTREQs during an exchange.
実装は交換の間に重複CERTREQsを送るべきではありません。
When a peer's certificate keying material has been cached, an implementation can send a hint to the peer to elide some of the certificates the peer would normally include in the response. In addition to the normal set of CERTREQs that are sent specifying the trust anchors, an implementation MAY send CERTREQs specifying the relevant cached end-entity certificates. When sending these hints, it is still necessary to send the normal set of trust anchor CERTREQs because the hints do not sufficiently convey all of the information required by the peer. Specifically, either the peer may not support this optimization or there may be additional chains that could be used in this context but will not be if only the end-entity certificate is specified.
ピアの証明書鍵材料がキャッシュされている場合には、実装は、ピアが正常に応じて含まれる証明書の一部をElideのためにピアにヒントを送信することができます。トラストアンカーを指定して送信されますCERTREQsの通常のセットに加えて、実装は、関連するキャッシュされたエンドエンティティ証明書を指定するCERTREQsを送信することができます。これらのヒントを送信する際のヒントが十分ピアで必要なすべての情報を伝えていないので、トラストアンカーCERTREQsの通常のセットを送信することが必要です。具体的には、どちらかのピアはこの最適化をサポートしていないか、またはこれに関連して使用することができますが唯一のエンドエンティティ証明書が指定されている場合ではありません追加のチェーンがあるかもしれません。
No special processing is required on the part of the recipient of such a CERTREQ, and the end-entity certificates will still be sent. On the other hand, the recipient MAY elect to elide certificates based on receipt of such hints.
特別な処理は、このようなCERTREQの受信者の一部には必要とされない、エンドエンティティ証明書は、まだ送信されます。一方、受信者は、このようなヒントの受信に基づいて証明書をElideのために選ぶことができます。
CERTREQs must contain information that identifies a Certification Authority certificate, which results in the peer always sending at least the end-entity certificate. Always sending the end-entity certificate allows implementations to determine unambiguously when a new certificate is being used by a peer (perhaps because the previous certificate has just expired), which may result in a failure because a new intermediate CA certificate might not be available to validate the new end-entity certificate). Implementations that implement this optimization MUST recognize when the end-entity certificate has changed and respond to it by not performing this optimization if the exchange must be retried so that any missing keying materials will be sent during retry.
CERTREQsは、常に、少なくともエンドエンティティ証明書を送信するピアになり、認証局証明書を、特定する情報が含まれている必要があります。常にエンドエンティティ証明書を送信すると、新しい中間CA証明書が利用可能ではないかもしれないので、新しい証明書が故障につながる可能性がある、（以前の証明書は、単に有効期限が切れているなどの理由）ピアによって使用されている場合に実装が明確に決定することを可能にします）新しいエンドエンティティ証明書を検証します。この最適化を実装する実装は、エンドエンティティ証明書が変更されたときに認識し、不足しているキーイング材料が再試行中に送信されますように交換が再試行されなければならない場合は、この最適化を行わないことで、それに応じなければなりません。
Imagine that an IKEv1 implementation has previously received and cached the peer certificate chain TA->CA1->CA2->EE. If, during a subsequent exchange, this implementation sends a CERTREQ containing the Subject field in certificate TA, this implementation is requesting that the peer send at least three certificates: CA1, CA2, and EE. On the other hand, if this implementation also sends a CERTREQ containing the Subject field of CA2, the implementation is providing a hint that only one certificate needs to be sent: EE. Note that in this example, the fact that TA is a trust anchor should not be construed to imply that TA is a self-signed certificate.
IKEv1の実装が以前に受信し、ピア証明書チェーンTA-> CA1-> CA2-> EEをキャッシュしていることを想像してみてください。 CA1、CA2、およびEE：以降の交換時に、この実装は、証明書TAに件名フィールドを含むCERTREQを送信し、場合、この実装は、ピアは、少なくとも3つの証明書を送信することを要求しています。この実装はまた、CA2の件名フィールドを含むCERTREQを送信する場合一方、インプリメンテーションは、1つの証明書のみを送信する必要があるヒントを提供している：EEを。この例では、実際TAは、トラストアンカーは、TAが自己署名証明書であることを意味すると解釈されるべきではないということであることに注意してください。
The Certificate (CERT) Payload allows the peer to transmit a single certificate or CRL. Multiple certificates should be transmitted in multiple payloads. For backwards-compatibility reasons, implementations MAY send intermediate CA certificates in addition to the appropriate end-entity certificate(s), but SHOULD NOT send any CRLs, ARLs, or trust anchors. Exchanging trust anchors and especially CRLs and ARLs in IKE would increase the likelihood of UDP fragmentation, make the IKE exchange more complex, and consume additional network bandwidth.
証明書（CERT）ペイロードは、ピアが単一の証明書やCRLを送信することを可能にします。複数の証明書は、複数のペイロードで送信する必要があります。下位互換性のために、実装は、適切なエンドエンティティ証明書（複数可）に加えて、中間CA証明書を送信することができるが、任意のCRL、ARLs、又はトラストアンカーを送るべきではありません。 IKEに信頼アンカー、特にCRLとARLsを交換することは、UDPの断片化の可能性を高めるIKE交換をより複雑にし、追加のネットワーク帯域幅を消費することになります。
Note, however, that while the sender of the CERT payloads SHOULD NOT send any certificates it considers trust anchors, it's possible that the recipient may consider any given intermediate CA certificate to be a trust anchor. For instance, imagine the sender has the certificate chain TA1->CA1->EE1 while the recipient has the certificate chain TA2->EE2 where TA2=CA1. The sender is merely including an intermediate CA certificate, while the recipient receives a trust anchor.
CERTペイロードの送信者は、それが信頼アンカーを考慮したすべての証明書を送るべきではありませんが、それは受信者が任意の中間CA証明書が信頼アンカーであると考えている可能性がありますこと、しかし、注意してください。例えば、送信者が証明書チェーンを持つ想像TA1-> CA1-> EE1受信者が証明書チェーンTA2-> EE2 TA2 = CA1を有しています。受信者は、トラストアンカーを受けながら、送信者は、単に、中間CA証明書を含めています。
However, not all certificate forms that are legal in the PKIX certificate profile make sense in the context of IPsec. The issue of how to represent IKE-meaningful name-forms in a certificate is especially problematic. This document provides a profile for a subset of the PKIX certificate profile that makes sense for IKEv1/ ISAKMP.
ただし、PKIX証明書プロファイルに法的であるすべての証明書のフォームは、IPsecのコンテキストで意味を成しません。証明書でIKE-意味のある名前-形態を表す方法の問題は、特に問題となります。この文書では、IKEv1の/ ISAKMPのために理にかなっているPKIX証明書プロファイルのサブセットのプロファイルを提供します。
The Certificate Type field identifies to the peer the type of certificate keying materials that are included. ISAKMP defines 10 types of Certificate Data that can be sent and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
証明書の種類フィールドは、ピアに含まれている証明書キーイング材料のタイプを識別する。 ISAKMPを送信することができる証明書データの10種類を定義し、これらのタイプのための構文を指定します。このドキュメントの目的のために、唯一の次のタイプは関連しています。
o X.509 Certificate - Signature o Revocation Lists (CRL and ARL) o PKCS #7 wrapped X.509 certificate
O X.509証明書 - PKCS＃7 O失効リスト（CRLとARL）O署名X.509証明書を包ん
The use of the other types are out of the scope of this document:
他のタイプの使用は、この文書の範囲外です：
o X.509 Certificate - Key Exchange o PGP Certificate o DNS Signed Key o Kerberos Tokens o SPKI Certificate o X.509 Certificate Attribute
O X.509証明書 - PGP証明書O鍵交換X.509証明書の属性O SPKI証明書OのKerberosトークンO DNS署名キーO
This type specifies that Certificate Data contains a certificate used for signing.
このタイプは、証明書データが署名に使用する証明書が含まれていることを指定します。
These types specify that Certificate Data contains an X.509 CRL or ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for discussion.
これらのタイプは、証明書データがX.509のCRLまたはARLが含まれていることを指定します。これらのタイプは、IKEに送るべきではありません。議論のため、3.2.3項を参照してください。
This type defines a particular encoding, not a particular certificate type. Implementations SHOULD NOT generate CERTs that contain this Certificate Type. Implementations SHOULD accept CERTs that contain this Certificate Type because several implementations are known to generate them. Note that those implementations sometimes include entire certificate hierarchies inside a single CERT PKCS #7 payload, which violates the requirement specified in ISAKMP that this payload contain a single certificate.
このタイプは、特定の符号化ではなく、特定の証明書の種類を定義します。実装は、この証明書の種類が含まれているCERTSを生成すべきではありません。実装は、いくつかの実装がそれらを生成することが知られているので、この証明書の種類が含まれているCERTSを受け入れる必要があります。これらの実装は時々、このペイロードが単一の証明書を含むことがISAKMPで指定された要件を侵害する単一CERT PKCS＃7ペイロード、内部全体証明書階層を含むことに留意されたいです。
In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6.
IKEv1のメインモードでは、CERTペイロードはメッセージ5および6でなければなりません。
An implementation that does not receive any CERTREQs during an exchange SHOULD NOT send any CERT payloads, except when explicitly configured to proactively send CERT payloads in order to interoperate with non-compliant implementations that fail to send CERTREQs even when certificates are desired. In this case, an implementation MAY send the certificate chain (not including the trust anchor) associated with the end-entity certificate. This MUST NOT be the default behavior of implementations.
交換の間に任意のCERTREQsを受信しない実装は、明示的に積極的に証明書が必要な場合でも、CERTREQsを送信するために失敗し、非準拠の実装と相互運用するために、CERTペイロードを送信するように設定する場合を除き、任意のCERTペイロードを送るべきではありません。この場合、実装は、エンドエンティティ証明書に関連付けられている（トラストアンカーを含まない）証明書チェーンを送信することができます。これは、実装のデフォルトの動作にすることはできません。
Implementations whose local security policy configuration expects that a peer must receive certificates through out-of-band means SHOULD ignore any CERTREQ messages that are received. Such a condition has been known to occur due to non-compliant or buggy implementations.
そのローカルセキュリティポリシーの設定の実装は、ピアが受信されているすべてのCERTREQメッセージを無視すべきでアウトオブバンド手段を通じて証明書を受け取る必要があることを期待しています。そのような条件は、非準拠やバギー実装に起こることが知られています。
Implementations that receive CERTREQs from a peer that contain only unrecognized Certification Authorities MAY elect to terminate the exchange, in order to avoid unnecessary and potentially expensive cryptographic processing, denial-of-service (resource starvation) attacks.
のみ認識されていない証明機関が含まれているピアからCERTREQsを受け取る実装は不要と潜在的に高価な暗号処理、拒否のサービス（リソース不足）攻撃を避けるために、交換を終了することを選択するかもしれません。
In response to multiple CERTREQs that contain different Certification Authority identities, implementations MAY respond using an end-entity certificate which chains to a CA that matches any of the identities provided by the peer.
異なる認証局IDを含む複数のCERTREQsに応じて、実装はどのピアが提供するアイデンティティのいずれかと一致するCAにチェーンエンドエンティティ証明書を使用して応答することができます。
Implementations MAY elect to skip parsing or otherwise decoding a given set of CERTs if those same keying materials are available via some preferable means, such as the case where certificates from a previous exchange have been cached.
実装は、同じキーイング材料は、前回交換から証明書がキャッシュされている場合などのいくつかの好適な手段を介して利用可能である場合構文解析または他の方法で本命の所与のセットをデコードスキップすることを選択することができます。
Implementations SHOULD NOT send multiple end-entity certificates and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates.
実装は、複数のエンドエンティティ証明書を送るべきではなく、受信者が複数のエンドエンティティ証明書を反復処理することが期待されるべきではありません。
If multiple end-entity certificates are sent, they MUST have the same public key; otherwise, the responder does not know which key was used in the Main Mode message 5.
複数のエンドエンティティ証明書が送られている場合、それらは同じ公開鍵を持っている必要があります。そうでない場合、応答者は、メインモードメッセージ5で使用したキーを知りません。
Implementations MUST be able to deal with receiving CERTs with unrecognized or unsupported Certificate Types. Implementations MAY discard such payloads, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing.
実装は認識されていないか、サポートされていない証明書の種類と本命を受けるに対処できなければなりません。実装はローカルポリシーに応じて、そのようなペイロードを捨てるかもしれ。 ISAKMP [2]のセクション5.10、「証明書要求ペイロード処理」、追加の処理を指定します。
Implementations MUST be able to deal with receiving CERTs with undecodable Certificate Data fields. Implementations MAY discard such payloads, depending on local policy. ISAKMP specifies other actions that may be taken.
実装は、復号不能証明書データフィールドで本命を受けるに対処できなければなりません。実装はローカルポリシーに応じて、そのようなペイロードを捨てるかもしれ。 ISAKMPをとることができる他のアクションを指定します。
Implementations MUST NOT assume that CERTs are ordered in any way.
実装は、本命はどのような方法で順序付けられていると仮定してはいけません。
Implementations MUST support receiving multiple identical CERTs during an exchange.
実装は、交換中に複数の同一の本命を受けてサポートしなければなりません。
Implementations MUST be prepared to receive certificates and CRLs that are not relevant to the current exchange. Implementations MAY discard such extraneous certificates and CRLs.
実装は、現在の為替に関連していない証明書とCRLを受け取るために準備しなければなりません。実装は、このような余分な証明書とCRLを捨てるかもしれ。
Implementations MAY send certificates that are irrelevant to an exchange. One reason for including certificates that are irrelevant to an exchange is to minimize the threat of leaking identifying information in exchanges where CERT is not encrypted in IKEv1. It should be noted, however, that this probably provides rather poor protection against leaking the identity.
実装は為替に無関係な証明書を送信することができます。交換とは無関係である証明書を含む理由の一つは、CERTはIKEv1の中に暗号化されていない交換機に識別情報漏洩の脅威を最小限にすることです。おそらく、アイデンティティをリークに対してかなり貧弱な保護を提供すること、しかし、注意すべきです。
Another reason for including certificates that seem irrelevant to an exchange is that there may be two chains from the Certification Authority to the end entity, each of which is only valid with certain validation parameters (such as acceptable policies). Since the end-entity doesn't know which parameters the relying party is using, it should send the certificates needed for both chains (even if there's only one CERTREQ).
交換とは無関係に見える証明書を含むもう一つの理由は、（例えば、許容されるポリシーなど）は、特定の検証パラメータでのみ有効であり、各々がエンドエンティティに証明機関からの二つの鎖が存在し得るということです。エンドエンティティは、証明書利用者が使用してどのパラメータを知らないので、それは（一つだけCERTREQありますも）両方の鎖のために必要な証明書を送信する必要があります。
Implementations SHOULD NOT send multiple end-entity certificates and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates.
実装は、複数のエンドエンティティ証明書を送るべきではなく、受信者が複数のエンドエンティティ証明書を反復処理することが期待されるべきではありません。
Implementations SHOULD NOT send duplicate CERTs during an exchange. Such payloads should be suppressed.
実装は交換の間に重複CERTSを送るべきではありません。このようなペイロードが抑制されなければなりません。
When multiple CERTREQs are received that specify certification authorities within the end-entity certificate chain, implementations MAY send the shortest chain possible. However, implementations SHOULD always send the end-entity certificate. See Section 3.2.9.2 for more discussion of this optimization.
複数CERTREQsがエンドエンティティ証明書チェーン内のその指定証明機関を受信した場合、実装が可能な最短のチェーンを送信することができます。しかし、実装は常にエンドエンティティ証明書を送るべきです。この最適化のより多くの議論については、セクション3.2.9.2を参照してください。
Implementations MAY employ local means to recognize CERTs that have already been received and SHOULD discard these duplicate CERTs.
実装は、すでに受信されているCERTSを認識するためのローカルの手段を用いてもよいし、これらの重複CERTSを捨てます。
IKEv1 specifies the optional use of the Hash Payload to carry a pointer to a certificate in either of the Phase 1 public key encryption modes. This pointer is used by an implementation to locate the end-entity certificate that contains the public key that a peer should use for encrypting payloads during the exchange.
IKEv1のフェーズ1の公開鍵暗号化モードのいずれかで証明書へのポインタを運ぶためにハッシュペイロードの任意の使用を指定します。このポインタは、ピアが交換中にペイロードを暗号化するために使用すべき公開鍵を含むエンドエンティティ証明書を検索するために実装によって使用されます。
Implementations SHOULD include this payload whenever the public portion of the keypair has been placed in a certificate.
鍵ペアの公開部分は、証明書内に配置されているときはいつでも実装は、このペイロードを含むべきです。
The Peer Authorization Database (PAD) as described in RFC 4301 [14] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement, which are generally out of scope of this document. The PAD is intended to provide a link between the SPD and the security association management in protocols such as IKE. See RFC 4301 [14], Section 4.4.3 for more details.
ピア認証データベース（PAD）RFC 4301に記載されているように[14]は、IKEv2の中にIDペイロードの使用を記載し、ポリシーの詳細をより具体的に扱うサービスを提供することに加えて、ポリシーに同一の結合のための形式的なモデルを提供この文書の範囲外の一般的執行、。 PADはSPDとIKEなどのプロトコルのセキュリティ協会管理との間のリンクを提供することを意図しています。詳細については、RFC 4301 [14]、セクション4.4.3を参照してください。
Note that IKEv2 adds an optional IDr payload in the second exchange that the initiator may send to the responder in order to specify which of the responder's multiple identities should be used. The responder MAY choose to send an IDr in the third exchange that differs in type or content from the initiator-generated IDr. The initiator MUST be able to receive a responder-generated IDr that is a different type from the one the initiator generated.
IKEv2のイニシエータが使用されるべき応答の複数のアイデンティティのかを指定するためにレスポンダに送信することができる第二の交換に任意IDRペイロードを付加することに留意されたいです。レスポンダは、イニシエータが生成したIDRからタイプまたは内容が異なる第三の交換にIDRを送信するために選ぶかもしれ。イニシエータは、イニシエータが生成されたものとは異なるタイプであるレスポンダで生成IDRを受け取ることができなければなりません。
IKEv2 does not support Certificate Payload sizes over approximately 64K. See Section 3.2.3 for the problems this can cause.
IKEv2のは、以上の約64Kの証明書ペイロードサイズをサポートしていません。これが発生する可能性があります問題のために、3.2.3項を参照してください。
This ID type defines a request for the peer to send a hash and URL of its X.509 certificate, instead of the actual certificate itself. This is a particularly useful mechanism when the peer is a device with little memory and lower bandwidth, e.g., a mobile handset or consumer electronics device.
このIDタイプではなく、実際の証明書自体から、そのX.509証明書のハッシュとURLを送信するピアの要求を定義します。これは、ピアが少ないメモリおよび低帯域幅、例えば、携帯電話や家電機器と装置である場合に特に有用機構です。
If the IKEv2 implementation supports URL lookups, and prefers such a URL to receiving actual certificates, then the implementation will want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 [3], Section 3.10.1, "This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format)". If an HTTP_CERT_LOOKUP_SUPPORTED notification is sent, the sender MUST support the http scheme. See Section 4.3.1 for more discussion of HTTP_CERT_LOOKUP_SUPPORTED.
IKEv2の実装がURLルックアップをサポートしており、実際の証明書を受信したことに、このようなURLを好む場合は、実装がタイプHTTP_CERT_LOOKUP_SUPPORTEDの通知を送ることになるでしょう。 IKEv2から[3]、セクション3.10.1、「この通知はCERTREQペイロードを含むことができ、任意のメッセージに含まれる送信者がHTTPベースのURLに基づいて証明書をルックアップすることが可能である（したがって、おそらく好むであろうことを示しているかもしれませ「）という形式の証明書の仕様を受信します。 HTTP_CERT_LOOKUP_SUPPORTED通知が送信された場合、送信者は、httpスキームをサポートしなければなりません。 HTTP_CERT_LOOKUP_SUPPORTEDのより多くの議論については、セクション4.3.1を参照してください。
In IKEv2, the CERTREQ payload must be in messages 2 and 3. Note that in IKEv2, it is possible to have one side authenticating with certificates while the other side authenticates with pre-shared keys.
他方の側が事前共有キーで認証している間のIKEv2において、CERTREQペイロードは、メッセージ2とIKEv2ので、証明書を持つ片側認証を有することが可能であることに留意されたいでなければなりません。
This type specifies that Certificate Data contains a hash and the URL to a repository where an X.509 certificate can be retrieved.
このタイプは、証明書データは、ハッシュとX.509証明書が取得できるリポジトリへのURLが含まれていることを指定します。
An implementation that sends an HTTP_CERT_LOOKUP_SUPPORTED notification MUST support the http scheme and MAY support the ftp scheme, and MUST NOT require any specific form of the url-path, and it SHOULD support having user-name, password, and port parts in the URL. The following are examples of mandatory forms:
HTTP_CERT_LOOKUP_SUPPORTED通知を送信する実装は、httpスキームをサポートしなければならないとftpスキームをサポートすることができ、URLパスのいずれかの特定のフォームを要求してはなりません、そして、それはURLにユーザー名、パスワード、およびポート部を有するサポートすべきです。次の必須の形式の例を以下に示します。
o http://certs.example.com/certificate.cer o http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400 o http://certs.example.com/%0a/../foo/bar/zappa
http://certs.example.com/certificate.cer http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400ます。http：// certs.example.com/%0a/../foo/bar/zappa
while the following is an example of a form that SHOULD be supported:
以下ながらは、サポートされるべきである形態の一例です。
o http://user:password@certs.example.com:8888/certificate.cer
Oます。http：//ユーザー：password@certs.example.com：8888 / certificate.cer
FTP MAY be supported, and if it is, the following is an example of the ftp scheme that MUST be supported:
FTPをサポートすることができる、それがある場合は、以下をサポートしなければなりませんFTP方式の例であります：
o ftp://ftp.example.com/pub/certificate.cer
お ｆｔｐ：／／ｆｔｐ。えぁｍｐぇ。こｍ／ぷｂ／せｒちふぃかて。せｒ
In IKEv2, the CERT payload MUST be in messages 3 and 4. Note that in IKEv2, it is possible to have one side authenticating with certificates while the other side authenticates with pre-shared keys.
他方の側が事前共有キーで認証している間のIKEv2では、CERTペイロードは、メッセージ3とのIKEv2で、証明書を有する片側認証を有することが可能であること4.注意していなければなりません。
For IKEv2, implementations MUST NOT assume that any but the first CERT is ordered in any way. IKEv2 specifies that the first CERT contain an end-entity certificate that can be used to authenticate the peer.
IKEv2のために、実装は最初CERTが、いずれかが何らかの方法で順序付けられていると仮定してはいけません。 IKEv2の最初CERTがピアを認証するために使用することができるエンドエンティティ証明書を含むことを指定します。
Except where specifically stated in this document, implementations MUST conform to the requirements of the PKIX [5] certificate profile.
具体的には、この文書に記載されている場合を除いて、実装は、PKIX [5]証明書プロファイルの要件に適合しなければなりません。
Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order to permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check.
証明書でIKEとIPsecを使用しているユーザーは、多くの場合、それらに利用可能なCAの能力をほとんど制御を持っていました。この仕様の実装は、柔軟性のないおよび/または非準拠のCAでの使用を可能にするために本明細書で必要とされるチェックを無効にするために、コンフィギュレーションノブを含むことができます。しかし、証明書上のすべてのチェックは、システム全体のセキュリティに関わる具体的な理由のために存在します。したがって、すべてのチェックがデフォルトで有効にする必要があります。管理者とユーザーは様々なチェックのためのセキュリティ目的を理解し、セキュリティチェックを無効にすることで失われるかについては明らかであるべきです。
Although PKIX states that "implementations SHOULD be prepared to accept any version certificate", in practice, this profile requires certain extensions that necessitate the use of Version 3 certificates for all but self-signed certificates used as trust anchors. Implementations that conform to this document MAY therefore reject Version 1 and Version 2 certificates in all other cases.
PKIXは、実際には、「実装は任意のバージョンの証明書を受け入れるために準備されるべきである」と述べているが、このプロファイルは、信頼アンカーとして使用する自己署名証明書が、すべてのバージョン3つの証明書を使用する必要が特定の拡張子が必要です。この文書に準拠する実装は、したがって、他のすべての場合にはバージョン1とバージョン2の証明書を拒否することがあります。
Certification Authority implementations MUST be able to create certificates with Subject fields with at least the following four attributes: CN, C, O, and OU. Implementations MAY support other Subject attributes as well. The contents of these attributes SHOULD be configurable on a certificate-by-certificate basis, as these fields will likely be used by IKE implementations to match SPD policy.
CN、C、O、およびOU：認証機関の実装には、少なくとも次の4つの属性と件名フィールドを持つ証明書を作成できなければなりません。実装は、他の件名が同様に属性をサポートするかもしれません。これらのフィールドがありそうSPDポリシーに一致するようにIKEの実装で使用されるように、これらの属性の内容は、証明書によって証明書毎に設定可能であるべきです。
See Section 3.1.5 for details on how IKE implementations need to be able to process Subject field attributes for SPD policy lookup.
IKEの実装はSPDポリシー検索のための件名フィールド属性を処理できるようにする必要がある方法の詳細については、3.1.5項を参照してください。
IKE Implementations MUST accept certificates that contain an empty Subject field, as specified in the PKIX certificate profile. Identity information in such certificates will be contained entirely in the SubjectAltName extension.
IKE実装は、PKIX証明書プロファイルで指定され、空の件名フィールドが含まれている証明書を受け入れなければなりません。そのような証明書のID情報がsubjectAltName拡張に完全に含まれることになります。
Implementations that desire to place host names that are not intended to be processed by recipients as FQDNs (for instance "Gateway Router") in the Subject MUST use the commonName attribute.
件名に（例えば「ゲートウェイルータ」）のFQDNと受信者によって処理されるように意図されていないホスト名を配置することを望む実装はcommonNameの属性を使用しなければなりません。
As specified in the PKIX certificate profile, implementations MUST NOT populate X.500 distinguished names with the emailAddress attribute.
PKIX証明書プロファイルで指定されているように、実装はEMAILADDRESS属性でX.500識別名を移入してはなりません。
Conforming IKE implementations MUST recognize extensions that must or may be marked critical according to this specification. These extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
IKEの実装を準拠してか、この仕様に応じて、重要なマークされる必要があります拡張子を認識しなければなりません。これらの拡張機能は、次のとおりのKeyUsage、のSubjectAltName、および基本制約。
Certification Authority implementations SHOULD generate certificates such that the extension criticality bits are set in accordance with the PKIX certificate profile and this document. With respect to compliance with the PKIX certificate profile, IKE implementations processing certificates MAY ignore the value of the criticality bit for extensions that are supported by that implementation, but MUST support the criticality bit for extensions that are not supported by that implementation. That is, a relying party SHOULD processes all the extensions it is aware of whether the bit is true or false -- the bit says what happens when a relying party cannot process an extension.
証明機関の実装は、拡張臨界ビットはPKIX証明書プロファイルとこの文書に応じて設定されるように証明書を生成する必要があります。 PKIX証明書プロファイルの遵守に関しては、IKEの実装処理証明書は、その実装によってサポートされている機能拡張のための臨界ビットの値を無視することもできますが、実装によってサポートされていない拡張のための臨界ビットをサポートしなければなりません。ビットは、証明書利用者は、拡張子を処理できないときに何が起こるかと言う - それは、依拠当事者が、それはビットが真か偽かを認識しているすべての拡張機能を処理すべきである、です。
implements bit in cert PKIX mandate behavior
------------------------------------------------------
yes true true ok
yes true false ok or reject
yes false true ok or reject
yes false false ok
no true true reject
no true false reject
no false true reject
no false false ok
Implementations SHOULD NOT assume support for the AuthorityKeyIdentifier or SubjectKeyIdentifier extensions. Thus, Certification Authority implementations should not generate certificate hierarchies that are overly complex to process in the absence of these extensions, such as those that require possibly verifying a signature against a large number of similarly named CA certificates in order to find the CA certificate that contains the key that was used to generate the signature.
実装はAuthorityKeyIdentifierまたはSubjectKeyIdentifier拡張のサポートを仮定するべきではありません。このように、認証局の実装は、そのような可能性が含まれているCA証明書を見つけるために同様の名前のCA証明書を多数に対して署名を検証する必要があるものとして、これらの拡張機能が存在しない状態で処理することが過度に複雑で、証明書の階層を、生成するべきではありません署名を生成するために使用されたキー。
IKE uses an end-entity certificate in the authentication process. The end-entity certificate may be used for multiple applications. As such, the CA can impose some constraints on the manner that a public key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU) extensions apply in this situation.
IKEは、認証プロセスにおけるエンドエンティティ証明書を使用しています。エンドエンティティ証明書は、複数のアプリケーションに使用することができます。そのため、CAは、公開鍵が使用されるべきであるという方法で、いくつかの制約を課すことができます。 KeyUsage（KU）とextendedKeyUsageの（EKU）拡張は、このような状況で適用されます。
Since we are talking about using the public key to validate a signature, if the KeyUsage extension is present, then at least one of the digitalSignature or the nonRepudiation bits in the KeyUsage extension MUST be set (both can be set as well). It is also fine if other KeyUsage bits are set.
我々は、署名を検証する公開鍵を使用して話しているので、KeyUsage拡張が存在する場合、次いで、デジタル署名またはKeyUsage拡張における否認防止ビットの少なくとも一つが（両方とも同様に設定することができる）を設定しなければなりません。他のKeyUsageビットが設定されている場合も結構です。
A summary of the logic flow for peer cert validation follows:
ピア証明書の検証のための論理フローの概要は、次のとおりです。
o If no KU extension, continue.
無KU延長した場合、O、続けます。
o If KU present and doesn't mention digitalSignature or nonRepudiation (both, in addition to other KUs, is also fine), reject cert.
O KU存在すると言及していないデジタル署名または否認防止（その両方が、他のホークスに加えて、も結構です）場合は、証明書を拒否します。
o If none of the above, continue.
上記のいずれも、継続しない場合には、O。
The PKIX certificate profile recommends against the use of this extension. The PrivateKeyUsageExtension is intended to be used when signatures will need to be verified long past the time when signatures using the private keypair may be generated. Since IKE security associations (SAs) are short-lived relative to the intended use of this extension in addition to the fact that each signature is validated only a single time, the usefulness of this extension in the context of IKE is unclear. Therefore, Certification Authority implementations MUST NOT generate certificates that contain the PrivateKeyUsagePeriod extension. If an IKE implementation receives a certificate with this set, it SHOULD ignore it.
PKIX証明書プロファイルは、この拡張機能を使用しないことを推奨します。 PrivateKeyUsageExtensionは署名がプライベート鍵ペアを使用して署名を生成することができる時間を過ぎて長い検証する必要があるときに使用されることを意図しています。 IKEセキュリティアソシエーション（SA）は短命相対各署名は一度だけ検証されるという事実に加えて、この拡張の使用目的にしているので、IKEの文脈におけるこの拡張の有用性は不明です。そのため、認証局の実装はPrivateKeyUsagePeriod拡張を含む証明書を生成してはなりません。 IKEの実装はこのセットで証明書を受信した場合、それはそれを無視すべきです。
Many IKE implementations do not currently provide support for the CertificatePolicies extension. Therefore, Certification Authority implementations that generate certificates that contain this extension SHOULD NOT mark the extension as critical. As is the case with all certificate extensions, a relying party receiving this extension but who can process the extension SHOULD NOT reject the certificate because it contains the extension.
多くのIKE実装は、現在CertificatePolicies拡張のサポートを提供していません。したがって、この拡張を含む証明書を生成する認証局の実装は、重要として拡張子をマークすべきではありません。すべての証明書の拡張機能と同様に、証明書利用者は、この拡張子を受けたが、誰それが拡張子が含まれているため、証明書を拒否すべきではない拡張子を処理することができます。
Many IKE implementations do not support the PolicyMappings extension. Therefore, implementations that generate certificates that contain this extension SHOULD NOT mark the extension as critical.
多くのIKE実装はPolicyMappings拡張をサポートしていません。したがって、この拡張機能が含まれている証明書を生成する実装が重要と拡張子をマークすべきではありません。
Deployments that intend to use an ID of FQDN, USER_FQDN, IPV4_ADDR, or IPV6_ADDR MUST issue certificates with the corresponding SubjectAltName fields populated with the same data. Implementations SHOULD generate only the following GeneralName choices in the SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/ IKEv2 Identification Payload types: rfc822Name, dNSName, or iPAddress. Although it is possible to specify any GeneralName choice in the Identification Payload by using the ID_DER_ASN1_GN ID type, implementations SHOULD NOT assume support for such functionality, and SHOULD NOT generate certificates that do so.
FQDN、USER_FQDN、IPV4_ADDR、又はIPV6_ADDRのIDを使用する展開では、同じデータが取り込ま対応のSubjectAltNameフィールドを持つ証明書を発行しなければなりません。 rfc822Nameで、のdNSName、またはIPアドレス：これらの選択肢は法的のIKEv1 / ISAKMP / IKEv2のIDペイロードタイプにマップとして実装は、subjectAltName拡張にのみ、以下のGeneralNameの選択肢を生成する必要があります。それはID_DER_ASN1_GN IDタイプを使用してIDペイロード内の任意のGeneralNameの選択を指定することも可能ですが、実装は、そのような機能のサポートを仮定するべきではありませんし、そうする証明書を生成するべきではありません。
If the IKE ID type is FQDN, then this field MUST contain a fully qualified domain name. If the IKE ID type is FQDN, then the dNSName field MUST match its contents. Implementations MUST NOT generate names that contain wildcards. Implementations MAY treat certificates that contain wildcards in this field as syntactically invalid.
IKE IDタイプがFQDNである場合、このフィールドは、完全修飾ドメイン名を含まなければなりません。 IKE IDタイプがFQDNである場合には、のdNSNameフィールドは、その内容を一致させる必要があります。実装はワイルドカードを含む名前を生成してはなりません。実装は、構文的に無効であると、このフィールドにワイルドカードを含む証明書を扱うかもしれ。
Although this field is in the form of an FQDN, IKE implementations SHOULD NOT assume that this field contains an FQDN that will resolve via the DNS, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document. Implementations SHOULD NOT treat the failure to resolve as an error.
このフィールドは、FQDNの形式であるが、IKEの実装は、このフィールドには、これは、いくつかのアウトオブバンドメカニズムによって知られていない限り、DNS経由で解決しますFQDNが含まれていることを仮定するべきではありません。このようなメカニズムは、この文書の範囲外です。実装はエラーと解決に失敗したことを扱うべきではありません。
If the IKE ID type is IPV4_ADDR or IPV6_ADDR, then the iPAddress field MUST match its contents. Note that although PKIX permits CIDR [15] notation in the "Name Constraints" extension, the PKIX certificate profile explicitly prohibits using CIDR notation for conveying identity information. In other words, the CIDR notation MUST NOT be used in the SubjectAltName extension.
IKE IDタイプがIPV4_ADDRまたはIPV6_ADDRであれば、IPアドレスフィールドには、その内容を一致させる必要があります。 PKIXは、「名前制約」拡張子でCIDR [15]の表記を可能にするが、PKIX証明書プロファイルは、明示的に識別情報を搬送するためCIDR表記法を使用して禁止することに留意されたいです。換言すれば、CIDR表記はsubjectAltName拡張に使用してはいけません。
If the IKE ID type is USER_FQDN, then the rfc822Name field MUST match its contents. Although this field is in the form of an Internet mail address, IKE implementations SHOULD NOT assume that this field contains a valid email address, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document.
IKE IDタイプがUSER_FQDNの場合は、rfc822Nameでのフィールドは、その内容と一致しなければなりません。このフィールドは、インターネットメールアドレスの形式であるが、これは一部の帯域外のメカニズムによって知られていない限り、IKEの実装は、このフィールドは有効な電子メールアドレスが含まれていることを仮定するべきではありません。このようなメカニズムは、この文書の範囲外です。
Certification Authority implementations SHOULD NOT assume that other implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users.
認証局の実装は、他の実装がIssuerAltName拡張をサポートすることを仮定するべきではありませんし、特にこの拡張に含まれている情報は、エンドユーザーに表示されると仮定してはいけません。
The SubjectDirectoryAttributes extension is intended to convey identification attributes of the subject. IKE implementations MAY ignore this extension when it is marked non-critical, as the PKIX certificate profile mandates.
SubjectDirectoryAttributes拡張は、対象の識別属性を伝えることを意図しています。それはPKIX証明書プロファイルの義務として、非クリティカルマークされている場合、IKEの実装は、この拡張機能を無視してもよいです。
The PKIX certificate profile mandates that CA certificates contain this extension and that it be marked critical. IKE implementations SHOULD reject CA certificates that do not contain this extension. For backwards compatibility, implementations may accept such certificates if explicitly configured to do so, but the default for this setting MUST be to reject such certificates.
CA証明書は、この拡張機能が含まれており、それが重要なマークされているPKIX証明書プロファイルの義務。 IKEの実装は、この拡張機能が含まれていないCA証明書を拒否すべきです。後方互換性のために、明示的にそうするように構成されている場合の実装は、このような証明書を受け入れるかもしれませんが、この設定のデフォルトでは、このような証明書を拒否することでなければなりません。
Many IKE implementations do not support the NameConstraints extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
多くのIKE実装はNameConstraints拡張情報をサポートしていません。 、IKEのための最大の相互運用性に関心のある認証局の実装は、この拡張を含む証明書を生成するべきではありませんが存在する場合、この拡張機能は、重要マークを付けることPKIX証明書プロファイル義務付けて以来。
Many IKE implementations do not support the PolicyConstraints extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
多くのIKE実装はPolicyConstraintsの拡張をサポートしていません。 、IKEのための最大の相互運用性に関心のある認証局の実装は、この拡張を含む証明書を生成するべきではありませんが存在する場合、この拡張機能は、重要マークを付けることPKIX証明書プロファイル義務付けて以来。
The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in certificates for use with IKE. Note that there were three IPsec-related object identifiers in EKU that were assigned in 1999. The semantics of these values were never clearly defined. The use of these three EKU values in IKE/IPsec is obsolete and explicitly deprecated by this specification. CAs SHOULD NOT issue certificates for use in IKE with them. (For historical reference only, those values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-ipsecUser.)
CAは、IKEで使用するための証明書でextendedKeyUsageの（EKU）拡張子を含めるべきではありません。これらの値の意味が明確に定義されなかった1999年に割り当てられていたEKU中3のIPsec関連のオブジェクト識別子があったことに注意してください。 IKE / IPsecの中にこれらの3つのEKU値の使用が廃止され、明示的にこの仕様で廃止予定です。 CAは、彼らとIKEで使用するための証明書を発行するべきではありません。 （歴史的な基準についてのみ、これらの値は、ID-KP-ipsecEndSystem、ID-KP-ipsecTunnel、及びID-KP-ipsecUserでした。）
The CA SHOULD NOT mark the EKU extension in certificates for use with IKE and one or more other applications. Nevertheless, this document defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a certificate's use:
CAは、IKEと1つの以上の他のアプリケーションで使用するための証明書でEKU拡張子をマークすべきではありません。それにもかかわらず、このドキュメントでは、証明書の使用を制限するために使用することができることをextendedKeyUsageのkeyPurposeIDが定義されています。
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
where id-kp is defined in RFC 3280 [5]. If a certificate is intended to be used with both IKE and other applications, and one of the other applications requires use of an EKU value, then such certificates MUST contain either the keyPurposeID id-kp-ipsecIKE or anyExtendedKeyUsage [5], as well as the keyPurposeID values associated with the other applications. Similarly, if a CA issues multiple otherwise-similar certificates for multiple applications including IKE, and it is intended that the IKE certificate NOT be used with another application, the IKE certificate MAY contain an EKU extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its use with the other application. Recall, however, that EKU extensions in certificates meant for use in IKE are NOT RECOMMENDED.
ID-KPは、RFC 3280で定義される[5]。証明書は、IKEと他のアプリケーションの両方で使用されることが意図され、そして他の用途の一つはEKU値の使用を必要とする、そのような証明書は、同様に、[5] keyPurposeID ID-KP-ipsecIKE又はanyExtendedKeyUsageのいずれかを含有する必要がある場合keyPurposeID値は、他のアプリケーションに関連付けられています。同様に、CAは、IKEを含む複数のアプリケーション用に複数のそれ以外の場合は、同様の証明書を発行し、IKE証明書は、他のアプリケーションで使用できません、IKE証明書はにID-KP-ipsecIKEのkeyPurposeIDをリストEKU拡張を含むことが意図されている場合他のアプリケーションでの使用を阻止。リコール、しかし、証明書でEKU拡張がIKEでの使用を意図することを推奨されていません。
Conforming IKE implementations are not required to support EKU. If a critical EKU extension appears in a certificate and EKU is not supported by the implementation, then RFC 3280 requires that the certificate be rejected. Implementations that do support EKU MUST support the following logic for certificate validation: o If no EKU extension, continue.
準拠IKE実装がEKUをサポートする必要はありません。重要なEKU拡張が証明書に表示され、EKUが実装によってサポートされていない場合は、RFC 3280には、証明書が拒否されている必要があります。 EKUをサポートしない実装は、証明書の検証のために、次のロジックをサポートしなければならない：なしEKU拡張であればO、続けます。
o If EKU present AND contains either id-kp-ipsecIKE or anyExtendedKeyUsage, continue.
O EKUの存在とID-KP-ipsecIKEまたはanyExtendedKeyUsageのいずれかが含まれている場合は、引き続き。
o Otherwise, reject cert.
Oそれ以外の場合は、証明書を拒否します。
Because this document deprecates the sending of CRLs in-band, the use of CRLDistributionPoints (CDP) becomes very important if CRLs are used for revocation checking (as opposed to, say, Online Certificate Status Protocol - OCSP [16]). The IPsec peer either needs to have a URL for a CRL written into its local configuration, or it needs to learn it from CDP. Therefore, Certification Authority implementations SHOULD issue certificates with a populated CDP.
この文書は、帯域内のCRLの送信を廃止されたためCRLは（ - OCSP [16]、たとえば、オンライン証明書状態プロトコルではなく）失効チェックのために使用されている場合は、CRLDistributionPoints（CDP）を使用することは非常に重要になってきます。 IPsecピアは、そのローカルコンフィギュレーションに書き込まれたCRLのURLを持っている必要がありますか、それはCDPからそれを学ぶ必要があります。そのため、認証局の実装では、人口のCDPとの証明書を発行する必要があります。
Failure to validate the CRLDistributionPoints/ IssuingDistributionPoint pair can result in CRL substitution where an entity knowingly substitutes a known good CRL from a different distribution point for the CRL that is supposed to be used, which would show the entity as revoked. IKE implementations MUST support validating that the contents of CRLDistributionPoints match those of the IssuingDistributionPoint to prevent CRL substitution when the issuing CA is using them. At least one CA is known to default to this type of CRL use. See Section 5.2.2.5 for more information.
CRLDistributionPoints / IssuingDistributionPointペアを検証する障害は、企業が故意失効などのエンティティを示すことになる、使用が想定されているCRLの異なる配布ポイントから既知の良好なCRLを代入CRL置換をもたらすことができます。 IKEの実装はCRLDistributionPointsの内容は、発行元CAがそれらを使用しているときCRL置換を防ぐためにIssuingDistributionPointのものと一致することを検証しサポートしなければなりません。少なくとも一つのCAは、CRLの使用のこのタイプをデフォルトにすることが知られています。詳細については、セクション5.2.2.5を参照してください。
CDPs SHOULD be "resolvable". Several non-compliant Certification Authority implementations are well known for including unresolvable CDPs like http://localhost/path_to_CRL and http:///path_to_CRL that are equivalent to failing to include the CDP extension in the certificate.
CDPは、「解決可能」であるべきです。 // localhost /をpath_to_CRLとします。http：/// path_to_CRL証明書にCDP拡張子を含めることができないと同等であり、いくつかの非準拠の認証局の実装がうまく解決できないHTTPのようなのCDPなどのために知られています。
See the IETF IPR Web page for CRLDistributionPoints intellectual property rights (IPR) information. Note that both the CRLDistributionPoints and IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED by the PKIX certificate profile, so there is no requirement to license any IPR.
CRLDistributionPoints知的財産権（IPR）の情報のためのIETF IPRのWebページを参照してください。 CRLDistributionPointsとIssuingDistributionPoint拡張の両方が推奨されていることに注意してくださいが、PKIX証明書プロファイルが必要としないので、任意の知的財産権をライセンスする必要はありません。
Many IKE implementations do not support the InhibitAnyPolicy extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
多くのIKE実装はInhibitAnyPolicy拡張をサポートしていません。 、IKEのための最大の相互運用性に関心のある認証局の実装は、この拡張を含む証明書を生成するべきではありませんが存在する場合、この拡張機能は、重要マークを付けることPKIX証明書プロファイル義務付けて以来。
IKE implementations MUST NOT assume that the FreshestCRL extension will exist in peer certificates. Note that most IKE implementations do not support delta CRLs.
IKEの実装はFreshestCRL拡張子がピアの証明書に存在すると仮定してはいけません。ほとんどのIKEの実装は、デルタCRLをサポートしていないことに注意してください。
The PKIX certificate profile defines the AuthorityInfoAccess extension, which is used to indicate "how to access CA information and services for the issuer of the certificate in which the extension appears". Because this document deprecates the sending of CRLs in-band, the use of AuthorityInfoAccess (AIA) becomes very important if OCSP [16] is to be used for revocation checking (as opposed to CRLs). The IPsec peer either needs to have a URI for the OCSP query written into its local configuration, or it needs to learn it from AIA. Therefore, implementations SHOULD support this extension, especially if OCSP will be used.
PKIX証明書プロファイルは、「拡張が現れる証明書の発行者のためのCA情報とサービスにアクセスする方法」を示すために使用されるAuthorityInfoAccess拡張を定義します。この文書は、帯域内のCRLの送信を廃止されたためOCSP [16]（CRLのとは対照的に）失効チェックのために使用される場合、AuthorityInfoAccess（AIA）を使用することは非常に重要となります。 IPsecピアは、そのローカルコンフィギュレーションに書き込まれたOCSPクエリのURIを持っている必要がありますか、それはAIAからそれを学ぶ必要があります。そのため、実装はOCSPが使用される場合は特に、この拡張機能をサポートする必要があります。
The PKIX certificate profile defines the SubjectInfoAccess certificate extension, which is used to indicate "how to access information and services for the subject of the certificate in which the extension appears". This extension has no known use in the context of IPsec. Conformant IKE implementations SHOULD ignore this extension when present.
PKIX証明書プロファイルは、「拡張が現れる証明書のサブジェクトのための情報やサービスにアクセスする方法」を示すために使用されるSubjectInfoAccess証明書拡張を定義します。この拡張は、IPsecのコンテキストには、既知の使用を持っていません。存在する場合に準拠IKEの実装は、この拡張機能を無視します。
When validating certificates, IKE implementations MUST make use of certificate revocation information, and SHOULD support such revocation information in the form of CRLs, unless non-CRL revocation information is known to be the only method for transmitting this information. Deployments that intend to use CRLs for revocation SHOULD populate the CRLDistributionPoints extension. Therefore, Certification Authority implementations MUST support issuing certificates with this field populated. IKE implementations MAY provide a configuration option to disable use of certain types of revocation information, but that option MUST be off by default. Such an option is often valuable in lab testing environments.
証明書を検証するとき、IKE実装は、証明書失効情報を利用しなければならない、および非CRL失効情報は、この情報を送信するための唯一の方法であることが知られていない限り、のCRLの形でそのような失効情報をサポートしなければなりません。失効のためのCRLを使用する展開ではCRLDistributionPoints拡張子を取り込むべきです。そのため、認証局の実装では、人口のこの分野での証明書を発行してサポートしなければなりません。 IKEの実装は失効情報の特定の種類の使用を無効にする設定オプションを提供することができるが、そのオプションはデフォルトでオフでなければなりません。このようなオプションは、多くの場合、ラボのテスト環境では貴重です。
IKE implementations that support multiple sources of obtaining certificate revocation information MUST act conservatively when the information provided by these sources is inconsistent: when a certificate is reported as revoked by one trusted source, the certificate MUST be considered revoked.
これらのソースによって提供された情報が矛盾している場合、証明書の失効情報を取得する複数のソースをサポートするIKE実装は、保存的に行動しなければならない：一個の信頼できるソースによって取り消されるよう証明書が報告されている場合、証明書は失効とみなされなければなりません。
Certification Authority implementations SHOULD NOT assume that IKE implementations support the AuthorityKeyIdentifier extension, and thus should not generate certificate hierarchies which are overly complex to process in the absence of this extension, such as those that require possibly verifying a signature against a large number of similarly named CA certificates in order to find the CA certificate which contains the key that was used to generate the signature.
証明機関の実装は、IKE実装がAuthorityKeyIdentifier拡張をサポートすると仮定してはならず、従ってそのような可能性が類似した名前の多数に対する署名を検証する必要があるものとして、この拡張の非存在下で処理する過度に複雑であり、証明書階層を生成するべきではありません署名を生成するために使用されたキーが含まれているCA証明書を見つけるためにCA証明書。
Certification Authority implementations SHOULD NOT assume that IKE implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users.
認証局の実装は、IKEの実装はIssuerAltName拡張をサポートすることを仮定するべきではありませんし、特にこの拡張に含まれている情報は、エンドユーザーに表示されると仮定してはいけません。
As stated in the PKIX certificate profile, all issuers MUST include this extension in all CRLs.
PKIX証明書プロファイルに述べたように、すべての発行体は、すべてのCRL中にこの拡張を含まなければなりません。
IKE implementations that do not support delta CRLs MUST reject CRLs that contain the DeltaCRLIndicator (which MUST be marked critical according to the PKIX certificate profile) and MUST make use of a base CRL if it is available. Such implementations MUST ensure that a delta CRL does not "overwrite" a base CRL, for instance, in the keying material database.
デルタCRLをサポートしていないIKEの実装は、（PKIX証明書プロファイルに応じて重要マークを付ける必要があります）DeltaCRLIndicatorが含まれているCRLを拒絶しなければなりませんし、それが利用可能な場合、ベースCRLを使用する必要があります。そのような実装は、デルタCRLは、鍵材料データベースに、例えば、ベースCRLを「上書き」しないことを保証しなければなりません。
Since some IKE implementations that do not support delta CRLs may behave incorrectly or insecurely when presented with delta CRLs, administrators and deployers should consider whether issuing delta CRLs increases security before issuing such CRLs. And, if all the elements in the VPN and PKI systems do not adequately support Delta CRLs, then their use should be questioned.
デルタCRLのを提示する場合、デルタCRLをサポートしていないいくつかのIKE実装が間違ってまたは安全でない動作をする場合がありますので、管理者やデプロイヤが発行するデルタCRLは、このようなCRLを発行する前に、セキュリティを増大させるかどうかを検討すべきです。 VPNとPKIシステム内のすべての要素が適切にデルタCRLをサポートしていない場合は、その後、それらの使用は疑問視されなければなりません。
The editors are aware of several implementations that behave in an incorrect or insecure manner when presented with delta CRLs. See Appendix A for a description of the issue. Therefore, this specification RECOMMENDS NOT issuing delta CRLs at this time. On the other hand, failure to issue delta CRLs may expose a larger window of vulnerability if a full CRL is not issued as often as delta CRLs would be. See the Security Considerations section of the PKIX [5] certificate profile for additional discussion. Implementers as well as administrators are encouraged to consider these issues.
編集者は、デルタCRLのを提示すると、誤ったか、安全でない方法で動作し、いくつかの実装を認識しています。問題の説明については、付録Aを参照してください。したがって、この仕様は、この時点でデルタCRLを発行しないことをお勧めします。フルCRLは、できるだけ頻繁にデルタCRLはだろうとして発行されていない場合一方、デルタCRLを発行する障害は、脆弱性の大きな窓を露出させることができます。追加の議論のためのPKIX [5]証明書プロファイルのセキュリティの考慮事項のセクションを参照してください。実装者だけでなく、管理者は、これらの問題を考慮することが奨励されています。
A CA that is using CRLDistributionPoints may do so to provide many "small" CRLs, each only valid for a particular set of certificates issued by that CA. To associate a CRL with a certificate, the CA places the CRLDistributionPoints extension in the certificate, and places the IssuingDistributionPoint in the CRL. The distributionPointName field in the CRLDistributionPoints extension MUST be identical to the distributionPoint field in the IssuingDistributionPoint extension. At least one CA is known to default to this type of CRL use. See Section 5.1.3.13 for more information.
CRLDistributionPointsを使用しているCAは、そのCAによって発行された証明書の特定のセットのために多くの「小さな」のCRL、それぞれの唯一の有効なを提供するために、そうすることがあり証明書とCRLを関連付けるには、CAは、証明書にCRLDistributionPoints拡張を配置し、CRLにIssuingDistributionPointを配置します。 CRLDistributionPoints拡張におけるdistributionPointNameフィールドはIssuingDistributionPoint拡張でdistributionPointフィールドと同一でなければなりません。少なくとも一つのCAは、CRLの使用のこのタイプをデフォルトにすることが知られています。詳細については、セクション5.1.3.13を参照してください。
Given the recommendations against Certification Authority implementations generating delta CRLs, this specification RECOMMENDS that implementations do not populate CRLs with the FreshestCRL extension, which is used to obtain delta CRLs.
デルタCRLを生成する認証局の実装に対する勧告を考えると、この仕様は、実装は、デルタCRLを取得するために使用されるFreshestCRL拡張子、とCRLを移入しないことをお勧めします。
At the time that this document is being written, popular certification authorities and CA software issue certificates using the RSA-with-SHA1 and RSA-with-MD5 signature algorithms. Implementations MUST be able to validate certificates with either of those algorithms.
この文書が書かれているその時に、人気のある認証局とRSA-と-SHA1およびRSA-で-MD5署名アルゴリズムを使用して、CAのソフトウェアは証明書を発行します。実装は、これらのアルゴリズムのいずれかで証明書を検証することができなければなりません。
As described in [17], both the MD5 and SHA-1 hash algorithms are weaker than originally expected with respect to hash collisions. Certificates that use these hash algorithms as part of their signature algorithms could conceivably be subject to an attack where a CA issues a certificate with a particular identity, and the recipient of that certificate can create a different valid certificate with a different identity. So far, such an attack is only theoretical, even with the weaknesses found in the hash algorithms.
[17]に記載されているように、MD5とSHA-1ハッシュアルゴリズムの両方が衝突をハッシュに対する当初の予想よりも弱いです。彼らの署名アルゴリズムの一部として、これらのハッシュアルゴリズムを使用する証明書は、考えられる限り、CAは、特定のアイデンティティと証明書を発行し、その証明書の受信者が異なるIDを持つ別の有効な証明書を作成することができ、攻撃を受ける可能性があります。これまでのところ、このような攻撃であっても、ハッシュアルゴリズムで見つかった弱点で、唯一の理論です。
Because of the recent attacks, there has been a heightened interest in having widespread deployment of additional signature algorithms. The algorithm that has been mentioned most often is RSA-with-SHA256, two types of which are described in detail in [18]. It is widely expected that this signature algorithm will be much more resilient to collision-based attacks than the current RSA-with-SHA1 and RSA-with-MD5, although no proof of that has been shown. There is active discussion in the cryptographic community of better hash functions that could be used in signature algorithms.
そのため、最近の攻撃は、追加の署名アルゴリズムの広範な展開を持つことに関心が高まってきました。最も頻繁に言及されたアルゴリズムは、RSA-WITH-SHA256、[18]に詳細に記載されている2つのタイプです。広くことの証拠は示されていないが、この署名アルゴリズムは、はるかに弾性衝突ベースの攻撃に電流RSA-WITH-SHA1未満、RSA-WITH-MD5であることが期待されます。署名アルゴリズムで使用することができ、より良いハッシュ関数の暗号コミュニティで活発な議論があります。
In order to interoperate, all implementations need to be able to validate signatures for all algorithms that the implementations will encounter. Therefore, implementations SHOULD be able to use signatures that use the sha256WithRSAEncryption signature algorithm (PKCS#1 version 1.5) as soon as possible. At the time that this document is being written, there is at least one CA that supports generating certificates with sha256WithRSAEncryption signature algorithm, and it is expected that there will be significant deployment of this algorithm by the end of 2007.
相互運用するために、すべての実装は、実装が遭遇するすべてのアルゴリズムのための署名を検証できるようにする必要があります。したがって、実装はできるだけ早くsha256WithRSAEncryption署名アルゴリズム（PKCS＃1バージョン1.5）を使用して署名を使用することができるべきです。この文書が書かれていることを当時、そこsha256WithRSAEncryption署名アルゴリズムで生成証明書をサポートして少なくとも一つのCAがあり、2007年末までにこのアルゴリズムの重要な展開が期待されます。
Below, we present a common format for exchanging configuration data. Implementations MUST support these formats, MUST support receiving arbitrary whitespace at the beginning and end of any line, MUST support receiving arbitrary line lengths although they SHOULD generate lines less than 76 characters, and MUST support receiving the following three line-termination disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF.
以下では、コンフィギュレーション・データを交換するための共通のフォーマットを提示します。これらのフォーマットをサポートしなければならない実装は、任意の行の最初と最後に任意の空白の受信をサポートしなければならない、彼らはラインを未満76個の文字を生成するべきであるが、任意の線長を受信サポートしなければならない、そして、次の3つのライン終端分野の受信をサポートしなければならない：LFを（ US-ASCII 10）、CR（US-ASCII 13）、およびCRLF。
Certificates MUST be Base64 [19] encoded and appear between the following delimiters:
証明書は、Base64 [19]エンコードされて、次の区切り文字の間に現れなければなりません。
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
CRLs and ARLs MUST be Base64 encoded and appear between the following delimiters:
CRLとARLsは、Base64エンコードは、次の区切り文字の間に表示されなければなりません：
-----BEGIN CRL-----
-----END CRL-----
IKE implementations MUST support two forms of public keys: certificates and so-called "raw" keys. Certificates should be transferred in the same form as Section 6.1. A raw key is only the SubjectPublicKeyInfo portion of the certificate, and MUST be Base64 encoded and appear between the following delimiters:
証明書とは、いわゆる「生」キー：IKEの実装は、公開鍵の二つの形式をサポートしなければなりません。証明書は、6.1節と同じ形式で転送する必要があります。生鍵証明書のみSubjectPublicKeyInfoで部分であり、Base64でエンコードし、次の区切り文字の間に表示されなければなりません。
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and appear between the following delimiters:
PKCS＃10 [9]、証明書署名要求は、Base64でエンコードし、次の区切り文字の間に表示されなければなりません。
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
The Contents of CERTREQ are not encrypted in IKE. In some environments, this may leak private information. Administrators in some environments may wish to use the empty Certification Authority option to prevent such information from leaking, at the cost of performance.
CERTREQの内容は、IKE内で暗号化されていません。一部の環境では、これは、個人情報を漏らすことがあります。一部の環境での管理者は、性能を犠牲にし、漏れるような情報を防ぐために、空の認証局オプションを使用することもできます。
Certificates may be included in any message, and therefore implementations may wish to respond with CERTs in a message that offers privacy protection in Main Mode messages 5 and 6.
証明書は、任意のメッセージに含まれることができるので、実装がメインモードメッセージ5および6でプライバシー保護を提供していますメッセージにCERTSで応答することを望むかもしれません。
Implementations may not wish to respond with CERTs in the second message, thereby violating the identity protection feature of Main Mode in IKEv1.
実装は、それによって、IKEv1の中にメインモードのアイデンティティ保護機能に違反し、2番目のメッセージでは本命で応答したくないかもしれません。
It is important to note that anywhere this document suggests implementers provide users with the configuration option to simplify, modify, or disable a feature or verification step, there may be security consequences for doing so. Deployment experience has shown that such flexibility may be required in some environments, but making use of such flexibility can be inappropriate in others. Such configuration options MUST default to "enabled" and it is appropriate to provide warnings to users when disabling such features.
どこにでもこの文書は実装者は、簡素化、変更、または機能または検証ステップを無効にする設定オプションをユーザーに提供する、そうするためのセキュリティ上の影響があるかもしれない示唆していることに注意することが重要です。展開の経験は、そのような柔軟性は、一部の環境で必要なことを示しているが、このような柔軟性を利用することは、他の人では不適切であることができます。このような設定オプションが「有効」にデフォルトとしなければならない、そのような機能を無効にする場合、ユーザーに警告を提供することが適当です。
The authors would like to acknowledge the expired document "A PKIX Profile for IKE" (July 2000) for providing valuable materials for this document.
作者はこのドキュメントのための貴重な資料を提供するために、期限切れのドキュメント「IKEのためのPKIXプロファイル」（2000年7月）を承認したいと思います。
The authors would like to especially thank Eric Rescorla, one of its original authors, in addition to Greg Carter, Steve Hanna, Russ Housley, Charlie Kaufman, Tero Kivinen, Pekka Savola, Paul Hoffman, and Gregory Lebovitz for their valuable comments, some of which have been incorporated verbatim into this document. Paul Knight performed the arduous task of converting the text to XML format.
著者は、特に彼らの貴重なコメントについてグレッグカーター、スティーブ・ハンナ、ラスHousley、チャーリー・カウフマン、TERO Kivinen、ペッカSavola、ポール・ホフマン、およびグレゴリーLebovitzに加えてエリックレスコラ、元の著者の一人を、感謝するのいくつかをしたいと思いますこれは、このドキュメントにそのまま組み込まれています。ポール・ナイトは、XML形式にテキストを変換する骨の折れる作業を行いました。
[1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[1]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[2] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[2]モーガン、D.、シュナイダー、M.、およびM. Schertler、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408、1998年11月。
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[3]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[5] 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.
[5] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[6] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[6]パイパー、D.、 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、RFC 2407、1998年11月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[8]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[9] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[9] Nystrom、M.とB. Kaliski、 "PKCS＃10：証明書要求の構文仕様バージョン1.7"、RFC 2986、2000年11月。
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[10]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[11]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[12] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[12] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[13] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[13]リン、C.、ケント、S.、およびK.ソ、 "IPアドレスとAS識別子のためのX.509拡張機能"、RFC 3779、2004年6月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[14]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[15] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[15]フラー、V.およびT.李、 "クラスレスドメイン間ルーティング（CIDR）：インターネットアドレスの割り当てと集計プラン"、BCP 122、RFC 4632、2006年8月。
[16] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[16]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[17] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[17]ホフマン、P.とB.シュナイアー、 "インターネットプロトコルで暗号化ハッシュに対する攻撃"、RFC 4270、2005年11月。
[18] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[18] Schaad、J.、Kaliski、B.、およびR. Housley氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールで使用するRSA暗号のための追加のアルゴリズムと識別子"、RFC 4055 、2005年6月。
[19] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[19] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
Appendix A. The Possible Dangers of Delta CRLs
付録A.デルタたCRLの可能性危険性
The problem is that the CRL processing algorithm is sometimes written incorrectly with the assumption that all CRLs are base CRLs and it is assumed that CRLs will pass content validity tests. Specifically, such implementations fail to check the certificate against all possible CRLs: if the first CRL that is obtained from the keying material database fails to decode, no further revocation checks are performed for the relevant certificate. This problem is compounded by the fact that implementations that do not understand delta CRLs may fail to decode such CRLs due to the critical DeltaCRLIndicator extension. The algorithm that is implemented in this case is approximately:
問題は、CRL処理アルゴリズムを時々すべてのCRLのCRLがベースであり、CRLがコンテンツの有効性試験に合格することが想定されていることを前提と誤って書かれていることです。具体的には、そのような実装は、すべての可能なのCRLに対して証明書を確認することができない：鍵材料データベースから取得された最初のCRLが復号に失敗した場合、それ以上の失効チェックは、関連する証明書のために実行されません。この問題は、デルタCRLを理解していない実装が原因の重要なDeltaCRLIndicator拡張子に、このようなCRLをデコードするのに失敗する可能性があるという事実によって悪化します。この場合には実装されているアルゴリズムは、およそ次のとおりです。
o fetch newest CRL
O、最新のCRLを取得
o check validity of CRL signature
O CRLの署名の有効性を確認
o if CRL signature is valid, then
O CRLの署名が、その後、有効であれば
o if CRL does not contain unrecognized critical extensions and certificate is on CRL, then set certificate status to revoked
CRLが認識されていない重要な機能拡張が含まれていないと証明書がCRLにある場合は、O、その後取り消された証明書にステータスを設定
The authors note that a number of PKI toolkits do not even provide a method for obtaining anything but the newest CRL, which in the presence of delta CRLs may in fact be a delta CRL, not a base CRL.
著者は、PKIツールキットの数が偶数デルタCRLの存在下で、実際にデルタCRLはなく、ベースCRLかもしれ最新のCRLが、何かを得るための方法を提供しないことに注意してください。
Note that the above algorithm is dangerous in many ways. See the PKIX [5] certificate profile for the correct algorithm.
上記のアルゴリズムは、多くの点で危険であることに注意してください。正しいアルゴリズムのPKIX [5]証明書プロファイルを参照してください。
Appendix B. More on Empty CERTREQs
付録B.複数の空CERTREQsに
Sending empty certificate requests is commonly used in implementations, and in the IPsec interop meetings, vendors have generally agreed that it means that send all/any end-entity certificates you have (if multiple end-entity certificates are sent, they must have same public key, as otherwise, the other end does not know which key was used). For 99% of cases, the client has exactly one certificate and public key, so it really doesn't matter, but the server might have multiple; thus, it simply needs to say to the client, use any certificate you have. If we are talking about corporate VPNs, etc., even if the client has multiple certificates or keys, all of them would be usable when authenticating to the server, so the client can simply pick one.
空の証明書要求を送信すると、一般的な実装で使用され、およびIPsecの相互運用会議で、ベンダーは一般的には複数のエンドエンティティ証明書が送信された場合/あなたが持っているすべてのエンドエンティティ証明書（、彼らは同じ公開を持たなければならないことは、すべての送信を意味することを合意していますキーは、そうでないと、もう一方の端）が使用されたキーを知りません。例99％の場合、クライアントは、1つの証明書と公開鍵を持っているので、それは本当に重要ではありませんが、サーバーが複数の場合があります。したがって、それは単にあなたが持っているすべての証明書を使用して、クライアントに言う必要があります。私たちは、クライアントが複数の証明書またはキーを持っている場合でも、など、企業のVPNについて話している場合は、サーバーに認証するときにそれらのすべてが使用可能になりますので、クライアントは、単にものを選ぶことができます。
If there is some real difference on which certificate to use (like ones giving different permissions), then the client must be configured anyway, or it might even ask the user which one to use (the user is the only one who knows whether he needs admin privileges, thus needs to use admin cert, or if the normal email privileges are ok, thus uses email only cert).
（ものは異なるアクセス許可を与えるように）使用する証明書のいくつかの本当の違いがある場合、クライアントはとにかく構成されている必要があり、あるいはそれも、ユーザは彼が必要かどうかを知っている唯一のものである（1が使用するユーザーを頼むかもしれません管理者権限は、これ管理者証明書を使用する必要がある、または通常の電子メールの権限がOKであれば、このように電子メールのみ証明書）を使用しています。
In 99% of the cases, the client has exactly one certificate, so it will send it. In 90% of the rest of the cases, any of the certificates is ok, as they are simply different certificates from the same CA, or from different CAs for the same corporate VPN, thus any of them is ok.
例99％で、クライアントは、1つの証明書を持っているので、それを送信します。彼らは同じ企業のVPNで同じCAから、または異なるCAから単に別の証明書があるとして例、残りの90％で、証明書のいずれかは、このようにそれらのいずれかがokです、大丈夫です。
Sending empty certificate requests has been agreed there to mean "give me your cert, any cert".
空の証明書要求を送信することを意味し、「私にあなたの証明書、任意の証明書を与える」ことが合意されています。
Justification:
正当化：
o Responder first does all it can to send a CERTREQ with a CA, check for IP match in SPD, have a default set of CAs to use in ambiguous cases, etc.
Oレスポンダ最初など、あいまいな場合に使用するCAのデフォルトセットを持って、SPDにIPの試合をチェックし、CAとCERTREQを送信することができるすべてを行います
o Sending empty CERTREQs is fairly common in implementations today, and is generally accepted to mean "send me a certificate, any certificate that works for you".
空CERTREQsを送信するoを実装して、今日はかなり一般的であり、一般に「私にあなたのために働くすべての証明書を証明書を送信」を意味するように受け入れられています。
o Saves responder sending potentially hundreds of certs, the fragmentation problems that follow, etc.
oはなど、潜在的に本命の何百、続く断片化の問題を送信レスポンダ保存します
o In +90% of use cases, Initiators have exactly one certificate.
Oの使用例+ 90％で、イニシエータは、1つの証明書を持っています。
o In +90% of the remaining use cases, the multiple certificates it has are issued by the same CA.
Oの残りの使用例+ 90％で、それが持っている複数の証明書は同じCAによって発行されています
o In the remaining use case(s) -- if not all the others above -- the Initiator will be configured explicitly with which certificate to send, so responding to an empty CERTREQ is easy.
O残りのユースケース（S）は - 上記のすべての他のものではない場合 - イニシエータので空CERTREQに応答することは容易であり、送信するためにどの証明書を使用して明示的に設定されます。
The following example shows why initiators need to have sufficient policy definition to know which certificate to use for a given connection it initiates.
開始剤は、それが開始され特定の接続に使用する証明書を知るために十分なポリシー定義を持っている必要がある理由、次の例を示します。
EXAMPLE: Your client (initiator) is configured with VPN policies for gateways A and B (representing perhaps corporate partners).
例：あなたのクライアント（イニシエータ）は、ゲートウェイAとB（おそらく企業パートナーを表す）用のVPNポリシーが設定されています。
The policies for the two gateways look something like:
2つのゲートウェイのポリシーは次のようになり：
Acme Company policy (gateway A)
Engineering can access 10.1.1.0
Trusted CA: CA-A, Trusted Users: OU=Engineering
Partners can access 20.1.1.0
Trusted CA: CA-B, Trusted Users: OU=AcmePartners
Bizco Company policy (gateway B) Sales can access 30.1.1.0 Trusted CA: CA-C, Trusted Users: OU=Sales Partners can access 40.1.1.0 Trusted CA: CA-B, Trusted Users: OU=BizcoPartners
Bizco会社方針（ゲートウェイB）販売が30.1.1.0信頼できるCAアクセスすることができ：CA-Cを、信頼されているユーザー：CA-B、信頼されたユーザー：OU = BizcoPartners OU =販売パートナーは、40.1.1.0信頼できるCAにアクセスすることができ
You are an employee of Acme and you are issued the following certificates:
あなたはアクメの従業員であり、あなたは、次の証明書を発行されています。
o From CA-A: CN=JoeUser,OU=Engineering o From CA-B: CN=JoePartner,OU=BizcoPartners
CA-AからO：CA-Bから0 = joeuserをCN、OU =エンジニアリング：CN = JoePartner、OU = BizcoPartners
The client MUST be configured locally to know which CA to use when connecting to either gateway. If your client is not configured to know the local credential to use for the remote gateway, this scenario will not work either. If you attempt to connect to Bizco, everything will work... as you are presented with responding with a certificate signed by CA-B or CA-C... as you only have a certificate from CA-B you are OK. If you attempt to connect to Acme, you have an issue because you are presented with an ambiguous policy selection. As the initiator, you will be presented with certificate requests from both CA-A and CA-B. You have certificates issued by both CAs, but only one of the certificates will be usable. How does the client know which certificate it should present? It must have sufficiently clear local policy specifying which one credential to present for the connection it initiates.
クライアントは、ゲートウェイのいずれかに接続する際にCAを使用するかを知るために、ローカルに設定されなければなりません。あなたのクライアントがリモートゲートウェイに使用するローカル資格を知るように設定されていない場合は、このシナリオはどちらか動作しません。あなたはBizcoに接続しようとした場合、あなたはあなただけでOKですCA-Bからの証明書を持っているとして、CA-BまたはCA-C ...によって署名された証明書で応答が提示されているように、すべてが...動作します。あなたがアクメに接続しようとすると、あなたがあいまいな政策選択を提示されているので、あなたが問題を持っています。開始剤として、あなたはCA-AおよびCA-Bの両方からの証明書要求が表示されます。あなたは、両方のCAが発行した証明書を持っていますが、証明書の一方のみが使用可能になります。どのようにクライアントは、それが提示する証明書を知っていますか？これは、1人の資格は、それが開始され、接続のために存在するのに十分に明確なローカルポリシーの指定を持っている必要があります。
Author's Address
著者のアドレス
Brian Korver Network Resonance, Inc. 2483 E. Bayshore Rd. Palo Alto, CA 94303 US
ブライアン・コーバーネットワークレゾナンス、Inc.の2483 E.ベイショアRdを。パロアルト、CA 94303米国
Phone: +1 650 812 7705 EMail: briank@networkresonance.com
電話：+1 650 812 7705 Eメール：briank@networkresonance.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。