Network Working Group R. Gagliano
Internet-Draft Cisco Systems
Updates: 3971 (if approved) S. Krishnan
Intended status: Standards Track Ericsson
Expires: March 2, 2011 A. Kukec
University of Zagreb
August 29, 2010
Certificate profile and certificate management for SEND
draft-ietf-csi-send-cert-06
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 2, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Gagliano, et al. Expires March 2, 2011 [Page 1]
Internet-Draft SEND certificate profile and management August 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. SEND Certificate profile . . . . . . . . . . . . . . . . . . . 6
4.1. Unconstrained Certified subnet prefixes . . . . . . . . . 6
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 7
6. Trust Anchor Material . . . . . . . . . . . . . . . . . . . . 8
7. Extended Key Usage Values . . . . . . . . . . . . . . . . . . 9
8. CRL profile and revocation . . . . . . . . . . . . . . . . . . 11
8.1. Online Certificate Status Protocol (OCSP)
Considerations . . . . . . . . . . . . . . . . . . . . . . 11
9. Certificate validation . . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Router Authorization Certificate example . . . . . . 18
Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Gagliano, et al. Expires March 2, 2011 [Page 2]
Internet-Draft SEND certificate profile and management August 2010
1. Requirements notation
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].
Gagliano, et al. Expires March 2, 2011 [Page 3]
Internet-Draft SEND certificate profile and management August 2010
2. Introduction
SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3
certificates that include the [RFC3779] extension for IPv6 addresses
to certify a router's authorization to advertise 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 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].
The Resource Public Key Infrastructure (RPKI) is the global PKI that
attests to allocation of IP address space. The RPKI represents the
centralized model referred in Section 6.2 of [RFC3971].
Consequently, SEND will use the RPKI certificate profile and
certificate validation detailed in [I-D.ietf-sidr-res-certs]. A
consequence of the use of RPKI certificate profile, the certificate
validation method described in RFC3971 is updated with the
certificate validation method in [I-D.ietf-sidr-res-certs].
Since the RFC 3779 IPv6 addresses 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
the purpose why the certificate was issued. This document specifies
three extended key usage values, one for routers, one for proxies,
and one for address owners, for use with 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.
Gagliano, et al. Expires March 2, 2011 [Page 4]
Internet-Draft SEND certificate profile and management August 2010
3. Terminology
Certified IPv6 address space IPv6 address space included in an
X.509v3 certificate using RFC 3779
extension for IPv6 addresses.
End Entity (EE) An entity in the PKI that is not a CA.
ETA External Trust Anchor as defined in
[I-D.ietf-sidr-ta].
ISP Internet Service Provider.
NIR National Internet Registry.
RIR Regional Internet Registry.
RPKI Resource PKI established in accordance with
[I-D.ietf-sidr-arch].
RPKI certificates Certificates defined in
[I-D.ietf-sidr-res-certs].
RTA RPKI Trust Anchor as defined in
[I-D.ietf-sidr-ta].
SEND certificates Certificates described in [RFC3971] and
extended in this document. They are end-
entity certificates that belong either to
SEND routers, SEND Proxies or SEND hosts:
* Router Authorization Certificates.
* Owner Authorization Certificates.
* Secure Proxy ND Certificates for ND
Proxy, Mobile IPv6 Home Agent or Proxy
Mobile Access Gateway
[I-D.ietf-csi-proxy-send].
Gagliano, et al. Expires March 2, 2011 [Page 5]
Internet-Draft SEND certificate profile and management August 2010
4. SEND Certificate profile
SEND certificates MUST comply with the RPKI resource profile
[I-D.ietf-sidr-res-certs]. A Router Authorization Certificate
example is included in the Appendix A.
In sections 2, 4.9.10 and 4.9.11 [I-D.ietf-sidr-res-certs] it is
stated that RFC 3779 resource extensions MUST be critical and MUST be
present in all Resource Certificates. SEND certificates MUST include
the IP Resources 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 [I-D.ietf-sidr-res-certs]. SEND
certificates MUST NOT have more than one IP Resources extension.
4.1. Unconstrained Certified subnet prefixes
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.
When using 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 IPv6 AFI as defined in RFC3779. The use of the "inherit" element
is permited in [I-D.ietf-sidr-res-certs].
Consequently, this document updates section 7.3 of RFC 3971 adding
the following text under Unconstrained:
Network operators that do not want to constrain routers to route
particular subnet prefixes but rather inherit them from its parent
certificate, should configure routers with certificates containing
the "inherit" element for IPv6 AFI.
Gagliano, et al. Expires March 2, 2011 [Page 6]
Internet-Draft SEND certificate profile and management August 2010
5. Deployment Models
RFC 3971 describes two deployment models:centralized and
decentralized. These models were differentiated by having one or
many trust anchor. 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 represent 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 of 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].
The public SEND deployment models represent those cases where SEND
deployment is linked to RPKI deployment as described in
[I-D.ietf-sidr-arch]. Trust anchor material MAY be part of a
different administrative domain (i.e. RIR, NIR 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 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 TAs.
Gagliano, et al. Expires March 2, 2011 [Page 7]
Internet-Draft SEND certificate profile and management August 2010
6. Trust Anchor Material
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. Section
6.5 of RFC 3971 lists the trust anchor configurations for end hosts
using SEND.
In the local SEND deployment model, it is possible to use as 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.
[I-D.ietf-sidr-ta] describes a scenario where relying parties use as
trust anchor material ETA (External Trust Anchor) certificates, which
do not list any address space. This configuration allows network
renumbering without the need for distributing new trust anchor
material in both the local and the public model.
This document updates Section 6.5 of RFC3971, where the following
paragraph should be added:
An end host MAY use as trust anchor material ETA certificates as
described in [I-D.ietf-sidr-ta]. In this case, the end host MUST
obtain the correspondent RTA (RPKI Trust Anchor) certificates from
the ETA repository in order to complete the Name Type Field of the
ICMP Trust Anchor Option, which MUST always refer to a trust anchor
certificate that validates Section 9.
Gagliano, et al. Expires March 2, 2011 [Page 8]
Internet-Draft SEND certificate profile and management August 2010
7. Extended Key Usage Values
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 key
usage extension, which indicates the intended purpose of the
certified public key. The Extended Key Usage extension is defined as
optional in [I-D.ietf-sidr-res-certs] 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 three KeyPurposeId values: one for
authorizing routers (Router Authorization Certificates), one for
authorizing proxies (Secure Proxy ND Certificates), and one for
address owners (Owner Authorization Certificates).
The inclusion of the router authorization value (id-kp-sendRouter)
indicates that the certificate has been issued for allowing the
router to generate RA and Redirect messages for the prefix(es) that
are mentioned in the X.509 extensions for IP addresses.
The inclusion of the proxy authorization value (id-kp-sendProxy)
indicates that the certificate has been issued for allowing the proxy
to perform proxying of RA and Redirect messages for the prefix(es)
that are mentioned 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 the address(es) or prefix(es) that are included in the
certificate extension for IP addresses. For an address in such
certificate the node can assign the address to an interface, send/
receive traffic from this address, and can send or respond NS, NA and
RS messages about that address. For a prefix in such certificate the
node can perform all the above mentioned operations for any address
in that prefix. Also, when a node's only certificate includes a
prefix and only the owner authorization KeyPurposeId value, the node
cannot advertise that prefix in an RA.
Inclusion of multiple values is permited and indicates that the
certified public key is appropriate for use by a node performing more
than one of these functions.
Gagliano, et al. Expires March 2, 2011 [Page 9]
Internet-Draft SEND certificate profile and management August 2010
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-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }
As described in [I-D.ietf-sidr-res-certs], 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-
sendProxy) 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
one of the three KeyPurposeIds defined above even if they include the
anyExtendedKeyUsage OID defined in [RFC5280].
Gagliano, et al. Expires March 2, 2011 [Page 10]
Internet-Draft SEND certificate profile and management August 2010
8. CRL profile and revocation
RPKI requires the use of CRLs [I-D.ietf-sidr-res-certs].The host will
obtain the necessary CRLs and perform the certificate validation
method described in [I-D.ietf-sidr-res-certs].
8.1. Online Certificate Status Protocol (OCSP) Considerations
A host MAY use the OCSP [RFC2560] to verify the revocation status of
a certificate.
By adopting the [I-D.ietf-sidr-res-certs] as the 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
[I-D.ietf-sidr-cp].
Gagliano, et al. Expires March 2, 2011 [Page 11]
Internet-Draft SEND certificate profile and management August 2010
9. Certificate validation
This section updates section 6.3.1 of [RFC3971] by introducing new
validations without introducing any conflict.
The host MUST perform the certificate validation method described in
[I-D.ietf-sidr-res-certs]. The validation of certificates that uses
the "inherit" element is describe in RFC 3779 where the existence of
a parent prefix or range is required.
The host MUST verify that the correspondent Key PurposedId value(s)
is(are) present as described in Section 7.
Gagliano, et al. Expires March 2, 2011 [Page 12]
Internet-Draft SEND certificate profile and management August 2010
10. IANA Considerations
This document makes use of object identifiers to identify Extended
Key Usages (EKUs) and the ASN.1 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. No further action by IANA is necessary for
this document.
Gagliano, et al. Expires March 2, 2011 [Page 13]
Internet-Draft SEND certificate profile and management August 2010
11. Security Considerations
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.
Gagliano, et al. Expires March 2, 2011 [Page 14]
Internet-Draft SEND certificate profile and management August 2010
12. Acknowledgements
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.
Gagliano, et al. Expires March 2, 2011 [Page 15]
Internet-Draft SEND certificate profile and management August 2010
13. References
13.1. Normative References
[I-D.ietf-csi-proxy-send]
Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy
ND Support for SEND", draft-ietf-csi-proxy-send-01 (work
in progress), July 2009.
[I-D.ietf-sidr-cp]
Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource PKI (RPKI)",
draft-ietf-sidr-cp-08 (work in progress), January 2010.
[I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-18 (work in progress), May 2010.
[I-D.ietf-sidr-ta]
Michaelson, G., Kent, S., and G. Huston, "A Profile for
Trust Anchor Material for the Resource Certificate PKI",
draft-ietf-sidr-ta-04 (work in progress), May 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[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.
Gagliano, et al. Expires March 2, 2011 [Page 16]
Internet-Draft SEND certificate profile and management August 2010
13.2. Informative References
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-09 (work in
progress), October 2009.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
Gagliano, et al. Expires March 2, 2011 [Page 17]
Internet-Draft SEND certificate profile and management August 2010
Appendix A. Router Authorization Certificate example
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
X509v3 Subject Key Identifier:
B8:69:EB:36:23:F1:C4:21:65:DD:13:76:EE:90:AF
Gagliano, et al. Expires March 2, 2011 [Page 18]
Internet-Draft SEND certificate profile and management August 2010
: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
Gagliano, et al. Expires March 2, 2011 [Page 19]
Internet-Draft SEND certificate profile and management August 2010
Appendix B. ASN.1 Module
SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-send-cert-extns(TBD) }
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) }
-- Extended Key Usage Values
id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }
END
Gagliano, et al. Expires March 2, 2011 [Page 20]
Internet-Draft SEND certificate profile and management August 2010
Authors' Addresses
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
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Ana Kukec
University of Zagreb
Unska 3
Zagreb
Croatia
Email: ana.kukec@fer.hr
Gagliano, et al. Expires March 2, 2011 [Page 21]
