Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 6494 Cisco Systems
Updates: 3971 S. Krishnan
Category: Standards Track Ericsson
ISSN: 2070-1721 A. Kukec
Enterprise Architects
February 2012
Certificate Profile and Certificate Management for
SEcure Neighbor Discovery (SEND)
Abstract
抽象
SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND.
セキュアな近隣探索（SEND）は、ルータの認証を実行するためのX.509v3証明書を利用しています。この文書では、SENDに必要な拡張キー使用の値と一緒にリソース証明書に基づいてSENDのための証明書プロファイルを指定します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6494.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6494で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Terminology .....................................................3
4. SEND Certificate Profile ........................................4
4.1. Unconstrained Certified Subnet Prefixes ....................4
5. Deployment Models ...............................................5
6. Trust Anchor Material ...........................................5
7. Extended Key Usage Values .......................................6
8. CRL Profile and Revocation ......................................7
8.1. Online Certificate Status Protocol (OCSP) Considerations ...7
9. Certificate Validation ..........................................8
10. IANA Considerations ............................................8
11. Security Considerations ........................................8
12. Acknowledgements ...............................................8
13. References .....................................................9
13.1. Normative References ......................................9
13.2. Informative References ....................................9
Appendix A. Router Authorization Certificate Example ..............10
Appendix B. ASN.1 Module ..........................................11
SEcure Neighbor Discovery (SEND) [RFC3971] utilizes X.509v3 certificates that include the [RFC3779] extension for IPv6 addresses to certify a router's authorization to advertise the IPv6 prefix for the Neighbor Discovery (ND) protocol. The SEND specification defines a basic certificate profile for SEND. The certificate profile defined in this document supersedes the profile for Router Authorization Certificates specified in [RFC3971]. That is, certificates used in SEND (by routers, proxies, or address owners) MUST conform to this certificate profile and MAY conform to the original profile in [RFC3971].
セキュアな近隣探索（SEND）[RFC3971]は、[RFC3779]はIPv6の拡張は、近隣探索（ND）プロトコルのIPv6プレフィックスを通知するルータの承認を証明するためにアドレスを含めるのX.509v3証明書を利用しています。 SEND仕様は、SENDのための基本的な証明書プロファイルを定義します。この文書で定義された証明書プロファイルは、[RFC3971]で指定されたルータ認可証明書のプロファイルを優先します。すなわち、（ルータ、プロキシ、又はアドレス所有者）SENDに使用される証明書は、この証明書プロファイルに従わなければなりませんし、[RFC3971]で元のプロファイルに準拠していてもよいです。
The Resource Public Key Infrastructure (RPKI) is the global PKI that attests to the allocation of IP address space. The RPKI represents the centralized model discussed in Section 6.2 of [RFC3971]. Consequently, SEND will use the RPKI Certificate Profile and certificate validation detailed in [RFC6487]. Consequently, the certificate validation method described in [RFC3971] is updated with the certificate validation method in [RFC6487].
リソース公開鍵インフラストラクチャ（RPKI）は、IPアドレス空間の割り当てを証明グローバルPKIです。 RPKIは[RFC3971]のセクション6.2で説明した集中型モデルを示しています。したがって、SENDはRPKI証明書プロファイルと[RFC6487]に詳述された証明書の検証を使用します。したがって、[RFC3971]に記載の証明書検証方法は、[RFC6487]に証明書の検証方法を用いて更新されます。
Since the [RFC3779] IPv6 address extension does not mention what functions the node can perform for the certified IPv6 space, it becomes impossible to know the reason for which the certificate was issued. In order to facilitate issuance of certificates for specific functions, it is necessary to utilize the ExtKeyUsageSyntax field (optional in RPKI certificates) of the X.509 certificate to mention why the certificate was issued. This document specifies four extended key usage values -- one for routers, two for proxies, and one for address owners -- for use with SEND.
[RFC3779]のIPv6アドレス拡張が認定されたIPv6スペースで実行できるノードを機能何を言及していないので、それは証明書が発行された理由を知ることが不可能になります。特定の機能のための証明書の発行を容易にするためには、証明書が発行された理由を言及するX.509証明書の（RPKI証明書ではオプション）ExtKeyUsageSyntaxフィールドを利用する必要があります。ルータのための1つ、プロキシの2、およびアドレスの所有者のための1 - - SENDで使用するためにこの文書では、4つの拡張キー使用法値を指定します。
In RFC 3971, two deployment models were described: centralized and decentralized. This document describes the different deployment models that can be used with the SEND certificates defined here.
RFC 3971では、2つの展開モデルが記述された：中央集中型と分散型。このドキュメントでは、ここで定義されSEND証明書で使用できるさまざまな展開モデルについて簡単に説明します。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Certified IPv6 address space IPv6 address space included in an X.509v3 certificate using the extension for IPv6 addresses [RFC3779].
IPv6アドレス[RFC3779]のための拡張機能を使用してX.509v3証明書に含ま認定IPv6アドレススペースのIPv6アドレス空間。
End-entity (EE) An entity in the PKI that is not a Certification Authority (CA).
エンドエンティティ（EE）証明機関（CA）ではありませんPKI内のエンティティ。
ISP Internet Service Provider.
ISPインターネットサービスプロバイダ。
NIR National Internet Registry.
NIR国別インターネットレジストリ。
RIR Regional Internet Registry.
RIR地域インターネットレジストリ。
RPKI Resource PKI established in accordance with [RFC6480].
RPKIリソースPKIは、[RFC6480]に基づいて設立します。
RPKI certificates Certificates as defined in [RFC6487].
[RFC6487]で定義されるようRPKI証明書を証明書。
SEND certificates Certificates as described in [RFC3971] and extended in this document. They are end-entity certificates that belong either to SEND routers, SEND hosts, or SEND proxies:
[RFC3971]に記載され、本書で拡張として証明書の証明書を送信します。彼らは、ルータを送信するホストを送ったり、プロキシを送信するためにどちらかの所属エンドエンティティ証明書です：
* Router Authorization Certificates as
defined in [RFC3971].
* Owner Authorization Certificates as defined in [RFC3971].
*所有者の許可証明書は、[RFC3971]で定義されています。
* Secure Proxy ND Certificates as defined in [RFC6496].
[RFC6496]で定義されるよう*プロキシND証明書を固定します。
SEND KeyPurposeId An Extended Key Usage (EKU) value for SEND, such as the four introduced in this document.
このよう本書で紹介し4として、SEND用KeyPurposeIdアンに拡張キー使用法（EKU）の値を送信します。
SEND certificates MUST comply with the RPKI resource profile described in [RFC6487]. A Router Authorization Certificate example is included in Appendix A.
SEND証明書は、[RFC6487]に記載RPKIリソースプロファイルに従わなければなりません。ルータの認証証明書の例は、付録Aに含まれています
In Sections 2, 4.9.10, and 4.9.11 of [RFC6487], it is stated that RFC 3779 resource extensions MUST be marked as critical and MUST be present in all resource certificates. SEND certificates MUST include the IP Address Delegation extension [RFC3779]. This extension MUST include at least one address block for the IPv6 Address Family (AFI=0002), as described in Section 4.9.10 of [RFC6487]. SEND certificates MUST NOT have more than one IP Address Delegation extension.
セクション2、4.9.10、および[RFC6487]の4.9.11では、RFC 3779、リソースの拡張はそれほど重要でマークする必要があり、すべてのリソース証明書の中に存在しなければならないと述べています。 SENDの証明書は、IPアドレス委任拡張[RFC3779]を含まなければなりません。 [RFC6487]のセクション4.9.10に記載されているように、この拡張は、IPv6アドレスファミリ（AFI = 0002）のための少なくとも1つのアドレスブロックを含まなければなりません。 SENDの証明書は、複数のIPアドレス委任拡張を持ってはいけません。
Section 7.3 of [RFC3971] defines the Unconstrained Certified subnet prefixes category by using certificates containing either the null prefix or no prefix extension at all.
[RFC3971]のセクション7.3はヌル接頭辞または全く接頭辞拡張子のいずれかを含む証明書を使用して、制約のない公認サブネットプレフィックスのカテゴリを定義します。
When using the RPKI Certificate Profile, prefix extensions are mandatory and the null prefix MUST be validated. However, a certificate may inherit its parent's prefix or range by using the "inherit" element for the IPv6 Address Family Identifier (AFI) as defined in [RFC3779]. The use of the "inherit" element is permitted in [RFC6487].
RPKI証明書プロファイルを使用する場合は、接頭辞の拡張機能は必須で、nullの接頭辞を検証する必要があります。 [RFC3779]で定義されるようしかし、証明書は、IPv6の「継承」要素を使用して、親の接頭辞または範囲を継承することができる、ファミリー識別子（AFI）をアドレス。 「継承」要素の使用は[RFC6487]で許可されています。
Consequently, this document updates Section 7.3 of [RFC3971], adding the following text under Unconstrained:
そのため、このドキュメントでは、制約なしの下に次のテキストを追加し、[RFC3971]のセクション7.3を更新します。
Network operators that do not want to constrain routers to route particular subnet prefixes, but rather inherit those prefixes from the routers' parent certificates, should configure routers with certificates containing the "inherit" element for the IPv6 AFI.
IPv6のAFIのための 『継承』の要素を含む証明書でルーターを設定する必要があり、ルートの特定のサブネットプレフィックスにルータを制約するのではなく、ルータの親証明書からこれらの接頭辞を継承したくないネットワークオペレータ。
RFC 3971 describes two deployment models: centralized and decentralized. These models were differentiated by having one trust anchor or many trust anchors. In this document, we introduce two new deployment models not based on the number of trust anchors but on the localization of the SEND deployment.
中央集中型と分散型：RFC 3971には、2つの展開モデルについて簡単に説明します。これらのモデルは、1つのトラストアンカーまたは多くの信頼アンカーを持つことによって分化させました。この文書では、我々は信頼アンカーの数ではなく、SEND展開の局在に基づいていない二つの新しい展開モデルをご紹介します。
The local SEND deployment model represents those cases where SEND deployment is confined to an administrative domain. In this scenario, the deployment of SEND MAY be done independently of the existence of deployment in the upper RPKI hierarchy (i.e., an end user could perform local SEND deployment without the need for RPKI deployment in its ISP). This model requires the use of local trust anchors and configuring islands of trust. This model MAY include Unique Local Addresses (ULAs) [RFC4193].
ローカルSEND導入モデルは、SENDの展開が管理ドメインに限定され、それらの例を表しています。このシナリオでは、SENDの展開が上部RPKI階層の展開の有無とは無関係に行うことができる（すなわち、エンドユーザは、そのISPにRPKI展開を必要とすることなくローカルSEND展開を実行することができます）。このモデルは、ローカルのトラストアンカーと信頼の設定島々を使用する必要があります。このモデルは、ユニークローカルアドレス（ULAs）[RFC4193]を含むかもしれません。
The public SEND deployment models represent those cases where SEND deployment is linked to RPKI deployment as described in [RFC6480]. Trust anchor material MAY be part of a different administrative domain (i.e., RIRs, NIRs, or ISPs). It is a global model suitable for mobile users.
公共SEND展開モデルは、[RFC6480]に記載されているようにSEND展開がRPKI展開にリンクされているような場合を表します。トラストアンカー材料は、異なる管理ドメイン（すなわち、のRIR、のNIR、またはISPの）の一部であってもよいです。これは、モバイルユーザーに適したグローバルモデルです。
These two models are not mutually exclusive. It is entirely possible to have a hybrid model that incorporates features from both of these models. In one such hybrid deployment model, most IP address resources (e.g., global unicast addresses) would be certified under the global RPKI, while some others (e.g., ULAs) are certified under local trust anchors.
これらの2つのモデルが相互に排他的ではありません。これらのモデルの両方から機能を組み込んだハイブリッドモデルを持つことは完全に可能です。いくつか他の人が（例えば、ULAs）はローカルトラストアンカーの下で認定されながら、そのようなハイブリッド展開モデルでは、ほとんどのIPアドレスリソース（例えば、グローバルユニキャストアドレス）は、グローバルRPKIの下で認定されるだろう。
Relying parties (e.g., end hosts that implement SEND and process these router certificates) MUST be configured with one or more trust anchors to enable validation of the routers' certificates. [RFC6495] and Section 6.5 of [RFC3971] list the trust anchor configuration options for end hosts using SEND.
依拠当事者は、（実装例えば、エンドホストが送信し、これらのルータの証明書を処理する）は、1つまたは複数の信頼を使用して構成されなければならないルータの証明書の検証を可能にするためにアンカー。 [RFC6495]と[RFC3971]のセクション6.5には、SENDを使用して、エンドホストのトラストアンカーの設定オプションの一覧を表示します。
In the local SEND deployment model, it is possible to use as a trust anchor a certificate that includes in its RFC 3779 address extension the prefix ::/0. In this case, no new trust anchor material would be needed when renumbering. However, if trying to move from the local deployment model to the public deployment model, new trust anchor material will have to be distributed to relying parties.
ローカルSEND展開モデルでは、トラストアンカーとしてのRFC 3779アドレス拡張プレフィックス:: / 0に含まれる証明書を使用することが可能です。リナンバリングこの場合には、新しいトラストアンカー材料が必要とされないであろう。しかし、公共の展開モデルにローカルな展開モデルから移動しようとした場合、新しいトラストアンカー材料は、依拠当事者に配布する必要があります。
The Internet PKI document [RFC5280] specifies the extended key usage X.509 certificate extension. The extension indicates one or more purposes for which the certified public key may be used. The extended key usage extension can be used in conjunction with the key usage extension, which indicates the intended purpose of the certified public key. The EKU extension is defined as optional in [RFC6487] for end-entity certificates but MUST be present when issuing end-entity certificates for SEND.
インターネットPKIのドキュメント[RFC5280]は、拡張キー使用法のX.509証明書拡張を指定します。拡張子は、認定公開鍵が使用される1つのまたは複数の目的を示します。拡張鍵使用拡張が証明される公開鍵の意図された目的を示す鍵使用拡張と併せて使用することができます。 EKU拡張は、エンドエンティティ証明書の[RFC6487]でオプションとして定義されているが、SENDのためのエンドエンティティ証明書を発行する際に存在しなければなりません。
The extended key usage extension syntax is repeated here for convenience:
拡張鍵用途拡張構文は利便性のためにここで繰り返されます。
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
This specification defines four KeyPurposeId values: one for authorizing routers (Router Authorization Certificates), two for authorizing proxies (Secure Proxy ND Certificates), and one for address owners (Owner Authorization Certificates). Additional KeyPurposeId values may be specified in Standards Track documents.
許可ルータのための1つ（ルータ認可証明）、2つのプロキシを許可する（プロキシND証明書をセキュア）、及びアドレスの所有者のための1つの（所有者の認可証明）：この仕様は、4つのKeyPurposeId値を定義します。追加KeyPurposeId値は標準化過程文書で指定することができます。
The inclusion of the router authorization value (id-kp-sendRouter) indicates that the certificate has been issued for allowing the router to generate Router Advertisement (RA) and Redirect messages for any prefix(es) encompassed (as defined in Section 7.1 of [RFC6487]) by the IP address space included in the X.509 extensions for IP addresses.
ルータ認証値（ID-KP-sendRouter）の包含は、証明書をルータ広告（RA）を生成し、任意の接頭語（es）のセクション7.1で定義されるように（包含のためにメッセージをリダイレクトするルータを可能にするために発行されたことを示します[ IPアドレスのX.509拡張に含まれるIPアドレス空間によってRFC6487]）。
The inclusion of the proxied routing authorization value (id-kp-sendProxiedRouter) indicates that the certificate has been issued for allowing the proxy to perform proxying of RA and Redirect messages for any prefix(es) encompassed by the IP address space included in the X.509 extensions for IP addresses.
プロキシルーティング許可値（ID-KP-sendProxiedRouter）の包含は、証明書がプロキシがRAのプロキシを実行し、任意のプレフィックスのためのメッセージをリダイレクトすることを可能にするために発行されたことを示す（ES）Xに含まれるIPアドレス空間に包含されますIPアドレスの0.509の拡張機能。
The inclusion of the owner authorization value (id-kp-sendOwner) indicates that the certificate has been issued for allowing the node to use any address(es) that is/are encompassed by the IP address space included in the X.509 extensions for IP addresses. For an address in such a certificate, the node can assign the address to an interface; send/receive traffic from/to this address; and send/ respond to NS, NA, and RS messages related to that address.
所有者認証値（ID-KP-sendOwner）を含めることは、証明書がノード/用X.509拡張子に含まれるIPアドレス空間に含まれる任意のアドレスを使用することを可能にするために発行されたことを示しIPアドレス。そのような証明書のアドレスのために、ノードは、インタフェースにアドレスを割り当てることができます。このアドレスへの/からのトラフィックを受信/送信。そしてNS、NA、およびそのアドレスに関連するRSメッセージに応答/送信。
The inclusion of the proxied owner authorization value (id-kp-sendProxiedOwner) indicates that the certificate has been issued for allowing the proxy to perform proxying of Neighbor
プロキシ所有者認証値（ID-KP-sendProxiedOwner）の包含は、証明書がプロキシが近隣のプロキシを実行することを可能にするために発行されたことを示し
Solicitation (NS), Neighbor Advertisement (NA), and Router Solicitation (RS) messages for any address encompassed by the IP address space included in the X.509 extensions for IP addresses.
要請（NS）、IPアドレス空間に包含される任意のアドレスのための近隣広告（NA）、およびルーター要請（RS）メッセージには、IPアドレスのX.509の拡張に含まれています。
send-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxiedRouter OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }
id-kp-sendProxiedOwner OBJECT IDENTIFIER ::= { id-kp 26 }
As described in [RFC6487], the extended key usage extension, if present, MUST be non-critical.
[RFC6487]に記載されているように、拡張鍵使用拡張は、存在する場合、ノンクリティカルでなければなりません。
Relying parties MUST require the extended key usage extension to be present in a certificate, and they MAY require a particular KeyPurposeId value to be present (such as id-kp-sendRouter or id-kp-sendProxiedRouter) within the extended key usage extension. If multiple KeyPurposeId values are included, the relying parties need not recognize all of them, as long as the required KeyPurposeId value is present. Relying parties MUST reject certificates that do not contain at least one SEND KeyPurposeId, even if they include the anyExtendedKeyUsage OID defined in [RFC5280].
依拠当事者は、証明書中に存在する拡張鍵使用拡張を必要としなければならない、と彼らは、拡張鍵使用拡張内（例えばID-KP-sendRouterまたはID-KP-sendProxiedRouterとして）存在することが特定のKeyPurposeId値を必要とする場合があります。複数KeyPurposeId値が含まれている場合は、依拠当事者は限り必要KeyPurposeId値が存在しているとして、それらのすべてを認識する必要はありません。依拠当事者は、彼らが[RFC5280]で定義されたanyExtendedKeyUsage OIDが含まれていても、少なくとも一つのSEND KeyPurposeIdが含まれていない証明書を拒絶しなければなりません。
RPKI requires the use of Certificate Revocation Lists (CRLs) [RFC6487]. The host will obtain the necessary CRLs and perform the certificate validation method described in [RFC6487].
RPKIは、証明書失効リスト（CRL）[RFC6487]を使用する必要があります。ホストは、必要なCRLを取得して、[RFC6487]に記載の証明書検証方法を実行します。
A host MAY use OCSP [RFC2560] to verify the revocation status of a certificate.
ホストは、証明書の失効状態を確認するOCSP [RFC2560]を使用するかもしれ。
As [RFC6487] is adopted as the base certificate profile for SEND, the host SHOULD NOT assume that certificates will include the URI of an OCSP server as part of its Authority Information Access (AIA) extension. This is particularly evident in the SEND public deployment model, as OCSP services are not required by [RFC6484].
[RFC6487]はSENDのベース証明書プロファイルとして採用されるように、ホストは、証明書が機関情報アクセス（AIA）拡張の一部として、OCSPサーバのURIが含まれると仮定すべきではありません。 OCSPサービスは[RFC6484]によって必要とされないので、これは、SEND公共展開モデルにおいて特に明らかです。
This section updates Section 6.3.1 of [RFC3971] by introducing new validations without introducing any conflict.
このセクションでは、任意の競合を導入することなく、新たな検証を導入することにより、[RFC3971]のセクション6.3.1を更新します。
The host MUST perform the certificate validation method described in [RFC6487]. The validation of certificates that use the "inherit" element where the existence of a parent prefix or range is required is described in [RFC3779].
ホストは、[RFC6487]に記載の証明書検証方法を実行しなければなりません。親プレフィックスまたは範囲の存在が必要とされる「継承」要素を使用する証明書の検証は、[RFC3779]に記載されています。
The host MUST verify that the KeyPurposeId value corresponding to the Neighbor Discovery message type is present, as described in Section 7.
ホストは、第7節に記載されるように近隣探索メッセージタイプに対応するKeyPurposeId値が存在することを確かめなければなりません。
This document makes use of object identifiers to identify EKUs and the ASN.1 (Abstract Syntax Notation One) module found in Appendix B. The EKUs and ASN.1 module OID are registered in an arc delegated by IANA to the PKIX Working Group.
この文書は、オブジェクト識別子の使用は、PKIXワーキンググループにIANAによって委任されたアークに登録されている付録BザのEKUとASN.1モジュールOIDに見出さのEKUとASN.1（抽象構文記法1）モジュールを識別することができます。
The certification authority needs to ensure that the correct values for the extended key usage are inserted in each certificate that is issued. Relying parties may accept or reject a particular certificate for an intended use based on the information provided in these extensions. Incorrect representation of the information in the extended key usage field can cause the relying party to reject an otherwise appropriate certificate or accept a certificate that ought to be rejected. In particular, since a SEND certificate attests that its subject is authorized to play a given role in the SEND protocol, certificates that contain incorrect EKU values can enable some of the same attacks that SEND was meant to prevent. For example, if a malicious host can obtain a certificate that authorizes it to act as a router for a given prefix, then it can masquerade as a router for that prefix, e.g., in order to attract traffic from local nodes.
認証局は、拡張キー使用法の正しい値が発行された証明書ごとに挿入されていることを確認する必要があります。依拠当事者は、これらの拡張機能で提供される情報に基づいて、使用目的のために特定の証明書を受け入れるか拒否することができます。拡張キー使用法フィールドの情報の不正確な表現がそうでない場合は、適切な証明書を拒否または却下されるべきである証明書を受け入れるために依存者を引き起こす可能性があります。 SEND証明書はその被写体がSENDプロトコルに与えられた役割を果たして許可されていることを証明するため、特に、間違ったEKU値を含む証明書は、SENDを防ぐためのものだったのと同じ攻撃の一部を有効にすることができます。悪質なホストは、それが与えられたプレフィックスのルータとして動作するように許可証明書を取得できた場合、それはローカルノードからのトラフィックを誘致するために、例えば、そのプレフィックスのルータになりすますことができます。
The authors would like to thank Alberto Garcia, Stephen Kent, Sean Turner, Roni Even, Richard Barnes, Alexey Melnikov, Jari Arkko, David Harrington, and Tim Polk for their reviews and suggestions on the earlier versions of this document.
作者はこのドキュメントの以前のバージョンの彼らのレビューと提案のためのアルベルト・ガルシア、スティーブン・ケント、ショーン・ターナー、ロニでも、リチャード・バーンズ、アレクセイ・メルニコフ、ヤリArkko、デヴィッド・ハリントン、およびティムポークに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2560] 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.
[RFC2560]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]リン、C.、ケント、S.、およびK.ソ、 "IPアドレスとAS識別子のためのX.509拡張機能"、RFC 3779、2004年6月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012.
[RFC6484]ケント、S.、香港、D.、ソ、K.、およびR. Watro、 "リソースの公開鍵インフラストラクチャ（RPKI）のための証明書ポリシー（CP）"、BCP 173、RFC 6484、2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]ヒューストン、G.、マイケルソン、G.、およびR. Loomans、 "X.509 PKIXリソース証明書のプロファイル"、RFC 6487、2012年2月。
[RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields", RFC 6495, February 2012.
[RFC6495]ガリアーノ、R.、クリシュナン、S.、およびA. Kukec、 "サブジェクトキー識別子（SKI）セキュア近隣探索（SEND）名前タイプフィールド"、RFC 6495、2012年2月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M.とS.ケント、 "安全なインターネットルーティングをサポートするインフラストラクチャ"、RFC 6480、2012年2月。
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-Martinez, "Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)", RFC 6496, February 2012.
[RFC6496]クリシュナン、S.、Laganier、J.、ボノーラ、M.、およびA.ガルシア・マルティネス、2012年2月、RFC 6496 "セキュア近隣探索（SEND）のプロキシNDサポートセキュア"。
Appendix A. Router Authorization Certificate Example
付録A.ルータの認証証明書の例
Certificate: Data: Version: 3 (0x2) Serial Number: 249 (0xf9) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=EXAMPLE-CA-2342342652346 Validity Not Before: Jul 2 10:06:32 2010 GMT Not After : Jul 2 10:06:32 2011 GMT Subject: CN=SEND-EXAMPLE-123432 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b7:06:0d:8e:f7:39:0a:41:52:93:59:a8:f5:63: 3f:2e:3d:24:17:9d:19:aa:09:ff:c0:2a:f3:c6:99: d7:34:0d:bf:f1:e9:73:b5:8f:dc:d4:91:d6:5d:cb: 9c:b8:2b:41:63:c1:8f:f7:48:54:02:89:07:24:c3: b0:6e:11:5a:7d:c0:38:88:4b:d9:3b:93:c7:ca:4d: a4:00:a2:d3:6d:14:15:8f:15:08:4d:4e:b3:8a:cc: de:2d:e0:7a:9b:c0:6e:14:f6:a7:ae:b9:e0:c5:18: 60:75:3d:d3:50:00:47:0d:86:5b:1c:a0:85:81:af: 2b:84:98:49:7d:60:a2:e8:4f:6d:40:ba:d5:fe:de: de:41:53:c7:c4:f4:d3:1a:41:cd:dc:9f:08:43:33: 48:00:57:e4:56:93:7d:dd:19:12:e8:bf:26:b3:4b: 30:ac:b8:9c:b1:37:05:18:3c:7b:6b:26:d7:c9:15: c9:4a:eb:1b:fa:92:38:46:27:44:96:8a:a1:12:c1: 09:77:4a:7b:a5:07:88:a6:36:30:98:70:79:b6:44: 7e:b1:c9:4c:5b:11:56:e8:14:50:f7:f8:e5:ed:f1: ac:a4:31:46:36:77:05:c9:63:fe:c3:ab:54:e2:bd: 79:1d:14:d1:c2:80:36:d3:be:e6:c7:a2:47:59:1b: 75:9f Exponent: 65537 (0x10001)
証明書：データ：バージョン：3（0x2の）シリアル番号：249（0xf9）署名アルゴリズム：sha256WithRSAEncryption発行者：前ではなくCN =例-CA-2342342652346妥当性：7月2日10時06分32秒2010 GMTない後：7月2日10： 6時32分2011 GMT件名：CN = SEND-EXAMPLE-123432サブジェクト公開鍵情報：公開鍵アルゴリズム：rsaEncryption公開鍵：（2048ビット）モジュラス：00：B7：06：0D：8E：F7：39：0A： 41：52：93：59：A8：F5：63：3F：2E：3D：24：17：9D：19：AA：09：FF：C0：2A：F3：C6：99：D7：34：0D： BF：F1：E9：73：B5：8F：DC：D4：91：D6：5D：CB：9C：B8：2B：41：63：C1：8F：F7：48：54：02：89：07： 24：C3：B0：6E：11：5A：7D：C0：38：88：4B：D9：3B：93：C7：CA：4D：A4：00：A2：D3：6D：14：15：8F： 15：08：4D：4E：B3：8A：CC：デ：2D：E0：7A：9B：C0：6E：14：F6：A7：AE：B9：E0：C5：18：60：75：3D： D3：50：00：47：0D：86：5B：1C：A0：85：81：AF：2B：84：98：49：7D：60：A2：E8：4F：6D：40：BA：D5： FE：デ：デ：41：53：C7：C4：F4：D3：1A：41：CD：DC：9F：08：43：33：48：00：57：E4：56：93：7D：DD： 19：12：E8：BF：26：B3：4B：30：AC：B8：9C：B1：37：05：18：3C：7B：6B：26：D7：C9：15：C9：4A：EB：図1b：FA：92：38：46：27：44：96：8A：A1：12：C1：09：77：4A：7B：A5：07：88：A6：36：30：98：70：79： B6：44：7E：B1：C 9：4C：5B：11：56：E8：14：50：F7：F8：E5：ED：F1：AC：A4：31：46：36：77：05：C9：63：FE：C3：AB： 54：E2：BD：79：1D：14：D1：C2：80：36：D3は：であり：E6：C7：A2：47：59：1B：75：指数9F：65537（0x10001）
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:4C:5D:56:82:15:8A:67:A6:8C:69:67:68:88
:6F:15:E5:C9:96:58:EB
X509v3 CRL Distribution Points:
書X509v3 CRL配布ポイント：
Full Name:
URI:rsync://rsync.example.exampledomain/
EXAMPLE-CA-2342342652346/EXAMPLE-CA.crl
X509v3 Subject Key Identifier: B8:69:EB:36:23:F1:C4:21:65:DD:13:76:EE:90:AF :F7:CD:E3:61:CD X509v3 Key Usage: critical Digital Signature sbgp-ipAddrBlock: critical IPv6: 2001:db8:cafe:bebe::/64
書X509v3件名キー識別子：B8：69：EB：36：23：F1：C4：21：65：DD：13：76：EE：90：AF：F7：CD：E3：61：CD書X509v3キー使用法：重要なデジタル署名sbgp-ipAddrBlock：重要なのIPv6：2001：DB8：カフェ：BEBE :: / 64
X509v3 Extended Key Usage: 1.3.6.1.5.5.7.3.23 Signature Algorithm: sha256WithRSAEncryption 92:14:38:6e:45:83:1b:cb:7c:45:0d:bc:7f:6e:36:bf:82:cc: 7e:00:91:ea:f4:24:43:cc:00:3c:3f:c2:99:0c:c6:b9:20:2e: ca:dc:df:94:0d:c9:a1:75:c4:5c:39:a1:cf:9f:e1:40:9c:aa: a9:80:76:d1:3a:91:d9:db:2f:cd:3c:05:50:52:eb:28:47:d0: ab:d3:fd:6f:30:17:16:7f:c6:0f:2b:25:bb:db:29:d7:bb:4e: f3:7c:2d:e1:04:b7:f0:bc:d5:8a:ba:8c:0d:39:22:48:02:d1: 67:fb:35:5c:b6:83:03:63:7c:73:03:70:20:de:fb:d7:12:ed: 6f:a1:ff:b2:a6:39:fb:55:9a:07:bd:68:40:0f:6f:d5:24:34: cf:e8:dd:76:33:2a:d0:b9:1b:ae:a8:68:86:17:f8:13:35:0e: f6:04:ec:2a:39:88:06:70:c6:e8:56:87:f7:35:54:2a:28:2c: 92:47:a9:89:39:d7:72:24:21:9d:02:52:f9:7c:76:7f:e9:cd: 09:6e:82:f4:da:6c:f9:72:b2:64:98:b5:0c:6a:38:8d:81:e5: fc:50:46:6f:38:40:56:06:92:5a:e0:86:5d:55:f5:7b:85:b2: 68:4f:49:72:e0:fa:2c:bf:9e:7d:aa:28:17:ca:04:b8:ae:69: c9:04:28:12
1.3.6.1.5.5.7.3.23署名アルゴリズム：書X509v3鍵使用拡張sha256WithRSAEncryptionを92：14：38：6E：45：83：1B：CB：7C：45：0D：BC：7F：6E：36：BF： 82：CC：7E：00：91：EA：F4：24：43：CC：00：3C：3F：C2：99：0C：C6：B9：20：2E：CA：DC：DF：94：0D： C9：A1：75：C4：5C：39：A1：CF：9F：E1：40：9C：AA：A9：80：76：D1：3A：91：D9：DB：2F：CD：3C：05： 50：52：EB：28：47：D0：AB：D3：FD：6F：30：17：16：7F：C6：0F：2B：25：BB：DB：29：D7：BB：4E：F3： 7C：2D：E1：04：B7：F0：BC：D5：8A：BA：8C：0D：39：22：48：02：D1：67：FB：35：5（c）：B6：83：03：63： 7C：73：03：70：20：デ：FB：D7：12：ED：6F：A1：FF：B2：A6：39：FB：55：9A：07：BD：68：40：0F：6F： D5：24：34：CF：E8：DD：76：33：2A：D0：B9：1B：AE：A8：68：86：17：F8：13：35：0E：F6：04：EC：2A： 39：88：06：70：C6：E8：56：87：F7：35：54：2A：28：C：92：47：A9：89：39：D7：72：24：21：9D：02： 52：F9：7C：76：7F：E9：CD：09：6E：82：F4：DA：6C：F9：72：B2：64：98：B5：0C：6A：38：8D：81：E5： FC：50：46：6F：38：40：56：06：92：5A：E0：86：5D：55：F5：7B：85：B2：68：4F：49：72：E0：FA：C： BF：9E：7D：AA：28：17：CA：04：B8：AE：69：C9：04：28：12
Appendix B. ASN.1 Module
付録B. ASN.1モジュール
SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-send-cert-extns(71) }
SENDCertExtns {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-送信-CERT-extns（71） }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- OID Arc
- OIDアーク
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
-- Extended Key Usage Values
- 拡張キー使用法値
id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxiedRouter OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }
id-kp-sendProxiedOwner OBJECT IDENTIFIER ::= { id-kp 26 }
END
終わり
Authors' Addresses
著者のアドレス
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle 1180 Switzerland
ロケガリアーノシスコシステムズアベニューデUttins 5ロル1180スイス
EMail: rogaglia@cisco.com
メールアドレス：rogaglia@cisco.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
スレシュクリシュナンエリクソン8400 Decarie大通りマウントロイヤル、QCカナダの町
Phone: +1 514 345 7900 x42871 EMail: suresh.krishnan@ericsson.com
電話：+1 514 345 7900 x42871メール：suresh.krishnan@ericsson.com
Ana Kukec Enterprise Architects 46/525 Collins St. Melbourne, VIC 3000 Australia
アナKukecエンタープライズアーキテクト525分の46コリンズセントメルボルン、VIC 3000オーストラリア
EMail: ana.kukec@enterprisearchitects.com
メールアドレス：ana.kukec@enterprisearchitects.com