[要約] RFC 4945は、IKEv1/ISAKMP、IKEv2、およびPKIXのインターネットIPセキュリティPKIプロファイルに関する標準化された要件を提供します。このRFCの目的は、これらのプロトコルのセキュリティに関するベストプラクティスを定義し、PKIのプロファイルを統一することです。
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）The IETF Trust（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.
X.509（PKIX）証明書プロファイルのインターネットキーエクスチェンジ（IKE）と公開キーインフラストラクチャは、どちらも特定のアプリケーションで使用するためにプロファイルする必要があるフレームワークを提供します。このドキュメントは、IKE/IPSECのコンテキストでPKIテクノロジーを使用する要件を定義するIKEとPKIXのプロファイルを提供します。このドキュメントは、IKEV1やIKEV2などのプロトコル仕様を補完します。これは、公開キー証明書と関連するキーイング材料の存在を想定していますが、PKIの問題に明示的に対処していません。このドキュメントはこれらの問題に対処します。意図した視聴者は、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では、このドキュメントの残りの部分で使用される特別な用語を定義し、セクション3でIKEV1/ISAKMPのプロファイルを提供し、セクション4でIKEV2のプロファイルを提供し、セクション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_user_fqdnをid_rfc822_addrに変更しました。どちらもこのドキュメントで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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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を使用可能な証明書ストアまたはディレクトリの証明書の検索の検索キーとして使用できます。このセクションの主な関心事は、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).
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 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] =少なくとも、実装は、IDペイロードコンテンツの正確なマッチングをローカルSPDのエントリに実行するように構成できる必要があります。
[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] =さらに、実装は、IDペイロードコンテンツのサブストリングまたはワイルドカードマッチをローカルSPDのエントリに実行するように構成可能でもあります。（これについては、セクション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はIPアドレスよりも推奨されます（セクション3.1.1の説明を参照）。
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.
著名な名前（DN）をIDとして送信する場合、実装はIDでDN全体を送信する必要があります。また、実装は、SPDマッチングのC、CN、O、およびOUの属性を少なくともサポートする必要があります。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コンテンツとの一致を行うことができます。言い換えれば、実装はIDの正確な一致をSPDに実行できる必要がありますが、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.
実装は、ネットワークアドレス翻訳者（NAT）トラバーサルの問題やIP検証動作の問題などの相互運用性の問題により、IDペイロードをIPアドレスに入力してはなりません。
Deployments may only want to consider using the IP address as ID if all of the following are true:
展開は、次のすべてが真である場合にのみ、IPアドレスをIDとして使用することを検討することをお勧めします。
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.
o ピアはNATの背後にいません。管理者は、ピアソースアドレスが受信したIDアドレスが受け取ったIPアドレスと一致し、ピア証明書のsubjectName拡張機能のiPaddressフィールドにあることを確認するための実装を意図しています。
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アドレスがビットワイズ比較を介してIDアドレスが一致することを確認できる必要があります。実装は、デフォルトでこの検証を実行する必要があります。IDの内容を、equalityのためにsubjectaltname拡張機能のiPaddressフィールドと比較する場合、バイナリ比較を実行する必要があります。証明書には複数のアドレスIDタイプが含まれる場合があることに注意してください。この場合、少なくとも1つはソースIPと一致する必要があります。デフォルトが有効になっている場合、2つのアドレス間の不一致をエラーとして扱う必要があり、セキュリティ協会のセットアップを中止する必要があります。このイベントは監査可能です。実装は、その検証ステップをスキップする（つまり、ローカルポリシーの構成が有効にできる）構成オプションを提供する場合がありますが、そのオプションはデフォルトでオフにする必要があります。現在の実装は、このトピックでの振る舞いが大きく異なるため、より良い相互運用性を可能にするために、「SkipからValidation」を含めます。
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アドレスタイプの1つである場合、実装はデフォルトでこの検証を実行する必要があります。このデフォルトが有効になっている場合、ミスマッチをエラーとして扱う必要があり、セキュリティ協会のセットアップを中止する必要があります。このイベントは監査可能です。実装では、その検証ステップをスキップするには（つまり、ローカルポリシーの構成が有効になる）構成オプションを提供する場合がありますが、そのオプションはデフォルトでオフにする必要があります。ソースIPの検証のトピックで現在の実装がどのように動作するかは大きく異なるため、より良い相互運用性を可能にするために、「Skipからの検証」を含めます。
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.
上記の検証の両方のデフォルトが有効になっている場合、Transitiveプロパティにより、実装は、証明書のsumbercaltname拡張機能のiPaddressフィールドの内容とビットワイズの比較を介してピアソースIPアドレスが一致することを確認します。さらに、実装により、管理者は、証明書のsumbortaltname拡張機能のiPaddressフィールドの内容を少し単一の比較により、ピアソース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エンドポイントであると認識されている場合、ポリシーはそのアドレスを使用して決定される場合がありますが、ピア証明書を検証することでID（アドレス）が検証されるまで、ポリシーを使用しないでください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.
実装は、ID_FQDN IDタイプをサポートする必要があります。通常、固定IPアドレスのないホストのホストベースのアクセス制御リストをサポートする必要があります。ただし、実装はDNSを使用して、ポリシー決定への入力のためにFQDNをIPアドレスにマッピングする必要はありません。たとえば、DNSSEC [11]がそのFQDNに使用された場合、マッピングが安全であることが知られていない場合を除きます。
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ペイロードに含まれるIDがPeer End-Entity証明書に含まれるID情報と一致することを確認できる必要があります。実装は、デフォルトでこの検証を実行する必要があります。IDの内容を、等式のsumbercaltname拡張機能のDNSNAMEフィールドと比較する場合、ケースに依存しない文字列比較を実行する必要があります。Case-inssensive Stringの比較は、国際化ドメイン名（IDN）でも機能することに注意してください（IDN [12]を参照）。この比較のために、サブストリング、ワイルドカード、または正規表現マッチングを実行しないでください。このデフォルトが有効になっている場合、ミスマッチをエラーとして扱う必要があり、セキュリティ協会のセットアップを中止する必要があります。このイベントは監査可能です。実装は、その検証ステップをスキップする（つまり、ローカルポリシーの構成が有効にできる）構成オプションを提供する場合がありますが、そのオプションはデフォルトでオフにする必要があります。現在の実装は、このトピックでの動作が大きく異なるため、より良い相互運用性を可能にするために、「SkipからValidation」を含めます。
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.
実装は、ID_USER_FQDN IDタイプをサポートする必要があります。通常、固定IPアドレスのないユーザーのユーザーベースのアクセス制御リストをサポートする必要があります。ただし、実装はDNSを使用して、ポリシー決定に入力するためにFQDN部分をIPアドレスにマッピングする必要はありません。たとえば、マッピングが安全であることが知られていない場合、たとえばDNSSEC [11]がその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 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ペイロードに含まれるアイデンティティが、sumberaltname拡張機能のRFC822NAMEフィールドに含まれるID情報と一致することを確認できる必要があります。実装は、デフォルトでこの検証を実行する必要があります。IDのコンテンツを、equalityのsumbutaltname拡張機能でRFC822NAMEフィールドと比較する場合、ケース非感受性の文字列比較を実行する必要があります。Case-inssensive Stringの比較は、国際化ドメイン名（IDN）でも機能することに注意してください（IDN [12]を参照）。この比較のために、サブストリング、ワイルドカード、または正規表現マッチングを実行しないでください。このデフォルトが有効になっている場合、ミスマッチをエラーとして扱う必要があり、セキュリティ協会のセットアップを中止する必要があります。このイベントは監査可能です。実装は、その検証ステップをスキップする（つまり、ローカルポリシーの構成が有効にできる）構成オプションを提供する場合がありますが、そのオプションはデフォルトでオフにする必要があります。現在の実装は、このトピックでの動作が大きく異なるため、より良い相互運用性を可能にするために、「SkipからValidation」を含めます。
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.
実装は、IDの内容のサブストリング、ワイルドカード、または正規表現のマッチングをサポートして、SPDのポリシーを検索することをサポートする場合があります。これは、ローカルセキュリティポリシーの構成の問題です。
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のコンテンツをエンドエンティティ証明書からサブジェクトフィールドに入力する必要があり、2つのバイナリ比較が成功するようにそうする必要があります。一致がない場合は、これをエラーとして扱う必要があり、セキュリティ協会のセットアップを中止する必要があります。このイベントは監査可能です。
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証明書プロファイルの「件名」セクションで明示的に許可されている場合でも、空の場合、end-entity証明書の主題に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マッチングに関しては、実装は、IDのDN全体のSPDへのエントリとのビットごとの比較に基づいて、マッチングを実行できる必要があります。ただし、運用上の経験により、特に大規模な展開では、ローカル構成でDN全体を使用することが困難であることが示されています。したがって、実装は、IDの被験者DN内のC、CN、O、OUの属性の任意の組み合わせのSPDマッチをSPDで同じものに実行できる必要があります。相互運用性は特定とはほど遠く、疑わしいものであるが、実装は任意の組み合わせで追加のDN属性を使用したマッチングをサポートする場合があります。また、実装は、IDからSPDへのIDからサポートされているDN属性のいずれかについて、サブストリング、ワイルドカード、または正規表現マッチの実行をサポートする場合があります。このような柔軟性により、展開者は、会社の部門全体（例えば、O = Foobar Inc.、OU = Engineering）のゲートウェイに1つのSPDエントリを作成することができますが、DNから他の詳細を引き出すことができます（例：CN = John = Johndoe）監査目的。上記はすべて、ローカルの実装とローカルポリシーの定義と執行能力の問題であり、ワイヤーのビットではありませんが、相互運用性に大きな影響を与えます。
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拡張機能の両方が人口の両方である場合、または被験者が空であるかどうかに関係なく複数のIDを含む場合など、単一のIDを含む単一のIDを含む証明書をサポートする必要があります。多くの場合、証明書には、空でない被験者に加えて、subjectaltname拡張機能にIPアドレスなどのIDが含まれます。
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に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でポリシーを見つけることができない場合、受信者は適切なポリシーと一致しようとするときに証明書の他のIDを使用できます。たとえば、証明書には、空でないサブジェクトフィールド、DNSName、iPaddressが含まれているとします。iPaddressが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証明書-Signature o Rococationリスト（CRLおよびARL）O PKCS＃7ラップ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証明書 - キーエクスチェンジO PGP（かなり良いプライバシー）証明書o DNS署名キーO Kerberos Tokens O SPKI（単純公開キーインフラストラクチャ）証明書o X.509証明書属性
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の帯域外に対処されるべきです。この理由およびその他の理由により、実装は、証明書の種類が「証明書取消リスト（CRL）」または「権限取消リスト（ARL）」である場合にCertreqを生成すべきではありません。そのようなCertreqを生成する実装は、受信者が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.
帯域内の取り消しリストを交換する代わりに、取り消しチェックへのポインターは、CRLDISTRISTPOINTS（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タイプを含むCertreqを無視する場合があり、編集者はそのようなCertreqメッセージを生成する実装を認識していません。したがって、このタイプの使用は非推奨です。実装は、この証明書タイプを含むcertreqを必要としないでください。このIDタイプを含むcertreqを受信する実装は、そのようなペイロードを「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.
証明書のキーイング資料の帯域交換が必要な場合、少なくとも1つのCertreqを送信することにより、実装はこれをピアに通知する必要があります。言い換えれば、交換中にCertreqを送信しない実装は、証明書のペイロードを受け取ることを期待してはなりません。
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.
キーイング資料の帯域交換を要求する場合、実装は、特定の交換中にローカルポリシーが明示的に信頼できると見なすすべてのピアトラストアンカーに対してCERTREQを生成する必要があります。実装は、主題と認定機関のバイナリ比較が成功するように、信託アンカーの主題フィールドに認定機関のフィールドを埋める必要があります。
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証明書 - 署名」であり、認定機関フィールドが空でない場合にCertreqを生成する必要があります。ただし、実装は、特別な条件下で空の認証機関フィールドでCertreqを生成する場合があります。PKIXは空の発行者フィールドで証明書を禁止していますが、そうすることが適切であり、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ピアの複数のポリシーを備えたゲートウェイがあるまれなケースを考えてみましょう。これらのピアの一部はビジネスパートナーであり、一部はリモートアクセス従業員、一部はテレワーカー、一部は支店、および/またはゲートウェイは、多くの顧客（仮想ルーターなど）に同時にサービスを提供する場合があります。証明書の総数、および対応する信託アンカーは非常に高いです - たとえば、数百。これらの各ポリシーは、1つ以上の許容可能な信頼アンカーで構成されているため、合計でゲートウェイには、着信接続の認証に使用できる100（100）の信頼アンカーがあります。これらの接続の多くは、動的に割り当てられたIPアドレスを持つホスト/ゲートウェイから発生し、IKEイニシエーターのソースIPがゲートウェイに知られていないことも、イニシエーターの識別でもないと仮定します（メインモードメッセージ5で明らかになるまで）。IKEメインモードメッセージ4では、レスポンダーゲートウェイはイニシエーターにcertreqを送信する必要があります。この例を考慮して、ゲートウェイは、Certreqを送信する可能性のある100の認定当局のどれがわからないでしょう。すべての可能な認証当局を送ると、大幅な処理遅延、帯域幅の消費、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:
このような展開では、Responder Gatewayの実装は、Certreqの認証機関を示すためにできる限りのことを行うことができるはずです。これは、レスポンダーが最初にSPDをチェックしてソースIPと一致するかどうかを確認し、そのIPにどのCAが関連付けられているかを示す兆候を見つける必要があることを意味します。これが失敗した場合（上記の場合のように、ソースIPが馴染みがないため）、レスポンダーには、このような曖昧な接続中にCARTREQで示すデフォルトのCASであるCASを指定する構成オプションが必要です（たとえば、これらのnでCertreqを送信します不明なソースIPがある場合はCAS）。このようなフォールバックが特定の展開シナリオで構成または非現実的でない場合、レスポンダーの実装には、次の構成オプションの両方が必要です。
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を送信した後、レスポンダーがメッセージ5の証明書を受け取り、レスポンダーが（a）をサポートしていない、または（b）ポリシーの構成（イニシエーターの証明書が存在するためにポリシーが一致するようになりました）、これはエラーとして扱われ、セキュリティ協会のセットアップを中止する必要があります。このイベントは監査可能です。
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.
実装は、サポートされていない証明書タイプを使用してCertreqの受信に対処できる必要があります。認識されサポートされている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.
実装は、認定不可能な認証機関フィールドを使用してCertreqの受信に対処できる必要があります。実装は、ローカルポリシーに応じて、そのようなペイロードを無視する場合があります。ISAKMPは、取得される可能性のある他のアクションを指定します。
Implementations MUST NOT assume that CERTREQs are ordered in any way.
実装は、Certreqが何らかの形で注文されていると仮定してはなりません。
Implementations SHOULD NOT send duplicate CERTREQs during an exchange.
実装は、交換中に重複したcertreqを送信するべきではありません。
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.
ピアの証明書キーイング素材がキャッシュされた場合、実装はピアにヒントを送信して、ピアが通常応答に含める証明書の一部を削除することができます。信頼のアンカーを指定して送信される通常のCertreqsのセットに加えて、実装は、関連するキャッシュエンドエンティティ証明書を指定するCertreqを送信する場合があります。これらのヒントを送信する場合、ヒントがピアが必要とするすべての情報を十分に伝えていないため、通常の信頼のアンカー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の受信者の側には特別な処理は必要ありません。また、エンディティ証明書は引き続き送信されます。一方、受信者は、このようなヒントの受領に基づいて証明書を削除することを選択できます。
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には、認定機関証明書を識別する情報が含まれている必要があります。その結果、ピアは常に少なくとも終了証明書を送信します。常にエンドエンティティ証明書を送信することにより、実装がピアによって新しい証明書が使用されている場合（おそらく以前の証明書が期限切れになったため）、実装を明確に決定できます。新しいエンドエンティティ証明書を検証します）。この最適化を実装する実装では、エンティーティ証明書が変更され、この最適化を実行しないことにより、交換を再試行しなければならない場合、再試行中に送信することにより、それに応答することを認識する必要があります。
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にサブジェクトフィールドを含むCertreqを送信する場合、この実装は、ピアが少なくとも3つの証明書を送信することを要求しています：CA1、CA2、およびEE。一方、この実装が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とARLを交換すると、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を持っていることを想像してください。送信者は単に中間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証明書-Signature o Rococationリスト（CRLおよびARL）O PKCS＃7ラップ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証明書 - キーエクスチェンジo PGP証明書O DNS署名キーO Kerberos Tokens O SPKI証明書O X.509証明書属性
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.
このタイプは、特定の証明書タイプではなく、特定のエンコーディングを定義します。実装は、この証明書の種類を含む証明書を生成してはなりません。実装は、いくつかの実装がそれらを生成することが知られているため、この証明書タイプを含む証明書を受け入れる必要があります。これらの実装には、単一の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.
取引所中にCERTREQを受け取らない実装は、証明書が必要な場合でもCERTREQを送信できない非準拠の実装と相互運用するために、積極的に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.
不要で潜在的に高価な暗号化処理、サービス拒否（リソース飢v）攻撃を避けるために、認識されていない認証当局のみを含むピアから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を含む複数のCertreqに応えて、実装は、ピアが提供するIDのいずれかに一致する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.
実装は、認識されていないまたはサポートされていない証明書タイプを備えたCERTINGを扱うことができなければなりません。実装は、ローカルポリシーに応じて、そのようなペイロードを破棄する場合があります。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.
実装は、交換とは無関係な証明書を送信する場合があります。交換とは無関係の証明書を含める理由の1つは、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).
交換とは無関係に思われる証明書を含めるもう1つの理由は、認定機関から最終エンティティに2つのチェーンがある可能性があり、それぞれが特定の検証パラメーター（許容可能なポリシーなど）でのみ有効であることです。エンドエンティティでは、頼っている当事者が使用しているパラメーターがわからないため、両方のチェーンに必要な証明書を送信する必要があります（たとえCertreqが1つしかない場合でも）。
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.
実装は、交換中に重複した証明書を送信すべきではありません。このようなペイロードは抑制される必要があります。
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.
エンドエンティティ証明書チェーン内の認証当局を指定する複数のcertreqを受け取った場合、実装は可能な限り最短チェーンを送信する場合があります。ただし、実装では常にエンドエンティティ証明書を送信する必要があります。この最適化の詳細については、セクション3.2.9.2を参照してください。
Implementations MAY employ local means to recognize CERTs that have already been received and SHOULD discard these duplicate 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.
Keypairの公開部分が証明書に配置されたときはいつでも、このペイロードを実装する必要があります。
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.
RFC 4301 [14]に記載されているピア認証データベース（PAD）は、IKEV2でのIDペイロードの使用について説明し、ポリシーの詳細をより具体的に扱うサービスを提供するサービスを提供することに加えて、アイデンティティをポリシーに拘束する正式なモデルを提供します通常、このドキュメントの範囲外である執行。このパッドは、IKEなどのプロトコルでSPDとセキュリティ協会の管理者との間のリンクを提供することを目的としています。詳細については、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は、Responderの複数のアイデンティティのどれを使用するかを指定するために、イニシエーターがResponderに送信できる2番目の交換にオプションのIDRペイロードを追加することに注意してください。レスポンダーは、イニシエーターで生成されたIDRとのタイプまたはコンテンツが異なる3番目の交換で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ルックアップをサポートし、実際の証明書を受信することを好む場合、実装はタイプ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および3にある必要があります。IKEV2では、片側が証明書で認証することが可能であり、反対側は事前共有キーで認証されることに注意してください。
This type specifies that Certificate Data contains a hash and the URL to a repository where an X.509 certificate can be retrieved.
このタイプは、証明書データにハッシュとURLがX.509証明書を取得できるリポジトリに含まれることを指定します。
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-PATHを必要とする必要はありません。以下は、必須フォームの例です。
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
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
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
o
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および4にある必要があります。IKEV2では、片側が証明書で認証することが可能であることに注意してください。
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の場合、実装は、最初の証明書以外は何らかの形で注文されていると仮定してはなりません。IKEV2は、最初の証明書には、ピアの認証に使用できるエンドエンティティ証明書が含まれていることを指定します。
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の機能をほとんど制御できませんでした。この仕様の実装には、柔軟性のないCASおよび/または非接続的な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.
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.
認証機関の実装は、少なくとも次の4つの属性を持つサブジェクトフィールドで証明書を作成できる必要があります：CN、C、O、およびOU。実装は、他の主題属性もサポートする場合があります。これらの属性の内容は、証明書ごとに構成できる必要があります。これらのフィールドは、IKE実装でSPDポリシーと一致するために使用される可能性が高いためです。
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.
受信者がFQDNSとして処理することを意図していないホスト名（たとえば、「ゲートウェイルーター」）を主題内に配置することを望む実装は、CommonName属性を使用する必要があります。
As specified in the PKIX certificate profile, implementations MUST NOT populate X.500 distinguished names with the emailAddress attribute.
PKIX証明書プロファイルで指定されているように、実装はX.500の著名な名前を電子メールAddress属性に入力してはなりません。
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、およびbasicconstraintsです。
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.
実装は、authorideyidentifierまたはsubjectkeyidentifier拡張機能のサポートを想定してはなりません。したがって、認定機関の実装は、これらの拡張機能の存在下で処理するために過度に複雑な証明書階層を生成するべきではありません。たとえば、多数の同様の名前の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拡張機能が存在する場合は、キーセージ拡張機能のDigitalSignatureまたは非控除ビットの少なくとも1つを設定する必要があります（両方も設定できます）。また、他のkeyUSAGEビットが設定されている場合は問題ありません。
A summary of the logic flow for peer cert validation follows:
ピア証明書の検証のロジックフローの概要は次のとおりです。
o If no KU extension, continue.
o KU拡張機能がない場合は、続行します。
o If KU present and doesn't mention digitalSignature or nonRepudiation (both, in addition to other KUs, is also fine), reject cert.
o Kuが出席し、DigitalSignatureまたは非繰り返しに言及していない場合（両方とも他のKUに加えて、問題も問題ありません）、CERTを拒否します。
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セキュリティ協会（SAS）は、各署名が1回しか検証されていないという事実に加えて、この拡張機能の意図された使用に比べて短命であるため、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実装は現在、証明書の拡張機能をサポートしていません。したがって、この拡張機能を含む証明書を生成する認証機関の実装は、拡張機能を重要なものとしてマークしてはなりません。すべての証明書拡張機能の場合と同様に、この延長を受け取る依存関係者は、拡張機能を処理できる人は、拡張機能が含まれているため、証明書を拒否すべきではありません。
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フィールドで証明書を発行する必要があります。実装は、subjectaltname拡張機能で次の一般名の選択肢のみを生成する必要があります。これらの選択肢は、RFC822NAME、DNSNAME、またはiPaddressのLegal IKEV1/ IKEV2/ IKEV2識別ペイロードタイプにマッピングされるためです。ID_DER_ASN1_GN IDタイプを使用して、識別ペイロードで一般名の選択を指定することは可能ですが、実装はそのような機能のサポートを想定してはならず、そうする証明書を生成するべきではありません。
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の場合、iPaddressフィールドはその内容と一致する必要があります。PKIXは「名前の制約」拡張機能でCIDR [15]の表記を許可しているが、PKIX証明書プロファイルは、CIDR表記を使用してID情報を伝えることを明示的に禁止することに注意してください。言い換えれば、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.
件名DirectoryAttributes拡張は、被験者の識別属性を伝えることを目的としています。IKEの実装は、PKIX証明書プロファイルが義務付けられているため、非批判的であるとマークされている場合、この拡張機能を無視する場合があります。
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.
PKIX証明書プロファイルは、CA証明書にこの拡張機能が含まれており、重要とマークされていることを義務付けています。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拡張機能をサポートしていません。PKIX証明書プロファイルは、この拡張機能が存在するときに重要とマークされることを義務付けているため、IKEの最大の相互運用性に関心のある認証機関の実装は、この拡張機能を含む証明書を生成してはなりません。
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拡張機能をサポートしていません。PKIX証明書プロファイルは、この拡張機能が存在するときに重要とマークされることを義務付けているため、IKEの最大の相互運用性に関心のある認証機関の実装は、この拡張機能を含む証明書を生成してはなりません。
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で使用するための証明書に拡張キーユーザー（EKU）拡張機能を含めるべきではありません。EKUには、1999年に割り当てられた3つのIPSEC関連オブジェクト識別子があったことに注意してください。これらの値のセマンティクスは明確に定義されていませんでした。IKE/IPSECでのこれら3つのEKU値の使用は時代遅れであり、この仕様によって明示的に非推奨されています。CASは、IKEで使用するために証明書を発行してはなりません。（履歴参照のみのために、これらの値はID-KP-IPSECENDSYSTEST、ID-KP-IPECTUNNEN、および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拡張機能をマークしないでください。それにもかかわらず、このドキュメントでは、証明書の使用を制限するために使用できる拡張キーエイジャージキープラリッドを定義します。
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値の使用を必要とする場合、そのような証明書は、keypurposeId id-kp-inpecikeまたはayextedededkeyusage [5]を含む必要があります。他のアプリケーションに関連付けられたkeypurposeId値。同様に、CAがIKEを含む複数のアプリケーションに対して複数の類似の証明書を発行し、IKE証明書を別のアプリケーションで使用しないことを意図している場合、IKE証明書には、ID-KP-IPSECIKEのキープラーズイドをリストするEKU拡張機能を含めることができます。他のアプリケーションでの使用を阻止します。ただし、IKEでの使用を目的とした証明書のEKU拡張は推奨されないことを思い出してください。
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.
EKUをサポートするために、IKEの実装の適合は必要ありません。重要なEKU拡張機能が証明書に表示され、EKUが実装によってサポートされていない場合、RFC 3280では証明書を拒否する必要があります。EKUをサポートする実装は、証明書の検証のために次のロジックをサポートする必要があります。OEKU拡張機能がない場合は、続行します。
o If EKU present AND contains either id-kp-ipsecIKE or anyExtendedKeyUsage, continue.
o EKUが存在し、ID-KP-IPSecikeまたはayextededKeyUsageのいずれかを含む場合、続行します。
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が失効チェックに使用される場合、CRLDISTRISTOPPINTS（CDP）の使用が非常に重要になります（たとえば、オンライン証明書ステータスプロトコル-OCSP [16]）。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/ susingDistributionPointペアの検証に失敗すると、CRLの代替が発生する可能性があり、エンティティが使用されるはずのCRLの異なる分布ポイントから既知の良好なCRLを故意に置き換えると、エンティティが取り消されたものを示します。IKEの実装は、発行CAがそれらを使用しているときにCRLの置換を防ぐために、crldistributionpointの内容が発行配信ポイントの内容と一致することを検証することをサポートする必要があります。少なくとも1つの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は「解決可能」でなければなりません。いくつかの非準拠認証機関の実装は、http：// localhost/path_to_crlやhttp：/// path_to_crlなどの未解決の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とIssingdistributionpoint拡張機能の両方が推奨されますが、pkix証明書プロファイルでは必要ないため、IPRのライセンスを取得する必要はないことに注意してください。
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実装は、阻害剤の拡張をサポートしていません。PKIX証明書プロファイルは、この拡張機能が存在するときに重要とマークされることを義務付けているため、IKEの最大の相互運用性に関心のある認証機関の実装は、この拡張機能を含む証明書を生成してはなりません。
IKE implementations MUST NOT assume that the FreshestCRL extension will exist in peer certificates. Note that most IKE implementations do not support delta CRLs.
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情報とサービスにアクセスする方法」を示すために使用されるAuthority -Infoaccess拡張機能を定義します。このドキュメントは、銀行内のCRLの送信を非難するため、OCSP [16]が（CRLとは対照的に）取り消しチェックに使用される場合、authoridinfoaccess（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の形でそのような取り消し情報をサポートする必要があります。CRLSを取り消しに使用する予定の展開では、CRLDISTRISTPOINTS拡張機能を備えている必要があります。したがって、認定機関の実装は、このフィールドが登録された証明書の発行をサポートする必要があります。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の実装がauthoridKeyIdentifier拡張機能をサポートしていると仮定してはならないため、この拡張機能の存在下で処理するのに過度に複雑な証明書階層を生成してはなりません。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.
Delta CRLSをサポートしていないIKEの実装は、Deltacrlindicatorを含むCRL（PKIX証明書プロファイルに応じて重要とマークする必要があります）を拒否し、利用可能な場合はベース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.
Delta CRLSをサポートしていない一部のIKE実装は、デルタCRLと提示された場合に誤ってまたは不安に振る舞う可能性があるため、管理者と展開者は、Delta CRLSを発行するとCRLSを発行する前にセキュリティを増加させるかどうかを検討する必要があります。また、VPNおよびPKIシステムのすべての要素がDelta CRLSを適切にサポートしていない場合、それらの使用に疑問を投げかける必要があります。
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.
編集者は、デルタCRLSで提示された場合、誤ったまたは不安定な方法で動作するいくつかの実装を認識しています。問題の説明については、付録Aを参照してください。したがって、この仕様では、現時点ではデルタCRLを発行しないことが推奨されます。一方、デルタCRLの発行に失敗すると、完全なCRLがDelta CRLSと同じくらい頻繁に発行されない場合、より大きな脆弱性のウィンドウを公開する可能性があります。追加の議論については、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は、多くの「小さい」CRLを提供するためにそうすることができます。CRLを証明書に関連付けるために、CAはCRLDistributionPointsの拡張を証明書に配置し、IssingDistributionPointをCRLに配置します。crldistributionpoints拡張の配信ポイント名フィールドは、IssingDistributionPoint拡張の分布ポイントフィールドと同一でなければなりません。少なくとも1つの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.
Delta CRLSを生成する認定機関の実装に対する推奨事項を考慮して、この仕様では、実装には、Delta CRLの取得に使用される新鮮なCRLに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-with-Sha1およびRSA-with-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を持つ証明書を発行し、その証明書の受信者が異なる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であり、その2つのタイプは[18]で詳細に説明されています。この署名アルゴリズムは、現在の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.
相互運用するために、すべての実装は、実装が遭遇するすべてのアルゴリズムの署名を検証できる必要があります。したがって、実装は、できるだけ早くSHA256WithRSAENCRYPTING署名アルゴリズム（PKCS＃1バージョン1.5）を使用する署名を使用できる必要があります。このドキュメントが記述されている時点で、SHA256SAECRYPTION SIGNATUREアルゴリズムを使用したSHA256の生成証明書をサポートするCAが少なくとも1つあり、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つのライン終端分野を受信することをサポートする必要があります。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の実装は、証明書といわゆる「生」キーの2つの形式のパブリックキーをサポートする必要があります。証明書は、セクション6.1と同じ形式で転送する必要があります。生のキーは、証明書の件名の件名部分のみであり、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のプライバシー保護を提供するメッセージのCERTで応答することをお勧めします。
Implementations may not wish to respond with CERTs in the second message, thereby violating the identity protection feature of Main Mode in IKEv1.
実装は、2番目のメッセージで証明書に応答することを望まない場合があり、それによりIKEV1のメインモードのID保護機能に違反します。
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.
著者は、グレッグ・カーター、スティーブ・ハンナ、スティーブ・ハンリー、ラス・ハウリー、チャーリー・カウフマン、テロ・キビネン、ペッカ・サヴォラ、ポール・ホフマン、グレゴリー・レボビッツの貴重なコメントに加えて、元の著者の一人であるエリック・レスコルラに特に感謝したいと思います。このドキュメントに逐語的に組み込まれています。Paul Knightは、テキストをXML形式に変換するという骨の折れるタスクを実行しました。
[1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[1] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Maughan、D.、Schneider、M。、およびM. Schertler、「インターネットセキュリティ協会および主要管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[3] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[6] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[6] Piper、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[8] Postel、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] Deering、S。and 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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（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] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子としてのX.509拡張機能」、RFC 3779、2004年6月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[14] Kent、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] Fuller、V。およびT. Li、「クラスレスインタードメインルーティング（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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[17] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[17] Hoffman、P。and B. Schneier、「インターネットプロトコルにおける暗号化に対する攻撃」、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、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、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月。
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がデコードに失敗した場合、関連証明書に対してさらなる取り消しチェックは実行されません。この問題は、Delta CRLSを理解していない実装が、重要な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
o CRLに認識されていない重要な拡張機能が含まれておらず、証明書がCRLにある場合は、証明書ステータスを設定して取り消されます
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]証明書プロファイルを参照してください。
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).
使用する証明書（異なるアクセス許可を与えるような証明書など）に実際の違いがある場合、クライアントはとにかく構成する必要があります。したがって、管理者の特権は、admin certを使用する必要があります。または、通常の電子メールの特権が問題ない場合は、電子メールのみ証明書を使用します）。
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つの証明書を持っているため、送信します。残りのケースの90％では、同じCAまたは同じ企業VPNの異なるCAの単なる異なる証明書であるため、証明書のいずれかは問題ありません。
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 Responderは、CAでCERTREQを送信し、SPDでIPマッチをチェックすること、曖昧なケースで使用するデフォルトのCASセットなどを最初に行うことができます。
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".
o 空のcertreqを送信することは、今日の実装ではかなり一般的であり、一般的に「証明書を送ってください。
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 残りのユースケースでは、上記の他のすべてではないにしても、イニシエーターはどの証明書を送信するかを明示的に構成するため、空の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
ACME Company Policy（Gateway A）エンジニアリングは10.1.1.0信頼できるCA：CA-A、信頼できるユーザー：OU =エンジニアリングパートナーが20.1.1.0信頼できるCA：CA-B、信頼できるユーザー：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 Company Policy（Gateway B）販売は30.1.1.0信頼できるCA：CA-C、信頼できるユーザー：OU =セールスパートナーが40.1.1.0信頼できるCA：CA-B、信頼できるユーザー：OU = BizCopartnersにアクセスできます
You are an employee of Acme and you are issued the following certificates:
あなたはACMEの従業員であり、次の証明書が発行されます。
o From CA-A: CN=JoeUser,OU=Engineering o From CA-B: CN=JoePartner,OU=BizcoPartners
o CA-Aから：CN = JOEUSER、OU = Engineering O CA-B：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に接続しようとすると、すべてが機能します... CA-BまたはCA-Cが署名した証明書で応答することで提示されているため... CA-Bからの証明書のみがあるため、大丈夫です。ACMEに接続しようとすると、あいまいなポリシー選択が提示されているため、問題があります。イニシエーターとして、CA-AとCA-Bの両方からの証明書要求が提示されます。両方のCASが発行する証明書がありますが、使用可能な証明書の1つだけが発行されます。クライアントは、どの証明書を提示すべきかをどのようにして知っていますか？それが開始する接続に対して提示する資格情報を指定するローカルポリシーを十分に明確にする必要があります。
Author's Address
著者の連絡先
Brian Korver Network Resonance, Inc. 2483 E. Bayshore Rd. Palo Alto, CA 94303 US
Brian Korver Network Resonance、Inc。2483 E. Bayshore Rd。パロアルト、CA 94303 US
Phone: +1 650 812 7705
EMail: briank@networkresonance.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。