idnits 2.17.1 draft-ietf-csi-send-cert-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3971, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3971, updated by this document, for RFC5378 checks: 2003-10-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 24, 2010) is 4874 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-sidr-cp-15 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-19 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-11 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gagliano 3 Internet-Draft Cisco Systems 4 Updates: 3971 (if approved) S. Krishnan 5 Intended status: Standards Track Ericsson 6 Expires: May 28, 2011 A. Kukec 7 University of Zagreb 8 November 24, 2010 10 Certificate profile and certificate management for SEND 11 draft-ietf-csi-send-cert-10 13 Abstract 15 SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for 16 performing router authorization. This document specifies a 17 certificate profile for SEND based on Resource Certificates along 18 with extended key usage values required for SEND. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 28, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. SEND Certificate profile . . . . . . . . . . . . . . . . . . . 6 58 4.1. Unconstrained Certified subnet prefixes . . . . . . . . . 6 59 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Trust Anchor Material . . . . . . . . . . . . . . . . . . . . 8 61 7. Extended Key Usage Values . . . . . . . . . . . . . . . . . . 9 62 8. CRL profile and revocation . . . . . . . . . . . . . . . . . . 11 63 8.1. Online Certificate Status Protocol (OCSP) 64 Considerations . . . . . . . . . . . . . . . . . . . . . . 11 65 9. Certificate validation . . . . . . . . . . . . . . . . . . . . 12 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 71 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 72 Appendix A. Router Authorization Certificate example . . . . . . 18 73 Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 76 1. Requirements notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Introduction 84 SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3 85 certificates that include the [RFC3779] extension for IPv6 addresses 86 to certify a router's authorization to advertise IPv6 prefix for the 87 Neighbor Discovery (ND) Protocol. The SEND specification defines a 88 basic certificate profile for SEND. The certificate profile defined 89 in this document supersedes the profile for router certificates 90 specified in [RFC3971]. That is, certificates used in SEND (by 91 routers, proxies, or address owners) MUST conform to this certificate 92 profile and MAY conform to the original profile in [RFC3971]. 94 The Resource Public Key Infrastructure (RPKI) is the global PKI that 95 attests to the allocation of IP address space. The RPKI represents 96 the centralized model referred in Section 6.2 of [RFC3971]. 97 Consequently, SEND will use the RPKI certificate profile and 98 certificate validation detailed in [I-D.ietf-sidr-res-certs]. A 99 consequence of the use of RPKI certificate profile, the certificate 100 validation method described in RFC3971 is updated with the 101 certificate validation method in [I-D.ietf-sidr-res-certs]. 103 Since the RFC 3779 IPv6 addresses extension does not mention what 104 functions the node can perform for the certified IPv6 space, it 105 becomes impossible to know the reason for which the certificate was 106 issued. In order to facilitate issuance of certificates for specific 107 functions, it is necessary to utilize the ExtKeyUsageSyntax field 108 (optional in RPKI Certificates) of the X.509 certificate to mention 109 the purpose why the certificate was issued. This document specifies 110 four extended key usage values, one for routers, two for proxies, and 111 one for address owners, for use with SEND. 113 In RFC 3971 two deployment models were described: centralized and 114 decentralized. This document describes the different deployment 115 models that can be used with the SEND certificates defined here. 117 3. Terminology 119 Certified IPv6 address space IPv6 address space included in an 120 X.509v3 certificate using RFC 3779 121 extension for IPv6 addresses. 123 End Entity (EE) An entity in the PKI that is not a CA. 125 ISP Internet Service Provider. 127 NIR National Internet Registry. 129 RIR Regional Internet Registry. 131 RPKI Resource PKI established in accordance with 132 [I-D.ietf-sidr-arch]. 134 RPKI certificates Certificates defined in 135 [I-D.ietf-sidr-res-certs]. 137 SEND certificates Certificates described in [RFC3971] and 138 extended in this document. They are end- 139 entity certificates that belong either to 140 SEND routers, SEND hosts or SEND Proxies: 142 * Router Authorization Certificates 143 defined in [RFC3971]. 145 * Owner Authorization Certificates defined 146 in [RFC3971]. 148 * Secure Proxy ND Certificates defined in 149 [I-D.ietf-csi-proxy-send]. 151 SEND KeyPurposeId An Extended Key Usage (EKU) value for SEND, 152 such as the four introduced in this 153 document. 155 4. SEND Certificate profile 157 SEND certificates MUST comply with the RPKI resource profile 158 [I-D.ietf-sidr-res-certs]. A Router Authorization Certificate 159 example is included in the Appendix A. 161 In sections 2, 4.9.10 and 4.9.11 [I-D.ietf-sidr-res-certs] it is 162 stated that RFC 3779 resource extensions MUST be critical and MUST be 163 present in all Resource Certificates. SEND certificates MUST include 164 the IP Resources extension [RFC3779]. This extension MUST include at 165 least one address block for the IPv6 Address Family (AFI=0002), as 166 described in Section 4.9.10 of [I-D.ietf-sidr-res-certs]. SEND 167 certificates MUST NOT have more than one IP Resources extension. 169 4.1. Unconstrained Certified subnet prefixes 171 Section 7.3 of [RFC3971] defines the Unconstrained Certified subnet 172 prefixes category by using certificates containing either the null 173 prefix or no prefix extension at all. 175 When using RPKI certificate profile, prefix extensions are mandatory 176 and the null prefix MUST be validated. However, a certificate may 177 inherit its parent's prefix or range by using the "inherit" element 178 for IPv6 AFI as defined in RFC3779. The use of the "inherit" element 179 is permited in [I-D.ietf-sidr-res-certs]. 181 Consequently, this document updates section 7.3 of RFC 3971 adding 182 the following text under Unconstrained: 184 Network operators that do not want to constrain routers to route 185 particular subnet prefixes but rather inherit them from its parent 186 certificate, should configure routers with certificates containing 187 the "inherit" element for IPv6 AFI. 189 5. Deployment Models 191 RFC 3971 describes two deployment models:centralized and 192 decentralized. These models were differentiated by having one or 193 many trust anchor. In this document we introduce two new deployment 194 models, not based on the number of trust anchors but on the 195 localization of the SEND deployment. 197 The local SEND deployment model represent those cases where SEND 198 deployment is confined to an administrative domain. In this 199 scenario, the deployment of SEND MAY be done independently of the 200 existence of deployment in the upper RPKI hierarchy (i.e. an end user 201 could perform local SEND deployment without the need of RPKI 202 deployment in its ISP). This model requires the use of local trust 203 anchors and configuring islands of trust. This model MAY include 204 Unique Local Addresses(ULAs) [RFC4193]. 206 The public SEND deployment models represent those cases where SEND 207 deployment is linked to RPKI deployment as described in 208 [I-D.ietf-sidr-arch]. Trust anchor material MAY be part of a 209 different administrative domain (i.e. RIR, NIR or ISPs). It is a 210 global model suitable for mobile users. 212 These two models are not mutually exclusive. It is entirely possible 213 to have a hybrid model that incorporates features from both these 214 models. In one such hybrid deployment model most IP address 215 resources (e.g. global unicast addresses) would be certified under 216 the global RPKI, while some others (e.g., ULAs) are certified under 217 local TAs. 219 6. Trust Anchor Material 221 Relying parties (e.g., end hosts that implement SEND and process 222 these router certificates) MUST be configured with one or more trust 223 anchors to enable validation of the routers' certificates. Section 224 6.5 of RFC 3971 and [I-D.ietf-csi-send-name-type-registry] list the 225 trust anchor configuration options for end hosts using SEND. 227 In the local SEND deployment model, it is possible to use as trust 228 anchor a certificate that includes in its RFC 3779 address extension 229 the prefix ::/0. In this case no new trust anchor material would be 230 needed when renumbering. However, if trying to move from the local 231 deployment model to the public deployment model, new trust anchor 232 material will have to be distributed to relying parties. 234 7. Extended Key Usage Values 236 The Internet PKI document [RFC5280] specifies the extended key usage 237 X.509 certificate extension. The extension indicates one or more 238 purposes for which the certified public key may be used. The 239 extended key usage extension can be used in conjunction with key 240 usage extension, which indicates the intended purpose of the 241 certified public key. The EKU extension is defined as optional in 242 [I-D.ietf-sidr-res-certs] for end entity certificates but MUST be 243 present when issuing end entity certificates for SEND. 245 The extended key usage extension syntax is repeated here for 246 convenience: 248 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 250 KeyPurposeId ::= OBJECT IDENTIFIER 252 This specification defines four KeyPurposeId values: one for 253 authorizing routers (Router Authorization Certificates), two for 254 authorizing proxies (Secure Proxy ND Certificates), and one for 255 address owners (Owner Authorization Certificates). Additional 256 KeyPurposeId values may be specified in standard track documents. 258 The inclusion of the router authorization value (id-kp-sendRouter) 259 indicates that the certificate has been issued for allowing the 260 router to generate RA and Redirect messages for any prefix(es) 261 encompassed (as defined in Section 7.1 of [I-D.ietf-sidr-res-certs]) 262 by the IP address space included in the X.509 extensions for IP 263 addresses. 265 The inclusion of the proxied routing authorization value (id-kp- 266 sendProxiedRouter) indicates that the certificate has been issued for 267 allowing the proxy to perform proxying of RA and Redirect messages 268 for any prefix(es) encompassed by the IP address space included in 269 the X.509 extensions for IP addresses. 271 The inclusion of the proxied owner authorization value (id-kp- 272 sendProxiedOwner) indicates that the certificate has been issued for 273 allowing the proxy to perform proxying of NS, NA and RS messages for 274 any address encompassed by the IP address space included in the X.509 275 extensions for IP addresses. 277 The inclusion of the owner authorization value (id-kp-sendOwner) 278 indicates that the certificate has been issued for allowing the node 279 to use any address(es) that is/are encompassed by the IP address 280 space included in the X.509 extensions for IP addresses. For an 281 address in such certificate the node can assign the address to an 282 interface, send/receive traffic from/to this address, and can send/ 283 respond NS, NA and RS messages about that address. 285 send-kp OBJECT IDENTIFIER ::= 286 { iso(1) identified-organization(3) dod(6) internet(1) 287 security(5) mechanisms(5) pkix(7) kp(3) } 289 id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } 291 id-kp-sendProxiedRouter OBJECT IDENTIFIER ::= { id-kp 24 } 293 id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } 295 id-kp-sendProxiedOwner OBJECT IDENTIFIER ::= { id-kp 26 } 297 As described in [I-D.ietf-sidr-res-certs], the extended key usage 298 extension, if present, MUST be non-critical. 300 Relying Parties MUST require the extended key usage extension to be 301 present in a certificate, and they MAY require a particular 302 KeyPurposeId value to be present (such as id-kp-sendRouter or 303 sendProxiedRouter) within the extended key usage extension. If 304 multiple KeyPurposeId values are included, the relying parties need 305 not recognize all of them, as long as the required KeyPurposeId value 306 is present.Relying parties MUST reject certificates that do not 307 contain at least one SEND KeyPurposeId even if they include the 308 anyExtendedKeyUsage OID defined in [RFC5280]. 310 8. CRL profile and revocation 312 RPKI requires the use of CRLs [I-D.ietf-sidr-res-certs].The host will 313 obtain the necessary CRLs and perform the certificate validation 314 method described in [I-D.ietf-sidr-res-certs]. 316 8.1. Online Certificate Status Protocol (OCSP) Considerations 318 A host MAY use OCSP [RFC2560] protocol to verify the revocation 319 status of a certificate. 321 By adopting the [I-D.ietf-sidr-res-certs] as the certificate profile 322 for SEND, the host SHOULD NOT assume that certificates will include 323 the URI of an OCSP server as part of its Authority Information Access 324 (AIA) extension. This is particularly evident in the SEND public 325 deployment model as OCSP services are not required by 326 [I-D.ietf-sidr-cp]. 328 9. Certificate validation 330 This section updates section 6.3.1 of [RFC3971] by introducing new 331 validations without introducing any conflict. 333 The host MUST perform the certificate validation method described in 334 [I-D.ietf-sidr-res-certs]. The validation of certificates that uses 335 the "inherit" element is describe in RFC 3779 where the existence of 336 a parent prefix or range is required. 338 The host MUST verify that the Key PurposedId value corresponding to 339 the Neighbor Discovery message type is present as described in 340 Section 7. 342 10. IANA Considerations 344 This document makes use of object identifiers to identify EKUs and 345 the ASN.1 (Abstract Syntax Notation One) module found in Appendix B. 346 The EKUs and ASN.1 module OID are registered in an arc delegated by 347 IANA to the PKIX Working Group. No further action by IANA is 348 necessary for this document. 350 11. Security Considerations 352 The certification authority needs to ensure that the correct values 353 for the extended key usage are inserted in each certificate that is 354 issued. Relying parties may accept or reject a particular 355 certificate for an intended use based on the information provided in 356 these extensions. Incorrect representation of the information in the 357 extended key usage field can cause the relying party to reject an 358 otherwise appropriate certificate or accept a certificate that ought 359 to be rejected. In particular, since a SEND certificate attests that 360 its subject is authorized to play a given role in the SEND protocol, 361 certificates that contain incorrect EKU values can enable some of the 362 same attacks that SEND was meant to prevent. For example, if a 363 malicious host can obtain a certificate that authorizes it to act as 364 a router for a given prefix, then it can masquerade as a router for 365 that prefix, e.g., in order to attract traffic from local nodes. 367 12. Acknowledgements 369 The authors would like to thank Alberto Garcia, Stephen Kent, Sean 370 Turner, Roni Even, Richard Barnes, Alexey Melnikov, Jari Arkko, David 371 Harrington and Tim Polk for their reviews and suggestions on the 372 earlier versions of this document. 374 13. References 376 13.1. Normative References 378 [I-D.ietf-csi-send-name-type-registry] 379 Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key 380 Identifier (SKI) SEND Name Type fields.", 381 draft-ietf-csi-send-name-type-registry-06 (work in 382 progress), June 2010. 384 [I-D.ietf-sidr-cp] 385 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 386 Policy (CP) for the Resource PKI (RPKI", 387 draft-ietf-sidr-cp-15 (work in progress), October 2010. 389 [I-D.ietf-sidr-res-certs] 390 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 391 X.509 PKIX Resource Certificates", 392 draft-ietf-sidr-res-certs-19 (work in progress), 393 October 2010. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 399 Adams, "X.509 Internet Public Key Infrastructure Online 400 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 402 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 403 Addresses and AS Identifiers", RFC 3779, June 2004. 405 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 406 Neighbor Discovery (SEND)", RFC 3971, March 2005. 408 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 409 Addresses", RFC 4193, October 2005. 411 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 412 Housley, R., and W. Polk, "Internet X.509 Public Key 413 Infrastructure Certificate and Certificate Revocation List 414 (CRL) Profile", RFC 5280, May 2008. 416 13.2. Informative References 418 [I-D.ietf-csi-proxy-send] 419 Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 420 Martinez, "Secure Proxy ND Support for SEND", 421 draft-ietf-csi-proxy-send-05 (work in progress), 422 September 2010. 424 [I-D.ietf-sidr-arch] 425 Lepinski, M. and S. Kent, "An Infrastructure to Support 426 Secure Internet Routing", draft-ietf-sidr-arch-11 (work in 427 progress), September 2010. 429 Appendix A. Router Authorization Certificate example 431 Certificate: 432 Data: 433 Version: 3 (0x2) 434 Serial Number: 249 (0xf9) 435 Signature Algorithm: sha256WithRSAEncryption 436 Issuer: CN=EXAMPLE-CA-2342342652346 437 Validity 438 Not Before: Jul 2 10:06:32 2010 GMT 439 Not After : Jul 2 10:06:32 2011 GMT 440 Subject: CN=SEND-EXAMPLE-123432 441 Subject Public Key Info: 442 Public Key Algorithm: rsaEncryption 443 Public-Key: (2048 bit) 444 Modulus: 445 00:b7:06:0d:8e:f7:39:0a:41:52:93:59:a8:f5:63: 446 3f:2e:3d:24:17:9d:19:aa:09:ff:c0:2a:f3:c6:99: 447 d7:34:0d:bf:f1:e9:73:b5:8f:dc:d4:91:d6:5d:cb: 448 9c:b8:2b:41:63:c1:8f:f7:48:54:02:89:07:24:c3: 449 b0:6e:11:5a:7d:c0:38:88:4b:d9:3b:93:c7:ca:4d: 450 a4:00:a2:d3:6d:14:15:8f:15:08:4d:4e:b3:8a:cc: 451 de:2d:e0:7a:9b:c0:6e:14:f6:a7:ae:b9:e0:c5:18: 452 60:75:3d:d3:50:00:47:0d:86:5b:1c:a0:85:81:af: 453 2b:84:98:49:7d:60:a2:e8:4f:6d:40:ba:d5:fe:de: 454 de:41:53:c7:c4:f4:d3:1a:41:cd:dc:9f:08:43:33: 455 48:00:57:e4:56:93:7d:dd:19:12:e8:bf:26:b3:4b: 456 30:ac:b8:9c:b1:37:05:18:3c:7b:6b:26:d7:c9:15: 457 c9:4a:eb:1b:fa:92:38:46:27:44:96:8a:a1:12:c1: 458 09:77:4a:7b:a5:07:88:a6:36:30:98:70:79:b6:44: 459 7e:b1:c9:4c:5b:11:56:e8:14:50:f7:f8:e5:ed:f1: 460 ac:a4:31:46:36:77:05:c9:63:fe:c3:ab:54:e2:bd: 461 79:1d:14:d1:c2:80:36:d3:be:e6:c7:a2:47:59:1b: 462 75:9f 463 Exponent: 65537 (0x10001) 464 X509v3 extensions: 465 X509v3 Authority Key Identifier: 466 keyid:4C:5D:56:82:15:8A:67:A6:8C:69:67:68:88 467 :6F:15:E5:C9:96:58:EB 469 X509v3 CRL Distribution Points: 471 Full Name: 472 URI:rsync://rsync.example.exampledomain/ 473 EXAMPLE-CA-2342342652346/EXAMPLE-CA.crl 475 X509v3 Subject Key Identifier: 476 B8:69:EB:36:23:F1:C4:21:65:DD:13:76:EE:90:AF 477 :F7:CD:E3:61:CD 478 X509v3 Key Usage: critical 479 Digital Signature 480 sbgp-ipAddrBlock: critical 481 IPv6: 482 2001:db8:cafe:bebe::/64 484 X509v3 Extended Key Usage: 485 1.3.6.1.5.5.7.3.23 486 Signature Algorithm: sha256WithRSAEncryption 487 92:14:38:6e:45:83:1b:cb:7c:45:0d:bc:7f:6e:36:bf:82:cc: 488 7e:00:91:ea:f4:24:43:cc:00:3c:3f:c2:99:0c:c6:b9:20:2e: 489 ca:dc:df:94:0d:c9:a1:75:c4:5c:39:a1:cf:9f:e1:40:9c:aa: 490 a9:80:76:d1:3a:91:d9:db:2f:cd:3c:05:50:52:eb:28:47:d0: 491 ab:d3:fd:6f:30:17:16:7f:c6:0f:2b:25:bb:db:29:d7:bb:4e: 492 f3:7c:2d:e1:04:b7:f0:bc:d5:8a:ba:8c:0d:39:22:48:02:d1: 493 67:fb:35:5c:b6:83:03:63:7c:73:03:70:20:de:fb:d7:12:ed: 494 6f:a1:ff:b2:a6:39:fb:55:9a:07:bd:68:40:0f:6f:d5:24:34: 495 cf:e8:dd:76:33:2a:d0:b9:1b:ae:a8:68:86:17:f8:13:35:0e: 496 f6:04:ec:2a:39:88:06:70:c6:e8:56:87:f7:35:54:2a:28:2c: 497 92:47:a9:89:39:d7:72:24:21:9d:02:52:f9:7c:76:7f:e9:cd: 498 09:6e:82:f4:da:6c:f9:72:b2:64:98:b5:0c:6a:38:8d:81:e5: 499 fc:50:46:6f:38:40:56:06:92:5a:e0:86:5d:55:f5:7b:85:b2: 500 68:4f:49:72:e0:fa:2c:bf:9e:7d:aa:28:17:ca:04:b8:ae:69: 501 c9:04:28:12 503 Appendix B. ASN.1 Module 505 SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1) 506 security(5) mechanisms(5) pkix(7) id-mod(0) 507 id-mod-send-cert-extns(71) } 509 DEFINITIONS IMPLICIT TAGS ::= 511 BEGIN 513 -- OID Arc 515 id-kp OBJECT IDENTIFIER ::= 516 { iso(1) identified-organization(3) dod(6) internet(1) 517 security(5) mechanisms(5) pkix(7) kp(3) } 519 -- Extended Key Usage Values 521 id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } 522 id-kp-sendProxiedRouter OBJECT IDENTIFIER ::= { id-kp 24 } 523 id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } 524 id-kp-sendProxiedOwner OBJECT IDENTIFIER ::= { id-kp 26 } 526 END 528 Authors' Addresses 530 Roque Gagliano 531 Cisco Systems 532 Avenue des Uttins 5 533 Rolle, 1180 534 Switzerland 536 Email: rogaglia@cisco.com 538 Suresh Krishnan 539 Ericsson 540 8400 Decarie Blvd. 541 Town of Mount Royal, QC 542 Canada 544 Phone: +1 514 345 7900 x42871 545 Email: suresh.krishnan@ericsson.com 547 Ana Kukec 548 University of Zagreb 549 Unska 3 550 Zagreb 551 Croatia 553 Email: ana.kukec@fer.hr