[要約] RFC 6494は、SEcure Neighbor Discovery（SEND）のための証明書プロファイルと証明書管理に関する規格です。その目的は、SENDプロトコルのセキュリティを向上させるために、証明書のプロファイルと管理方法を定義することです。
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.
Secure Neighbor Discovery（送信）は、ルーター認証を実行するためにX.509V3証明書を利用します。このドキュメントは、リソース証明書に基づいて送信の証明書プロファイルと、送信に必要な拡張キー使用値を指定します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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].
Secure Neighbor Discovery（SEND）[RFC3971]は、IPv6アドレスの[RFC3779]拡張機能を含むX.509V3証明書を利用して、近隣発見（ND）プロトコルのIPv6プレフィックスを宣伝するRouterの許可を認証します。送信仕様は、送信の基本的な証明書プロファイルを定義します。このドキュメントで定義された証明書プロファイルは、[RFC3971]で指定されたルーター認証証明書のプロファイルに取って代わります。つまり、（ルーター、プロキシ、または住所所有者によって）送信で使用される証明書は、この証明書プロファイルに準拠し、[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で説明されている集中モデルを表します。したがって、送信は、[RFC6487]で詳述されているRPKI証明書プロファイルと証明書の検証を使用します。したがって、[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
[RFC3779] IPv6アドレス拡張は、認定されたIPv6スペースに対してノードが実行できる機能について言及していないため、証明書が発行された理由を知ることは不可能になります。特定の機能の証明書の発行を促進するには、extkeyusagesYntaxフィールドを利用する必要があります
(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.
（RPKI証明書ではオプション）X.509証明書の証明書が発行された理由が言及されています。このドキュメントは、sendで使用するための4つの拡張された主要な使用値（ルーター用、1つはプロキシ用、1つはアドレス所有者用）を指定しています。
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つの展開モデルが説明されています。このドキュメントでは、ここで定義されている送信証明書で使用できるさまざまな展開モデルについて説明します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Certified IPv6 address space IPv6 address space included in an X.509v3 certificate using the extension for IPv6 addresses [RFC3779].
認定されたIPv6アドレススペースIPv6アドレススペースIPv6アドレス[RFC3779]の拡張機能を使用してX.509V3証明書に含まれています。
End-entity (EE) An entity in the PKI that is not a Certification Authority (CA).
エンドエンティティ（EE）認証機関ではないPKIのエンティティ（CA）。
ISP Internet Service Provider.
ISPインターネットサービスプロバイダー。
NIR National Internet Registry.
NIR National Internet Registry。
RIR Regional Internet Registry.
RIRリージョナルインターネットレジストリ。
RPKI Resource PKI established in accordance with [RFC6480].
[RFC6480]に従って確立されたRPKIリソースPKI。
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].
* [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の拡張キー使用量（EKU）値をkeypurposeIdに送信します。
SEND certificates MUST comply with the RPKI resource profile described in [RFC6487]. A Router Authorization Certificate example is included in Appendix A.
[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.
[RFC6487]のセクション2、4.9.10、および4.9.11では、RFC 3779リソース拡張が重要であるとマークされ、すべてのリソース証明書に存在する必要があると述べられています。証明書を送信するには、IPアドレス委任拡張子[RFC3779]を含める必要があります。この拡張機能は、[RFC6487]のセクション4.9.10で説明されているように、IPv6アドレスファミリー（AFI = 0002）の少なくとも1つのアドレスブロックを含める必要があります。送信証明書には、複数の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は、NULLプレフィックスまたは接頭辞拡張機能のいずれかを含む証明書を使用して、制約のない認定サブネットプレフィックスカテゴリを定義します。
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つの信頼アンカーまたは多くの信頼アンカーを持つことによって区別されました。このドキュメントでは、信頼のアンカーの数ではなく、送信展開のローカリゼーションに基づいていない2つの新しい展開モデルを導入します。
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の展開は、上部RPKI階層での展開の存在とは無関係に行われる場合があります（つまり、エンドユーザーは、ISPでのRPKI展開を必要とせずにローカル送信展開を実行できます）。このモデルでは、ローカルトラストアンカーの使用と信頼の島の構成が必要です。このモデルには、一意のローカルアドレス（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.
[RFC6480]で説明されているように、送信展開モデルは、送信展開がRPKI展開にリンクされている場合を表します。トラストアンカー材料は、異なる管理ドメイン（つまり、RIRS、NIRS、または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つのモデルは相互に排他的ではありません。これらの両方のモデルの機能を組み込んだハイブリッドモデルを持つことは完全に可能です。このようなハイブリッド展開モデルの1つでは、ほとんどのIPアドレスリソース（グローバルユニキャストアドレスなど）がグローバルRPKIの下で認定され、他の一部（ULA）はローカルトラストアンカーの下で認定されています。
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は、送信を使用したエンドホストのトラストアンカー構成オプションをリストします。
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.
ローカル送信展開モデルでは、RFC 3779のアドレス拡張::/0に含まれる証明書を信頼のアンカーとして使用することができます::/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]でオプションとして定義されていますが、送信のエンドエンティティ証明書を発行するときは存在する必要があります。
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.
この仕様では、4つのKeypurposeID値を定義します。1つはルーター（ルーター認証証明書）を承認するための1つ、プロキシ（セキュアプロキシND証明書）を許可するための2つ、およびアドレス所有者（所有者認証証明書）の場合は1つです。追加の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で定義されている場合も、RFC6487]）IPアドレスのX.509拡張機能に含まれるIPアドレススペースによって。
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）を含めることは、Xに含まれるIPアドレススペースに含まれるプレフィックスのRAのプロキシとリダイレクトメッセージをプロキシを実行できるようにするために証明書が発行されたことを示しています。.509 IPアドレスの拡張機能。
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-SENDENDERNER）を含めることは、ノードが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.
IPアドレスのX.509拡張機能に含まれるIPアドレススペースに含まれるアドレスの勧誘（NS）、Neighbor Advertisement（NA）、およびRouter Solicitation（RS）メッセージ。
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値が存在する限り、それらすべてを認識する必要はありません。頼る当事者は、[RFC5280]で定義されているayextededKeyUsage oidを含む場合でも、少なくとも1つのSendKeypurposeIdを含まない証明書を拒否する必要があります。
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では、証明書取消リスト（CRLS）[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]は送信の基本証明書プロファイルとして採用されているため、ホストは、証明書が権限情報アクセス（AIA）拡張機能の一部としてOCSPサーバーのURIを含めると想定すべきではありません。これは、[RFC6484]ではOCSPサービスが必要ないため、送信パブリック展開モデルで特に顕著です。
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で説明されているように、Neighbor Discoveryメッセージタイプに対応する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.
このドキュメントでは、オブジェクト識別子を使用して、ekusとasn.1（要約構文表記1）を識別して付録Bにあります。EKUSおよびASN.1モジュールOIDは、IANAによってPKIXワーキンググループに委任されたアークに登録されています。
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.
認証機関は、発行される各証明書に拡張されたキー使用量の正しい値が挿入されるようにする必要があります。頼る当事者は、これらの拡張機能で提供される情報に基づいて、意図した使用のために特定の証明書を受け入れるか拒否することができます。拡張された主要な使用状況フィールドでの情報の誤った表現により、頼る当事者は、そうでなければ適切な証明書を拒否したり、拒否すべき証明書を受け入れたりする可能性があります。特に、送信証明書は、その主題が送信プロトコルで特定の役割を果たすことを許可されていることを証明しているため、誤ったEKU値を含む証明書は、送信される同じ攻撃を防ぐことを意図したものを可能にすることができます。たとえば、悪意のあるホストが特定のプレフィックスのルーターとして機能することを許可する証明書を取得できる場合、そのプレフィックスのルーターを装って、たとえばローカルノードからトラフィックを引き付けることができます。
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.
著者は、アルベルト・ガルシア、スティーブン・ケント、ショーン・ターナー、ロニ・イヴ・ロニ、リチャード・バーンズ、アレクセイ・メルニコフ、ジャリ・アークコ、デビッド・ハリントン、ティム・ポークに、この文書の以前のバージョンに関するレビューと提案に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、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] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子としての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.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカル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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet 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] Kent、S.、Kong、D.、Seo、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] Huston、G.、Michaelson、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] Gagliano、R.、Krishnan、S。、およびA. Kukec、「サブジェクトキー識別子（SKI）セキュアネイバーディスカバリー（送信）名前タイプフィールド」、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. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、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] Krishnan、S.、Laganier、J.、Bonola、M。、およびA. Garcia-Martinez、「安全な近隣発見のための安全な代理サポート（送信）」、RFC 6496、2012年2月。
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)
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 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
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) }
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
Roque Gagliano Cisco Systems Avenue Des Uttins 5 Rolle 1180 Switzerland
EMail: rogaglia@cisco.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.QCカナダのマウントロイヤルの町
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Ana Kukec Enterprise Architects 46/525 Collins St. Melbourne, VIC 3000 Australia
Ana Kukec Enterprise Architects 46/525 Collins St. Melbourne、Vic 3000 Australia
EMail: ana.kukec@enterprisearchitects.com