idnits 2.17.1 draft-ietf-sidr-bgpsec-pki-profiles-20.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 RFC6487, but the abstract doesn't seem to directly say this. It does mention RFC6487 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6487, updated by this document, for RFC5378 checks: 2006-06-09) -- 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 (January 4, 2017) is 2661 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) == Missing Reference: 'RFC6818' is mentioned on line 408, but not defined ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing Working Group M. Reynolds 3 Internet-Draft IPSw 4 Updates: 6487 (if approved) S. Turner 5 Intended status: Standard Track sn3rd 6 Expires: July 8, 2017 S. Kent 7 BBN 8 January 4, 2017 10 A Profile for BGPsec Router Certificates, 11 Certificate Revocation Lists, and Certification Requests 12 draft-ietf-sidr-bgpsec-pki-profiles-20 14 Abstract 16 This document defines a standard profile for X.509 certificates used 17 to enable validation of Autonomous System (AS) paths in the Border 18 Gateway Protocol (BGP), as part of an extension to that protocol 19 known as BGPsec. BGP is the standard for inter-domain routing in the 20 Internet; it is the "glue" that holds the Internet together. BGPsec 21 is being developed as one component of a solution that addresses the 22 requirement to provide security for BGP. The goal of BGPsec is to 23 provide full AS path validation based on the use of strong 24 cryptographic primitives. The end-entity (EE) certificates specified 25 by this profile are issued to routers within an Autonomous System. 26 Each of these certificates is issued under a Resource Public Key 27 Infrastructure (RPKI) Certification Authority (CA) certificate. 28 These CA certificates and EE certificates both contain the AS 29 Identifier Delegation extension. An EE certificate of this type 30 asserts that the router(s) holding the corresponding private key are 31 authorized to emit secure route advertisements on behalf of the 32 AS(es) specified in the certificate. This document also profiles the 33 format of certification requests, and specifies Relying Party (RP) 34 certificate path validation procedures for these EE certificates. 35 This document extends the RPKI; therefore, this documents updates the 36 RPKI Resource Certificates Profile (RFC 6487). 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Describing Resources in Certificates . . . . . . . . . . . . . 3 73 3. Updates to [RFC6487] . . . . . . . . . . . . . . . . . . . . . 5 74 3.1 BGPsec Router Certificate Fields . . . . . . . . . . . . . 5 75 3.1.1. Subject . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.1.2. Subject Public Key Info . . . . . . . . . . . . . . . 5 77 3.1.3. BGPsec Router Certificate Version 3 Extension Fields . 5 78 3.1.3.1. Basic Constraints . . . . . . . . . . . . . . . . 5 79 3.1.3.2. Extended Key Usage . . . . . . . . . . . . . . . . 5 80 3.1.3.3. Subject Information Access . . . . . . . . . . . . 6 81 3.1.3.4. IP Resources . . . . . . . . . . . . . . . . . . . 6 82 3.1.3.5. AS Resources . . . . . . . . . . . . . . . . . . . 6 83 3.2. BGPsec Router Certificate Request Profile . . . . . . . . 6 84 3.3. BGPsec Router Certificate Validation . . . . . . . . . . . 7 85 3.4. Router Certificates and Signing Functions in the RPKI . . 7 86 4. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 5. Implementation Considerations . . . . . . . . . . . . . . . . . 8 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 94 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 97 1. Introduction 99 This document defines a profile for X.509 end-entity (EE) 100 certificates [RFC5280] for use in the context of certification of 101 Autonomous System (AS) paths in the BGPsec. Such certificates are 102 termed "BGPsec Router Certificates". The holder of the private key 103 associated with a BGPsec Router Certificate is authorized to send 104 secure route advertisements (BGPsec UPDATEs) on behalf of the AS(es) 105 named in the certificate. A router holding the private key is 106 authorized to send route advertisements (to its peers) identifying 107 the router's ASN as the source of the advertisements. A key property 108 provided by BGPsec is that every AS along the AS PATH can verify that 109 the other ASes along the path have authorized the advertisement of 110 the given route (to the next AS along the AS PATH). 112 This document is a profile of [RFC6487], which is a profile of 113 [RFC5280]; thus this document updates [RFC6487]. It establishes 114 requirements imposed on a Resource Certificate that is used as a 115 BGPsec Router Certificate, i.e., it defines constraints for 116 certificate fields and extensions for the certificate to be valid in 117 this context. This document also profiles the certification requests 118 used to acquire BGPsec Router Certificates. Finally, this document 119 specifies the Relying Party (RP) certificate path validation 120 procedures for these certificates. 122 1.1. Terminology 124 It is assumed that the reader is familiar with the terms and concepts 125 described in "A Profile for X.509 PKIX Resource Certificates" 126 [RFC6487], "BGPsec Protocol Specification" [ID.sidr-bgpsec-protocol], 127 "A Border Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security 128 Vulnerabilities Analysis" [RFC4272], "Considerations in Validating 129 the Path in BGP" [RFC5123], and "Capability Advertisement with BGP-4" 130 [RFC5492]. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 [RFC2119]. 137 2. Describing Resources in Certificates 139 Figure 1 depicts some of the entities in the RPKI and some of the 140 products generated by RPKI entities. IANA issues a Certification 141 Authority (CA) certificate to each Regional Internet Registry (RIR). 142 The RIR, in turn, issues a CA certificate to an Internet Service 143 Provider (ISP). The ISP in turn issues EE Certificates to itself to 144 enable verification of signatures on RPKI signed objects. The CA 145 also generates Certificate Revocation Lists (CRLs). These CA and EE 146 certificates are referred to as "Resource Certificates", and are 147 profiled in [RFC6487]. [RFC6480] envisioned using Resource 148 Certificates to enable verification of Manifests [RFC6486] and Route 149 Origin Authorizations (ROAs) [RFC6482]. ROAs and Manifests include 150 the Resource Certificates used to verify them. 152 +---------+ +------+ 153 | CA Cert |---| IANA | 154 +---------+ +------+ 155 \ 156 +---------+ +-----+ 157 | CA Cert |---| RIR | 158 +---------+ +-----+ 159 \ 160 +---------+ +-----+ 161 | CA Cert |---| ISP | 162 +---------+ +-----+ 163 / | | | 164 +-----+ / | | | +-----+ 165 | CRL |--+ | | +---| ROA | 166 +-----+ | | +-----+ 167 | | +----------+ 168 +----+ | +---| Manifest | 169 +-| EE |---+ +----------+ 170 | +----+ 171 +-----+ 172 Figure 1 174 This document defines another type of Resource Certificate, which is 175 referred to as a "BGPsec Router Certificate". The purpose of this 176 certificate is explained in Section 1 and falls within the scope of 177 appropriate uses defined within [RFC6484]. The issuance of BGPsec 178 Router Certificates has minimal impact on RPKI CAs because the RPKI 179 CA certificate and CRL profile remain unchanged (i.e., they are as 180 specified in [RFC6487]). Further, the algorithms used to generate 181 RPKI CA certificates that issue the BGPsec Router Certificates and 182 the CRLs necessary to check the validity of the BGPsec Router 183 Certificates remain unchanged (i.e., they are as specified in 184 [RFC7935]). The only impact is that RPKI CAs will need to be able to 185 process a profiled certificate request (see Section 5) signed with 186 algorithms found in [ID.sidr-bgpsec-algs]. BGPsec Router 187 Certificates are used only to verify the signature on the BGPsec 188 certificate request (only CAs process these) and the signature on a 189 BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers 190 process these); BGPsec Router Certificates are not used to process 191 Manifests and ROAs or verify signatures on Certificates or CRLs. 193 This document enumerates only the differences between this profile 194 and the profile in [RFC6487]. Note that BGPsec Router Certificates 195 are EE certificates and as such there is no impact on process 196 described in [RFC6916]. 198 3. Updates to [RFC6487] 200 3.1 BGPsec Router Certificate Fields 202 A BGPsec Router Certificate is consistent with the profile in 203 [RFC6487] as modified by the specifications in this section. As 204 such, it is a valid X.509 public key certificate and consistent with 205 the PKIX profile [RFC5280]. The differences between this profile and 206 the profile in [RFC6487] are specified in this section. 208 3.1.1. Subject 210 Common name encoding options that are supported are printableString 211 and UTF8String. For BGPsec Router Certificates, it is RECOMMENDED 212 that the common name attribute contain the literal string "ROUTER-" 213 followed by the 32-bit AS Number [RFC3779] encoded as eight 214 hexadecimal digits and that the serial number attribute contain the 215 32-bit BGP Identifier [RFC4271] (i.e., the router ID) encoded as 216 eight hexadecimal digits. If there is more than one AS number, the 217 choice of which to include in the common name is at the discretion of 218 the Issuer. If the same certificate is issued to more than one router 219 (hence the private key is shared among these routers), the choice of 220 the router ID used in this name is at the discretion of the Issuer. 222 3.1.2. Subject Public Key Info 224 Refer to section 3.1 of [ID.sidr-bgpsec-algs]. 226 3.1.3. BGPsec Router Certificate Version 3 Extension Fields 228 3.1.3.1. Basic Constraints 230 BGPsec speakers are EEs; therefore, the Basic Constraints extension 231 must not be present, as per [RFC6487]. 233 3.1.3.2. Extended Key Usage 235 BGPsec Router Certificates MUST include the Extended Key Usage (EKU) 236 extension. As specified in [RFC6487] this extension must be marked 237 as non-critical. This document defines one EKU for BGPsec Router 238 Certificates: 240 id-kp OBJECT IDENTIFIER ::= 241 { iso(1) identified-organization(3) dod(6) internet(1) 242 security(5) mechanisms(5) pkix(7) kp(3) } 244 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 246 A BGPsec router MUST require the extended key usage extension to be 247 present in a BGPsec Router Certificate it receives. If multiple 248 KeyPurposeId values are included, the BGPsec routers need not 249 recognize all of them, as long as the required KeyPurposeId value is 250 present. BGPsec routers MUST reject certificates that do not contain 251 the BGPsec Router EKU even if they include the anyExtendedKeyUsage 252 OID defined in [RFC5280]. 254 3.1.3.3. Subject Information Access 256 This extension is not used in BGPsec Router Certificates. It MUST be 257 omitted. 259 3.1.3.4. IP Resources 261 This extension is not used in BGPsec Router Certificates. It MUST be 262 omitted. 264 3.1.3.5. AS Resources 266 Each BGPsec Router Certificate MUST include the AS Resource 267 Identifier Delegation extension, as specified in section 4.8.11 of 268 [RFC6487]. The AS Resource Identifier Delegation extension MUST 269 include one or more AS numbers, and the "inherit" element MUST NOT be 270 specified. 272 3.2. BGPsec Router Certificate Request Profile 274 Refer to section 6 of [RFC6487]. The only differences between this 275 profile and the profile in [RFC6487] are: 277 o The Basic Constraints extension: 279 If included, the CA MUST NOT honor the cA boolean if set to TRUE. 281 o The Extended Key Usage extension: 283 If included, id-kp-bgpsec-router MUST be present (see Section 284 3.1). If included, the CA MUST honor the request for id-kp- 285 bgpsec-router. 287 o The Subject Information Access extension: 289 If included, the CA MUST NOT honor the request to include the 290 extension. 292 o The SubjectPublicKeyInfo field is specified in [ID.sidr-bgpsec- 293 algs]. 295 o The request is signed with the algorithms specified in [ID.sidr- 296 bgpsec-algs]. 298 3.3. BGPsec Router Certificate Validation 300 The validation procedure used for BGPsec Router Certificates is 301 identical to the validation procedure described in Section 7 of 302 [RFC6487] (and any RFC that updates this procedure), as modified 303 below. For example, in step 3: "The certificate contains all field 304 that must be present" - refers to the fields that are required by 305 this specification. 307 The differences are as follows: 309 o BGPsec Router Certificates MUST include the BGPsec Router EKU 310 defined in Section 3.1.3.2. 312 o BGPsec Router Certificates MUST NOT include the SIA extension. 314 o BGPsec Router Certificates MUST NOT include the IP Resource 315 extension. 317 o BGPsec Router Certificates MUST include the AS Resource Identifier 318 Delegation extension. 320 o BGPsec Router Certificate MUST include the subjectPublicKeyInfo 321 described in [ID.sidr-bgpsec-algs]. 323 NOTE: BGPsec RPs will need to support the algorithms in [ID.sidr- 324 bgpsec-algs], which are used to validate BGPsec signatures, as well 325 as the algorithms in [RFC7935], which are needed to validate 326 signatures on BGPsec certificates, RPKI CA certificates, and RPKI 327 CRLs. 329 3.4. Router Certificates and Signing Functions in the RPKI 331 As described in Section 1, the primary function of BGPsec route 332 certificates in the RPKI is for use in the context of certification 333 of Autonomous System (AS) paths in the BGPsec protocol. 335 The private key associated with a router EE certificate may be used 336 multiple times in generating signatures in multiple instances of the 337 BGPsec_Path Attribute Signature Segments [ID.sidr-bgpsec-protocol]. 338 I.e., the BGPsec router certificate is used to validate multiple 339 signatures. 341 BGPsec router certificates are stored in the issuing CA's repository, 342 where a repository following RFC6481 MUST use a .cer filename 343 extension for the certificate file. 345 4. Design Notes 347 The BGPsec Router Certificate profile is based on the Resource 348 Certificate profile as specified in [RFC7935]. As a result, many of 349 the design choices herein are a reflection of the design choices that 350 were taken in that prior work. The reader is referred to [RFC6484] 351 for a fuller discussion of those choices. 353 CAs are required by the Certificate Policy (CP) [RFC6484] to issue 354 properly formed BGPsec Router Certificates regardless of what is 355 present in the certification request so there is some flexibility 356 permitted in the certificate requests: 358 o BGPsec Router Certificates are always EE certificates; therefore, 359 requests to issue a CA certificate result in EE certificates; 361 o BGPsec Router Certificates are always EE certificates; therefore, 362 requests for Key Usage extension values keyCertSign and cRLSign 363 result in certificates with neither of these values; 365 o BGPsec Router Certificates always include the BGPsec Rouer EKU 366 value; therefore, request without the value result in certificates 367 with the value; and, 369 o BGPsec Router Certificates never include the Subject Information 370 Access extension; therefore, request with this extension result in 371 certificates without the extension. 373 Note that this behavior is similar to the CA including the AS 374 Resource Identifier Delegation extension in issued BGPsec Router 375 Certificates despite the fact it is not present in the request. 377 5. Implementation Considerations 379 This document permits the operator to include a list of ASNs in a 380 BGPsec Router Certificate. In that case, the router certificate would 381 become invalid if any one of the ASNs is removed from any superior CA 382 certificate along the path to a trust anchor. Operators could choose 383 to avoid this possibility by issuing a separate BGPsec Router 384 Certificate for each distinct ASN, so that the router certificates 385 for ASNs that are retained in the superior CA certificate would 386 remain valid. 388 6. Security Considerations 390 The Security Considerations of [RFC6487] apply. 392 A BGPsec Router Certificate will fail RPKI validation, as defined in 393 [RFC6487], because the cryptographic algorithms used are different. 394 Consequently, a RP needs to identify the EKU to determine the 395 appropriate Validation constraint. 397 A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to 398 encompass routers. It is a building block BGPsec and is used to 399 validate signatures on BGPsec Signature-Segment origination of 400 Signed-Path segments [ID.sidr-bgpsec-protocol]. Thus its essential 401 security function is the secure binding of one or more AS numbers to 402 a public key, consistent with the RPKI allocation/assignment 403 hierarchy. 405 Hash functions [ID.sidr-bgpsec-algs] are used when generating the two 406 key identifier extensions (i.e., Subject Key Identifier and Issuer 407 Key Identifier) included in BGPsec certificates. However as noted in 408 [RFC6818], collision resistance is not a required property of one-way 409 hash functions when used to generate key identifiers. Regardless, 410 hash collisions are unlikely, but they are possible and if detected 411 an operator should be alerted. A subject key identifier collision 412 might cause the incorrect certificate to be selected from the cache, 413 resulting in a failed signature validation. 415 7. IANA Considerations 417 This document makes use of two object identifiers in the SMI Registry 418 for PKIX. One is for the ASN.1 module in Appendix A and it comes 419 from the SMI Security for PKIX Module Identifier IANA registry (id- 420 mod-bgpsec-eku). The other is for the BGPsec router EKU defined in 421 Section 3.1.3.2 and Appendix A and it comes from the SMI Security for 422 PKIX Extended Key Purpose IANA registry. These OIDs were assigned 423 before management of the PKIX Arc was handed to IANA. No IANA 424 allocations are request of IANA, but please update the references in 425 those registries when this document is published by the RFC editor. 427 8. Acknowledgements 429 We would like to thank Geoff Huston, George Michaelson, and Robert 430 Loomans for their work on [RFC6487], which this work is based on. In 431 addition, the efforts of Matt Lepinski were instrumental in preparing 432 this work. Additionally, we'd like to thank Rob Austein, Roque 433 Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra 434 Murphy, and Sam Weiller for their reviews and comments. 436 9. References 438 9.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, DOI 442 10.17487/RFC2119, March 1997, . 445 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 446 Addresses and AS Identifiers", RFC 3779, DOI 447 10.17487/RFC3779, June 2004, . 450 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 451 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 452 10.17487/RFC4271, January 2006, . 455 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 456 Housley, R., and W. Polk, "Internet X.509 Public Key 457 Infrastructure Certificate and Certificate Revocation List 458 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 459 . 461 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 462 "Manifests for the Resource Public Key Infrastructure 463 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 464 . 466 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 467 X.509 PKIX Resource Certificates", RFC 6487, DOI 468 10.17487/RFC6487, February 2012, . 471 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 472 Algorithms and Key Sizes for Use in the Resource Public Key 473 Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 474 2016, . 476 [ID.sidr-bgpsec-protocol] Lepinski, M. and K. Sriram, "BGPsec 477 Protocol Specification", draft-ietf-sidr-bgpsec-protocol, 478 work-in-progress. 480 [ID.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & 481 Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in- 482 progress. 484 9.2. Informative References 486 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 487 RFC 4272, DOI 10.17487/RFC4272, January 2006, 488 . 490 [RFC5123] White, R. and B. Akyol, "Considerations in Validating the 491 Path in BGP", RFC 5123, DOI 10.17487/RFC5123, February 492 2008, . 494 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 495 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, 496 . 498 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 499 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 500 February 2012, . 502 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 503 Origin Authorizations (ROAs)", RFC 6482, DOI 504 10.17487/RFC6482, February 2012, . 507 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 508 Policy (CP) for the Resource Public Key Infrastructure 509 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 510 2012, . 512 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 513 "Manifests for the Resource Public Key Infrastructure 514 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 515 . 517 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 518 Procedure for the Resource Public Key Infrastructure 519 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 520 2013, . 522 Appendix A. ASN.1 Module 524 BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) 525 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) } 527 DEFINITIONS EXPLICIT TAGS ::= 529 BEGIN 531 -- EXPORTS ALL -- 533 -- IMPORTS NOTHING -- 535 -- OID Arc -- 537 id-kp OBJECT IDENTIFIER ::= { 538 iso(1) identified-organization(3) dod(6) internet(1) 539 security(5) mechanisms(5) pkix(7) kp(3) } 541 -- BGPsec Router Extended Key Usage -- 543 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 545 END 547 Authors' Addresses 549 Mark Reynolds 550 Island Peak Software 551 328 Virginia Road 552 Concord, MA 01742 554 Email: mcr@islandpeaksoftware.com 556 Sean Turner 557 sn3rd 559 EMail: sean@sn3rd.com 561 Stephen Kent 562 Raytheon BBN Technologies 563 10 Moulton St. 564 Cambridge, MA 02138 566 Email: kent@bbn.com