6494
PROPOSED STANDARD
Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)
Authors: R. Gagliano, S. Krishnan, A. Kukec
Date: February 2012
Area: int
Working Group: csi
Stream: IETF
Updates:
RFC 3971
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. [STANDARDS-TRACK]
RFC 6494
PROPOSED STANDARD
Errata Exist
Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 6494 Cisco Systems
Updates: <a href="./rfc3971">3971</a> S. Krishnan
Category: Standards Track Ericsson
ISSN: 2070-1721 A. Kukec
Enterprise Architects
February 2012
<span class="h1">Certificate Profile and Certificate Management for</span>
<span class="h1">SEcure Neighbor Discovery (SEND)</span>
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.
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc6494">http://www.rfc-editor.org/info/rfc6494</a>.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Gagliano, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Requirements Notation ...........................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. SEND Certificate Profile ........................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Unconstrained Certified Subnet Prefixes ....................<a href="#page-4">4</a>
<a href="#section-5">5</a>. Deployment Models ...............................................<a href="#page-5">5</a>
<a href="#section-6">6</a>. Trust Anchor Material ...........................................<a href="#page-5">5</a>
<a href="#section-7">7</a>. Extended Key Usage Values .......................................<a href="#page-6">6</a>
<a href="#section-8">8</a>. CRL Profile and Revocation ......................................<a href="#page-7">7</a>
<a href="#section-8.1">8.1</a>. Online Certificate Status Protocol (OCSP) Considerations ...<a href="#page-7">7</a>
<a href="#section-9">9</a>. Certificate Validation ..........................................<a href="#page-8">8</a>
<a href="#section-10">10</a>. IANA Considerations ............................................<a href="#page-8">8</a>
<a href="#section-11">11</a>. Security Considerations ........................................<a href="#page-8">8</a>
<a href="#section-12">12</a>. Acknowledgements ...............................................<a href="#page-8">8</a>
<a href="#section-13">13</a>. References .....................................................<a href="#page-9">9</a>
<a href="#section-13.1">13.1</a>. Normative References ......................................<a href="#page-9">9</a>
<a href="#section-13.2">13.2</a>. Informative References ....................................<a href="#page-9">9</a>
<a href="#appendix-A">Appendix A</a>. Router Authorization Certificate Example ..............<a href="#page-10">10</a>
<a href="#appendix-B">Appendix B</a>. ASN.1 Module ..........................................<a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
SEcure Neighbor Discovery (SEND) [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>] utilizes X.509v3
certificates that include the [<a href="./rfc3779" title=""X.509 Extensions for IP Addresses and AS Identifiers"">RFC3779</a>] 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 [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]. 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 [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>].
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 <a href="./rfc3971#section-6.2">Section 6.2 of [RFC3971]</a>.
Consequently, SEND will use the RPKI Certificate Profile and
certificate validation detailed in [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>]. Consequently, the
certificate validation method described in [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>] is updated with
the certificate validation method in [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>].
Since the [<a href="./rfc3779" title=""X.509 Extensions for IP Addresses and AS Identifiers"">RFC3779</a>] 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
<span class="grey">Gagliano, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
(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.
In <a href="./rfc3971">RFC 3971</a>, 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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Notation</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
Certified IPv6 address space IPv6 address space included in an
X.509v3 certificate using the extension
for IPv6 addresses [<a href="./rfc3779" title=""X.509 Extensions for IP Addresses and AS Identifiers"">RFC3779</a>].
End-entity (EE) An entity in the PKI that is not a
Certification Authority (CA).
ISP Internet Service Provider.
NIR National Internet Registry.
RIR Regional Internet Registry.
RPKI Resource PKI established in accordance
with [<a href="./rfc6480" title=""An Infrastructure to Support Secure Internet Routing"">RFC6480</a>].
RPKI certificates Certificates as defined in [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>].
SEND certificates Certificates as described in [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]
and extended in this document. They
are end-entity certificates that belong
either to SEND routers, SEND hosts, or
SEND proxies:
* Router Authorization Certificates as
defined in [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>].
* Owner Authorization Certificates as
defined in [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>].
<span class="grey">Gagliano, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
* Secure Proxy ND Certificates as
defined in [<a href="./rfc6496" title=""Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)"">RFC6496</a>].
SEND KeyPurposeId An Extended Key Usage (EKU) value for
SEND, such as the four introduced in
this document.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. SEND Certificate Profile</span>
SEND certificates MUST comply with the RPKI resource profile
described in [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>]. A Router Authorization Certificate example
is included in <a href="#appendix-A">Appendix A</a>.
In Sections <a href="#section-2">2</a>, <a href="#section-4.9.10">4.9.10</a>, and <a href="#section-4.9.11">4.9.11</a> of [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>], it is stated that
<a href="./rfc3779">RFC 3779</a> resource extensions MUST be marked as critical and MUST be
present in all resource certificates. SEND certificates MUST include
the IP Address Delegation extension [<a href="./rfc3779" title=""X.509 Extensions for IP Addresses and AS Identifiers"">RFC3779</a>]. This extension MUST
include at least one address block for the IPv6 Address Family
(AFI=0002), as described in <a href="./rfc6487#section-4.9.10">Section 4.9.10 of [RFC6487]</a>. SEND
certificates MUST NOT have more than one IP Address Delegation
extension.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Unconstrained Certified Subnet Prefixes</span>
<a href="./rfc3971#section-7.3">Section 7.3 of [RFC3971]</a> defines the Unconstrained Certified subnet
prefixes category by using certificates containing either the null
prefix or no prefix extension at all.
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 [<a href="./rfc3779" title=""X.509 Extensions for IP Addresses and AS Identifiers"">RFC3779</a>]. The use of the "inherit" element is permitted
in [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>].
Consequently, this document updates <a href="./rfc3971#section-7.3">Section 7.3 of [RFC3971]</a>, adding
the following text under Unconstrained:
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.
<span class="grey">Gagliano, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Deployment Models</span>
<a href="./rfc3971">RFC 3971</a> 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.
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) [<a href="./rfc4193" title=""Unique Local IPv6 Unicast Addresses"">RFC4193</a>].
The public SEND deployment models represent those cases where SEND
deployment is linked to RPKI deployment as described in [<a href="./rfc6480" title=""An Infrastructure to Support Secure Internet Routing"">RFC6480</a>].
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.
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Trust Anchor Material</span>
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. [<a href="./rfc6495" title=""Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields"">RFC6495</a>]
and <a href="./rfc3971#section-6.5">Section 6.5 of [RFC3971]</a> list the trust anchor configuration
options for end hosts using SEND.
In the local SEND deployment model, it is possible to use as a trust
anchor a certificate that includes in its <a href="./rfc3779">RFC 3779</a> 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.
<span class="grey">Gagliano, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Extended Key Usage Values</span>
The Internet PKI document [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] 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
[<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>] for end-entity certificates but MUST be present when
issuing end-entity certificates for 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.
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 <a href="./rfc6487#section-7.1">Section 7.1 of
[RFC6487]</a>) by the IP address space included in the X.509 extensions
for IP addresses.
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.
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.
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
<span class="grey">Gagliano, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
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.
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 [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>], the extended key usage extension, if
present, MUST be non-critical.
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 [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. CRL Profile and Revocation</span>
RPKI requires the use of Certificate Revocation Lists (CRLs)
[<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>]. The host will obtain the necessary CRLs and perform the
certificate validation method described in [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>].
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Online Certificate Status Protocol (OCSP) Considerations</span>
A host MAY use OCSP [<a href="./rfc2560" title=""X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"">RFC2560</a>] to verify the revocation status of a
certificate.
As [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>] 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 [<a href="./rfc6484" title=""Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)"">RFC6484</a>].
<span class="grey">Gagliano, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Certificate Validation</span>
This section updates <a href="./rfc3971#section-6.3.1">Section 6.3.1 of [RFC3971]</a> by introducing new
validations without introducing any conflict.
The host MUST perform the certificate validation method described in
[<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>]. The validation of certificates that use the "inherit"
element where the existence of a parent prefix or range is required
is described in [<a href="./rfc3779" title=""X.509 Extensions for IP Addresses and AS Identifiers"">RFC3779</a>].
The host MUST verify that the KeyPurposeId value corresponding to the
Neighbor Discovery message type is present, as described in
<a href="#section-7">Section 7</a>.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
This document makes use of object identifiers to identify EKUs and
the ASN.1 (Abstract Syntax Notation One) module found in <a href="#appendix-B">Appendix B</a>.
The EKUs and ASN.1 module OID are registered in an arc delegated by
IANA to the PKIX Working Group.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Security Considerations</span>
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.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Acknowledgements</span>
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.
<span class="grey">Gagliano, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. References</span>
<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2560">RFC2560</a>] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", <a href="./rfc2560">RFC 2560</a>, June 1999.
[<a id="ref-RFC3779">RFC3779</a>] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", <a href="./rfc3779">RFC 3779</a>, June 2004.
[<a id="ref-RFC3971">RFC3971</a>] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", <a href="./rfc3971">RFC 3971</a>, March 2005.
[<a id="ref-RFC4193">RFC4193</a>] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", <a href="./rfc4193">RFC 4193</a>, October 2005.
[<a id="ref-RFC5280">RFC5280</a>] 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", <a href="./rfc5280">RFC 5280</a>, May 2008.
[<a id="ref-RFC6484">RFC6484</a>] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource Public Key Infrastructure
(RPKI)", <a href="https://www.rfc-editor.org/bcp/bcp173">BCP 173</a>, <a href="./rfc6484">RFC 6484</a>, February 2012.
[<a id="ref-RFC6487">RFC6487</a>] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", <a href="./rfc6487">RFC 6487</a>,
February 2012.
[<a id="ref-RFC6495">RFC6495</a>] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key
Identifier (SKI) SEcure Neighbor Discovery (SEND) Name
Type Fields", <a href="./rfc6495">RFC 6495</a>, February 2012.
<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>. Informative References</span>
[<a id="ref-RFC6480">RFC6480</a>] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", <a href="./rfc6480">RFC 6480</a>, February 2012.
[<a id="ref-RFC6496">RFC6496</a>] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
Martinez, "Secure Proxy ND Support for SEcure Neighbor
Discovery (SEND)", <a href="./rfc6496">RFC 6496</a>, February 2012.
<span class="grey">Gagliano, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Router Authorization Certificate Example</span>
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:
Full Name:
URI:rsync://rsync.example.exampledomain/
EXAMPLE-CA-2342342652346/EXAMPLE-CA.crl
<span class="grey">Gagliano, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
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
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. ASN.1 Module</span>
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
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
<span class="grey">Gagliano, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc6494">RFC 6494</a> SEND Certificate Profile and Management February 2012</span>
-- 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
EMail: [email protected]
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
EMail: [email protected]
Ana Kukec
Enterprise Architects
46/525 Collins St.
Melbourne, VIC 3000
Australia
EMail: [email protected]
Gagliano, et al. Standards Track [Page 12]
Annotations
Select text to annotate