idnits 2.17.1 draft-ietf-csi-send-cert-05.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 (June 28, 2010) is 5050 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) == Unused Reference: 'RFC5781' is defined on line 426, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-csi-proxy-send-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-csi-proxy-send (ref. 'I-D.ietf-csi-proxy-send') == Outdated reference: A later version (-17) exists of draft-ietf-sidr-cp-08 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 == Outdated reference: A later version (-07) exists of draft-ietf-sidr-ta-04 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-09 Summary: 1 error (**), 0 flaws (~~), 7 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: December 30, 2010 A. Kukec 7 University of Zagreb 8 June 28, 2010 10 Certificate profile and certificate management for SEND 11 draft-ietf-csi-send-cert-05 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 December 30, 2010. 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. OCSP Considerations . . . . . . . . . . . . . . . . . . . 11 64 9. Certificate validation . . . . . . . . . . . . . . . . . . . . 12 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 70 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 71 Appendix A. Router Authorization Certificate example . . . . . . 18 72 Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Requirements notation 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3 84 certificates that include the [RFC3779] extension for IPv6 addresses 85 to certify a router's authorization to advertise IPv6 prefix for the 86 Neighbor Discovery (ND) Protocol. The SEND specification defines a 87 basic certificate profile for SEND. The certificate profile defined 88 in this document supercedes the profile for router certificates 89 specified in [RFC3971]. That is, certificates used in SEND (by 90 routers, proxies, or address owners) MUST conform to this certificate 91 profile and MAY conform to the original profile in [RFC3971]. 93 The Resource Public Key Infrastructure (RPKI) is the global PKI that 94 attests to allocation of IP address space. The RPKI represents the 95 centralized model referred in Section 6.2 of [RFC3971]. 96 Consequently, SEND will use the RPKI certificate profile and 97 certificate validation detailed in [I-D.ietf-sidr-res-certs]. A 98 consequence of the use of RPKI certificate profile, the certificate 99 validation method described in RFC3971 is updated with the 100 certificate validation method in [I-D.ietf-sidr-res-certs]. 102 Since the RFC 3779 IPv6 addresses extension does not mention what 103 functions the node can perform for the certified IPv6 space, it 104 becomes impossible to know the reason for which the certificate was 105 issued. In order to facilitate issuance of certificates for specific 106 functions, it is necessary to utilize the ExtKeyUsageSyntax field 107 (optional in RPKI Certificates) of the X.509 certificate to mention 108 the purpose why the certificate was issued. This document specifies 109 three extended key usage values, one for routers, one for proxies, 110 and one for address owners, for use with SEND. 112 In RFC 3971 two deployment models were described: centralized and 113 decentralized. This document describes the different deployment 114 models that can be used with the SEND certificates defined here. 116 3. Terminology 118 Certified IPv6 address space IPv6 address space included in an 119 X.509v3 certificate using RFC 3779 120 extension for IPv6 addresses. 122 End Entity (EE) An entity in the PKI that is not a CA. 124 ETA External Trust Anchor as defined in 125 [I-D.ietf-sidr-ta]. 127 ISP Internet Service Provider. 129 NIR National Internet Registry. 131 RIR Regional Internet Registry. 133 RPKI Resource PKI established in accordance with 134 [I-D.ietf-sidr-arch]. 136 RPKI certificates Certificates defined in 137 [I-D.ietf-sidr-res-certs]. 139 RTA RPKI Trust Anchor as defined in 140 [I-D.ietf-sidr-ta]. 142 SEND certificates Certificates described in [RFC3971] and 143 extended in this document. They are end- 144 entity certificates that belong either to 145 SEND routers or Secure Proxy ND nodes: 147 * Router Authorization Certificates. 149 * Secure Proxy ND certificates for ND 150 Proxy, Mobile IPv6 Home Agent or Proxy 151 Mobile Access Gateway 152 [I-D.ietf-csi-proxy-send]. 154 4. SEND Certificate profile 156 SEND certificates MUST comply with the RPKI resource profile 157 [I-D.ietf-sidr-res-certs]. A Router Authorization Certificate 158 example is included in the Appendix A. 160 In sections 2, 4.9.10 and 4.9.11 [I-D.ietf-sidr-res-certs] it is 161 stated that RFC 3779 resource extensions MUST be critical and MUST be 162 present in all Resource Certificates. SEND certificates MUST include 163 the IP Resources extension [RFC3779]. This extension MUST include at 164 least one address block for the IPv6 Address Family (AFI=0002), as 165 described in Section 4.9.10 of [I-D.ietf-sidr-res-certs]. SEND 166 certificates MUST NOT have more than one IP Resources extension. 168 4.1. Unconstrained Certified subnet prefixes 170 Section 7.3 of [RFC3971] defines the Unconstrained Certified subnet 171 prefixes category by using certificates containing either the null 172 prefix or no prefix extension at all. 174 When using RPKI certificate profile, prefix extensions are mandatory 175 and the null prefix MUST be validated. However, a certificate may 176 inherit its parent's prefix or range by using the "inherit" element 177 for IPv6 AFI as defined in RFC3779. The use of the "inherit" element 178 is permited in [I-D.ietf-sidr-res-certs]. 180 Consequently, this document updates section 7.3 of RFC 3971 adding 181 the following text under Unconstrained: 183 Network operators that do not want to constrain routers to route 184 particular subnet prefixes but rather inherit them from its parent 185 certificate, should configure routers with certificates containing 186 the "inherit" element for IPv6 AFI. 188 5. Deployment Models 190 RFC 3971 describes two deployment models:centralized and 191 decentralized. These models were differentiated by having one or 192 many trust anchor. In this document we introduce two new deployment 193 models, not based on the number of trust anchors but on the 194 localization of the SEND deployment. 196 The local SEND deployment model represent those cases where SEND 197 deployment is confined to an administrative domain. In this 198 scenario, the deployment of SEND MAY be done independently of the 199 existence of deployment in the upper RPKI hierarchy (i.e. an end user 200 could perform local SEND deployment without the need of RPKI 201 deployment in its ISP). This model requires the use of local trust 202 anchors and configuring islands of trust. This model MAY include 203 Unique Local Addresses(ULAs) [RFC4193]. 205 The public SEND deployment models represent those cases where SEND 206 deployment is linked to RPKI deployment as described in 207 [I-D.ietf-sidr-arch]. Trust anchor material MAY be part of a 208 different administrative domain (i.e. RIR, NIR or ISPs). It is a 209 global model suitable for mobile users. 211 These two models are not mutually exclusive. It is entirely possible 212 to have a hybrid model that incorporates features from both these 213 models. In one such hybrid deployment model most IP address 214 resources (e.g. global unicast addresses) would be certified under 215 the global RPKI, while some others (e.g., ULAs) are certified under 216 local TAs. 218 6. Trust Anchor Material 220 Relying parties (e.g., end hosts that implement SEND and process 221 these router certificates) MUST be configured with one or more trust 222 anchors to enable validation of the routers' certificates. Section 223 6.5 of RFC 3971 lists the trust anchor configurations for end hosts 224 using SEND. 226 In the local SEND deployment model, it is possible to use as trust 227 anchor a certificate that includes in its RFC 3779 address extension 228 the prefix ::/0. In this case no new trust anchor material would be 229 needed when renumbering. However, if trying to move from the local 230 deployment model to the public deployment model, new trust anchor 231 material will have to be distributed to relying parties. 233 [I-D.ietf-sidr-ta] describes a scenario where relying parties use as 234 trust anchor material ETA (External Trust Anchor) certificates, which 235 do not list any address space. This configuration allows network 236 renumbering without the need for distributing new trust anchor 237 material in both the local and the public model. 239 This document updates Section 6.5 of RFC3971, where the following 240 paragraph should be added: 242 An end host MAY use as trust anchor material ETA certificates as 243 described in [I-D.ietf-sidr-ta]. In this case, the end host MUST 244 obtain the correspondent RTA (RPKI Trust Anchor) certificates from 245 the ETA repository in order to complete the Name Type Field of the 246 ICMP Trust Anchor Option, which MUST always refer to a trust anchor 247 certificate that validates Section 9. 249 7. Extended Key Usage Values 251 The Internet PKI document [RFC5280] specifies the extended key usage 252 X.509 certificate extension. The extension indicates one or more 253 purposes for which the certified public key may be used. The 254 extended key usage extension can be used in conjunction with key 255 usage extension, which indicates the intended purpose of the 256 certified public key. The Extended Key Usage extension is defined as 257 optional in [I-D.ietf-sidr-res-certs] for end entity certificates but 258 MUST be present when issuing end entity certificates for SEND. 260 The extended key usage extension syntax is repeated here for 261 convenience: 263 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 265 KeyPurposeId ::= OBJECT IDENTIFIER 267 This specification defines three KeyPurposeId values: one for 268 authorizing routers, one for authorizing proxies, and one for address 269 owners. 271 The inclusion of the router authorization value indicates that the 272 certificate has been issued for allowing the router to advertise 273 prefix(es) that are mentioned using the X.509 extensions for IP 274 addresses and AS identifiers [RFC3779] 276 The inclusion of the proxy authorization value indicates that the 277 certificate has been issued for allowing the proxy to perform 278 proxying of neighbor discovery messages for the prefix(es) that are 279 mentioned using the X.509 extensions for IP addresses and AS 280 identifiers [RFC3779] 282 The inclusion of the owner authorization value indicates that the 283 certificate has been issued for allowing the node to use the 284 address(es) or prefix(es) that are mentioned using the X.509 285 extensions for IP addresses and AS identifiers [RFC3779]. For an 286 address in such certificate the host can assign the address, send/ 287 receive traffic from this address, and can respond to NSes about that 288 address. For a prefix in such certificate the node can perform all 289 the above mentioned operations for any address in that prefix. Also, 290 when a prefix is present in the certificate with the owner 291 authorization value, the node cannot advertise the prefix in an RA. 293 Inclusion of multiple values indicates that the certified public key 294 is appropriate for use by a node performing more than one of these 295 functions. 297 send-kp OBJECT IDENTIFIER ::= 298 { iso(1) identified-organization(3) dod(6) internet(1) 299 security(5) mechanisms(5) pkix(7) kp(3) } 301 id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } 303 id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 } 305 id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } 307 As described in [I-D.ietf-sidr-res-certs], the extended key usage 308 extension, if present, MUST be non-critical. 310 Relying Parties MUST require the extended key usage extension to be 311 present in a certificate, and they MAY require a particular 312 KeyPurposeId value to be present (such as id-kp-sendRouter or id-kp- 313 sendProxy) within the extended key usage extension. If multiple 314 KeyPurposeId values are included, the relying parties need not 315 recognize all of them, as long as the required KeyPurposeId value is 316 present.Relying parties MUST reject certificates that do not contain 317 one of the three KeyPurposeIds defined above even if they include the 318 anyExtendedKeyUsage OID defined in [RFC5280]. 320 8. CRL profile and revocation 322 RPKI requires the use of CRLs [I-D.ietf-sidr-res-certs].The host will 323 obtain the necessary CRLs and perform the certificate validation 324 method described in [I-D.ietf-sidr-res-certs]. 326 8.1. OCSP Considerations 328 By adopting the [I-D.ietf-sidr-res-certs] as the certificate profile 329 for SEND, the use of the OCSP protocol is not allowed by the RPKI 330 Certicate Policies [I-D.ietf-sidr-cp]. As CRLs are expected to be 331 small, the fetching of the required CRLs are not expected to demand 332 important bandwidth. 334 9. Certificate validation 336 This section updates section 6.3.1 of [RFC3971] by introducing new 337 validations without introducing any conflict. 339 The host MUST perform the certificate validation method described in 340 [I-D.ietf-sidr-res-certs]. 342 The validation of certificates that uses the "inherit" element is 343 describe in RFC 3779 where the existance of a parent prefix or range 344 is required. 346 10. IANA Considerations 348 This document makes use of object identifiers to identify Extended 349 Key Usages (EKUs) and the ASN.1 module found in Appendix B. The EKUs 350 and ASN.1 module OID are registered in an arc delegated by IANA to 351 the PKIX Working Group. No further action by IANA is necessary for 352 this document. 354 11. Security Considerations 356 The certification authority needs to ensure that the correct values 357 for the extended key usage are inserted in each certificate that is 358 issued. Relying parties may accept or reject a particular 359 certificate for an intended use based on the information provided in 360 these extensions. Incorrect representation of the information in the 361 extended key usage field can cause the relying party to reject an 362 otherwise appropriate certificate or accept a certificate that ought 363 to be rejected. In particular, since a SEND certificate attests that 364 its subject is authorized to play a given role in the SEND protocol, 365 certificates that contain incorrect EKU values can enable some of the 366 same attacks that SEND was meant to prevent. For example, if a 367 malicious host can obtain a certificate that authorizes it to act as 368 a router for a given prefix, then it can masquerade as a router for 369 that prefix, e.g., in order to attract traffic from local nodes. 371 12. Acknowledgements 373 The authors would like to thank Stephen Kent, Sean Turner, Roni Even, 374 Richard Barnes, Alexey Melnikov, Jari Arkko, David Harrington and Tim 375 Polk for their reviews and suggestions on the earlier versions of 376 this document. 378 13. References 380 13.1. Normative References 382 [I-D.ietf-csi-proxy-send] 383 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 384 ND Support for SEND", draft-ietf-csi-proxy-send-01 (work 385 in progress), July 2009. 387 [I-D.ietf-sidr-cp] 388 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 389 Policy (CP) for the Resource PKI (RPKI)", 390 draft-ietf-sidr-cp-08 (work in progress), January 2010. 392 [I-D.ietf-sidr-res-certs] 393 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 394 X.509 PKIX Resource Certificates", 395 draft-ietf-sidr-res-certs-18 (work in progress), May 2010. 397 [I-D.ietf-sidr-ta] 398 Michaelson, G., Kent, S., and G. Huston, "A Profile for 399 Trust Anchor Material for the Resource Certificate PKI", 400 draft-ietf-sidr-ta-04 (work in progress), May 2010. 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 406 Addresses and AS Identifiers", RFC 3779, June 2004. 408 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 409 Neighbor Discovery (SEND)", RFC 3971, March 2005. 411 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 412 Addresses", RFC 4193, October 2005. 414 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 415 Housley, R., and W. Polk, "Internet X.509 Public Key 416 Infrastructure Certificate and Certificate Revocation List 417 (CRL) Profile", RFC 5280, May 2008. 419 13.2. Informative References 421 [I-D.ietf-sidr-arch] 422 Lepinski, M. and S. Kent, "An Infrastructure to Support 423 Secure Internet Routing", draft-ietf-sidr-arch-09 (work in 424 progress), October 2009. 426 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 427 Scheme", RFC 5781, February 2010. 429 Appendix A. Router Authorization Certificate example 431 Certificate: 432 Data: 433 Version: 3 (0x2) 434 Serial Number: 29 (0x1d) 435 Signature Algorithm: sha256WithRSAEncryption 436 Issuer: CN=EXAMPLE-CA-2342342652346 437 Validity 438 Not Before: Feb 15 23:06:53 2010 GMT 439 Not After : Feb 15 23:06:53 2011 GMT 440 Subject: CN=SEND-EXAMPLE-123432 441 Subject Public Key Info: 442 Public Key Algorithm: rsaEncryption 443 RSA Public Key: (2048 bit) 444 Modulus (2048 bit): 445 00:bf:64:da:82:fb:b6:fd:a6:2d:c4:3a:10:d7:2c: 446 7b:8c:22:0a:30:b7:45:b1:7d:ae:c0:fd:f1:06:04: 447 5b:4a:6c:21:e7:de:15:cb:9a:07:c8:c4:80:6f:55: 448 cd:71:33:01:04:9f:87:57:db:d5:b3:c7:91:c5:81: 449 28:7f:a8:eb:b1:53:80:3a:01:8a:7c:97:d2:d3:41: 450 92:f4:68:db:3b:86:64:12:24:1e:e1:84:f8:33:5c: 451 0f:fa:ae:8a:a0:1f:e7:b7:4e:5a:ad:0a:a0:a1:2d: 452 42:5a:54:10:37:e2:13:84:88:ed:70:e4:76:6c:d6: 453 75:ab:8a:5c:c9:42:39:60:55:49:c2:66:ee:e7:64: 454 a1:67:fa:69:27:de:f6:2f:55:4d:09:89:29:75:c0: 455 61:02:41:7e:99:4f:81:1d:78:5a:45:8b:1c:9c:85: 456 87:76:51:a3:24:3b:0e:63:72:e8:b9:c5:81:32:91: 457 46:bb:87:81:82:5d:14:48:60:4a:ae:79:4f:f4:7e: 458 bd:ce:cf:01:de:19:e0:34:1a:12:fe:10:9d:1e:a6: 459 91:8b:28:ca:d6:83:71:8a:f3:39:fa:7a:49:c6:36: 460 b5:66:39:3a:a3:f8:02:70:a1:7a:8c:92:55:bd:b6: 461 84:cf:18:02:78:82:4f:2f:8e:f1:08:db:54:02:e0: 462 c5:e9 463 Exponent: 65537 (0x10001) 464 X509v3 extensions: 465 X509v3 Certificate Policies: critical 466 Policy: 1.3.6.1.5.5.7.14.2 468 X509v3 Authority Key Identifier: 469 keyid:F7:EB:16:AB:D2:43:E3:72:16:41: 470 E0:B7:99:CA:1F:A4:37:C3:74:FB 472 Authority Information Access: 473 CA Issuers - URI:rsync://rsync.example.exampledomain/ 474 EXAMPLE-CA-2342342652346/EXAMPLE-CA.cer 476 X509v3 CRL Distribution Points: 478 URI:rsync://rsync.example.exampledomain/ 479 EXAMPLE-CA-2342342652346/EXAMPLE-CA.crl 481 X509v3 Subject Key Identifier: 482 5F:AB:EC:98:8A:E1:47:41:55:4F:67:57:98: 483 22:CE:99:85:8F:2A:85 484 X509v3 Key Usage: critical 485 Digital Signature 486 X509v3 Extended Key Usage: 487 1.3.6.1.5.5.7.3.23 488 sbgp-ipAddrBlock: critical 489 IPv6: 490 2001:db8:CAFE:BEBE::/64 492 Signature Algorithm: sha256WithRSAEncryption 493 6f:ec:08:b2:5f:2c:84:6b:99:4c:fe:7d:00:db:fa:c1:90:a2: 494 de:34:0a:31:b0:f6:f1:95:d9:4a:ef:09:79:90:51:84:a9:5a: 495 a1:5a:a2:cd:09:69:e2:cb:ff:da:f1:34:32:bd:cc:b5:c8:7e: 496 b1:fa:46:78:93:a5:cc:d5:1b:03:30:42:c4:ab:55:d7:e5:0d: 497 74:de:e8:f3:00:6b:68:df:0d:64:ba:58:49:d0:0b:5d:a5:7c: 498 82:ec:5c:95:18:fe:67:f5:25:21:9c:07:8e:ba:81:80:c8:c2: 499 95:e6:0a:ea:bd:4b:a2:fc:10:53:cf:c9:16:83:83:88:7c:06: 500 39:04:dd:49:4e:75:b5:4b:6b:8d:4c:9f:d7:59:33:c3:95:c4: 501 7f:48:f5:83:da:37:e0:c1:a5:5d:09:7d:65:78:b6:77:a7:f9: 502 49:59:f8:83:3e:14:dd:e0:86:e1:5e:fa:6d:42:ee:dd:eb:c0: 503 f6:4b:0a:31:f1:37:1b:77:12:79:99:1b:2f:d5:e7:7f:2f:a2: 504 6e:54:71:17:17:0d:a4:7b:7d:5a:6e:40:02:1d:5c:6a:06:ab: 505 5d:33:ea:b6:8a:1b:f6:85:16:ef:d4:00:db:54:e8:ac:53:b8: 506 0f:39:d8:a4:3e:9b:87:41:f3:f5:05:d6:a0:44:cc:82:bc:b9: 507 fd:72:40:ff 509 Appendix B. ASN.1 Module 511 SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1) 512 security(5) mechanisms(5) pkix(7) id-mod(0) 513 id-mod-send-cert-extns(TBD) } 515 DEFINITIONS IMPLICIT TAGS ::= 517 BEGIN 519 -- OID Arc 521 id-kp OBJECT IDENTIFIER ::= 522 { iso(1) identified-organization(3) dod(6) internet(1) 523 security(5) mechanisms(5) pkix(7) kp(3) } 525 -- Extended Key Usage Values 527 id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } 528 id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 } 529 id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } 531 END 533 Authors' Addresses 535 Roque Gagliano 536 Cisco Systems 537 Avenue des Uttins 5 538 Rolle, 1180 539 Switzerland 541 Email: rogaglia@cisco.com 543 Suresh Krishnan 544 Ericsson 545 8400 Decarie Blvd. 546 Town of Mount Royal, QC 547 Canada 549 Phone: +1 514 345 7900 x42871 550 Email: suresh.krishnan@ericsson.com 552 Ana Kukec 553 University of Zagreb 554 Unska 3 555 Zagreb 556 Croatia 558 Email: ana.kukec@fer.hr