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
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)
用于安全邻居发现（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证书执行路由器授权。此文档基于资源证书以及发送所需的扩展密钥使用值指定用于发送的证书配置文件。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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].
安全邻居发现（发送）[RFC3971]利用X.509v3证书，其中包括IPv6地址的[RFC3779]扩展，以证明路由器有权公布邻居发现（ND）协议的IPv6前缀。SEND规范定义了SEND的基本证书配置文件。本文档中定义的证书配置文件取代[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节中讨论的集中式模型。因此，SEND将使用[RFC6487]中详述的RPKI证书配置文件和证书验证。因此，使用[RFC6487]中的证书验证方法更新[RFC3971]中描述的证书验证方法。
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证书中为可选）以说明颁发证书的原因。本文档指定了四个扩展密钥使用值，一个用于路由器，两个用于代理，一个用于地址所有者，用于SEND。
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.
在RFC3971中，描述了两种部署模型：集中式和分散式。本文档描述了可与此处定义的发送证书一起使用的不同部署模型。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Certified IPv6 address space IPv6 address space included in an X.509v3 certificate using the extension for IPv6 addresses [RFC3779].
认证的IPv6地址空间使用IPv6地址扩展[RFC3779]的X.509v3证书中包含的IPv6地址空间。
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.
国家互联网注册处。
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.
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.
发送证书必须符合[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）的至少一个地址块。发送证书不能有多个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证书配置文件时，前缀扩展是必需的，必须验证空前缀。但是，证书可以通过使用[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.
RFC3971描述了两种部署模型：集中式和分散式。这些模型通过具有一个信任锚或多个信任锚来区分。在本文中，我们介绍了两种新的部署模型，它们不是基于信任锚的数量，而是基于发送部署的本地化。
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层次结构中存在的部署来完成（即，最终用户可以执行本地SEND部署，而无需在其ISP中部署RPKI）。此模型需要使用本地信任锚并配置信任岛。此模型可能包括唯一本地地址（ULA）[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.
公共发送部署模型表示发送部署链接到RPKI部署的情况，如[RFC6480]中所述。信托锚材料可能属于不同的管理领域（即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.
这两种模式并不相互排斥。完全有可能有一个混合模型，它结合了这两种模型的特征。在一个这样的混合部署模型中，大多数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.
依赖方（例如，实现发送和处理这些路由器证书的终端主机）必须配置一个或多个信任锚，以启用路由器证书的验证。[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.
在本地发送部署模型中，可以使用一个证书作为信任锚，该证书在其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.
Internet PKI文档[RFC5280]指定扩展密钥使用X.509证书扩展。扩展名表示认证公钥可用于的一个或多个目的。扩展密钥使用扩展可与密钥使用扩展一起使用，该扩展指示认证公钥的预期用途。EKU扩展在[RFC6487]中定义为终端实体证书的可选扩展，但在为SEND颁发终端实体证书时必须存在。
The extended key usage extension syntax is repeated here for convenience:
为方便起见，此处重复了扩展密钥用法扩展语法：
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
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.
本规范定义了四个KeyPurposeId值：一个用于授权路由器（路由器授权证书），两个用于授权代理（安全代理ND证书），一个用于地址所有者（所有者授权证书）。其他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）并为包含在X.509 IP地址扩展中的IP地址空间中的任何前缀（如[RFC6487]第7.1节所定义）重定向消息。
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.509 IP地址扩展中包含的IP地址空间所包含的任何前缀执行RA代理和重定向消息。
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.
X.509 IP地址扩展中包含的IP地址空间所包含的任何地址的请求（NS）、邻居公告（NA）和路由器请求（RS）消息。
send-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
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-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxiedRouter OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendProxiedRouter OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }
id-kp-sendProxiedOwner OBJECT IDENTIFIER ::= { id-kp 26 }
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].
依赖方必须要求证书中存在扩展密钥使用扩展，并且他们可能要求扩展密钥使用扩展中存在特定的KeyPurposeId值（例如id kp sendRouter或id kp sendProxiedRouter）。如果包含多个KeyPurposeId值，则依赖方无需识别所有这些值，只要存在所需的KeyPurposeId值。依赖方必须拒绝不包含至少一个SEND KeyPurposeId的证书，即使它们包含[RFC5280]中定义的anyExtendedKeyUsage OID。
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]被用作发送的基本证书配置文件，主机不应假定证书将包含OCSP服务器的URI作为其权限信息访问（AIA）扩展的一部分。这在发送公共部署模型中尤其明显，因为[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.
主机必须验证与邻居发现消息类型对应的KeyPurposeId值是否存在，如第7节所述。
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.
本文件利用对象标识符识别附录B中的EKU和ASN.1（抽象语法符号1）模块。EKU和ASN.1模块OID在IANA委托给PKIX工作组的arc中注册。
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互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年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地址和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.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年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 52802008年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 64952012年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，“安全代理和支持安全邻居发现（SEND）”，RFC 64962012年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)
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 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
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 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
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) }
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 ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- OID Arc
--弧线
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
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 }
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瑞士
EMail: rogaglia@cisco.com
EMail: rogaglia@cisco.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Ana Kukec Enterprise Architects 46/525 Collins St. Melbourne, VIC 3000 Australia
澳大利亚维多利亚州墨尔本柯林斯街46/525号Ana Kukec Enterprise Architects，邮编：3000
EMail: ana.kukec@enterprisearchitects.com
EMail: ana.kukec@enterprisearchitects.com