idnits 2.17.00 (12 Aug 2021) /tmp/idnits16315/draft-ietf-sidr-bgpsec-pki-profiles-18.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 (July 21, 2016) is 2129 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: draft-ietf-sidr-rfc6485bis has been published as RFC 7935 == Outdated reference: draft-ietf-sidr-bgpsec-algs has been published as RFC 8208 == Outdated reference: draft-ietf-sidr-bgpsec-protocol has been published as RFC 8205 Summary: 0 errors (**), 0 flaws (~~), 4 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: January 22, 2017 S. Kent 7 BBN 8 July 21, 2016 10 A Profile for BGPsec Router Certificates, 11 Certificate Revocation Lists, and Certification Requests 12 draft-ietf-sidr-bgpsec-pki-profiles-18 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) 2016 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.1. Subject . . . . . . . . . . . . . . . . . . . . . 5 76 3.1.2. Subject Public Key Info . . . . . . . . . . . . . . . 5 77 3.1.3. BGPsec Router Certificate Version 3 Extension Fields . 6 78 3.1.3.1. Basic Constraints . . . . . . . . . . . . . . . . 6 79 3.1.3.2. Extended Key Usage . . . . . . . . . . . . . . . . 6 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 . . 8 86 4. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 5. Implementation Considerations . . . . . . . . . . . . . . . . . 9 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 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 Border Gateway Protocol Security 102 protocol (BGPsec). Such certificates are termed "BGPsec Router 103 Certificates". The holder of the private key associated with a 104 BGPsec Router Certificate is authorized to send secure route 105 advertisements (BGPsec UPDATEs) on behalf of the AS(es) named in the 106 certificate. A router holding the private key is authorized to send 107 route advertisements (to its peers) that contain one or more of the 108 specified AS number as the last item in the AS PATH attribute. A key 109 property provided by BGPsec is that every AS along the AS PATH can 110 verify that the other ASes along the path have authorized the 111 advertisement of the given route (to the next AS along the AS PATH). 113 This document is a profile of [RFC6487], which is a profile of 114 [RFC5280]; thus this document updates [RFC6487]. It establishes 115 requirements imposed on a Resource Certificate that is used as a 116 BGPsec Router Certificate, i.e., it defines constraints for 117 certificate fields and extensions for the certificate to be valid in 118 this context. This document also profiles the certification requests 119 used to acquire BGPsec Router Certificates. Finally, this document 120 specifies the Relying Party (RP) certificate path validation 121 procedures for these certificates. 123 1.1. Terminology 125 It is assumed that the reader is familiar with the terms and concepts 126 described in "A Profile for X.509 PKIX Resource Certificates" 127 [RFC6487], "BGPsec Protocol Specification" [ID.sidr-bgpsec-protocol], 128 "A Border Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security 129 Vulnerabilities Analysis" [RFC4272], "Considerations in Validating 130 the Path in BGP" [RFC5123], and "Capability Advertisement with BGP-4" 131 [RFC5492]. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 2. Describing Resources in Certificates 140 Figure 1 depicts some of the entities in the RPKI and some of the 141 products generated by RPKI entities. IANA issues a Certification 142 Authority (CA) certificate to each Regional Internet Registry (RIR). 143 The RIR, in turn, issues a CA certificate to an Internet Service 144 Providers (ISP). The ISP in turn issues EE Certificates to itself to 145 enable verification of signatures on RPKI signed objects. The CA also 146 generate. The CA also generates Certificate Revocation Lists (CRLs). 147 These CA and EE certificates are referred to as "Resource 148 Certificates", and are profiled in [RFC6487]. The [RFC6480] 149 envisioned using Resource Certificates to enable verification of 150 Manifests [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482]. 151 ROAs and Manifests include the Resource Certificates used to verify 152 them. 154 +---------+ +------+ 155 | CA Cert |---| IANA | 156 +---------+ +------+ 157 \ 158 +---------+ +-----+ 159 | CA Cert |---| RIR | 160 +---------+ +-----+ 161 \ 162 +---------+ +-----+ 163 | CA Cert |---| ISP | 164 +---------+ +-----+ 165 / | | | 166 +-----+ / | | | +-----+ 167 | CRL |--+ | | +---| ROA | 168 +-----+ | | +-----+ 169 | | +----------+ 170 +----+ | +---| Manifest | 171 +-| EE |---+ +----------+ 172 | +----+ 173 +-----+ 174 Figure 1 176 This document defines another type of Resource Certificate, which is 177 referred to as a "BGPsec Router Certificate". The purpose of this 178 certificate is explained in Section 1 and falls within the scope of 179 appropriate uses defined within [RFC6484]. The issuance of BGPsec 180 Router Certificates has minimal impact on RPKI CAs because the RPKI 181 CA certificate and CRL profile remain unchanged (i.e., they are as 182 specified in [RFC6487]). Further, the algorithms used to generate 183 RPKI CA certificates that issue the BGPsec Router Certificates and 184 the CRLs necessary to check the validity of the BGPsec Router 185 Certificates remain unchanged (i.e., they are as specified in 186 [ID.sidr-rfc6485bis]). The only impact is that RPKI CAs will need to 187 be able to process a profiled certificate request (see Section 5) 188 signed with algorithms found in [ID.sidr-bgpsec-algs]. The use of 189 BGPsec Router Certificates in no way affects RPKI RPs that process 190 Manifests and ROAs because the public key found in the BGPsec Router 191 Certificate is used only to verify the signature on the BGPsec 192 certificate request (only CAs process these) and the signature on a 193 BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers 194 process these). 196 This document enumerates only the differences between this profile 197 and the profile in [RFC6487]. Note that BGPsec Router Certificates 198 are EE certificates and as such there is no impact on process 199 described in [RFC6916]. 201 3. Updates to [RFC6487] 203 3.1 BGPsec Router Certificate Fields 205 A BGPsec Router Certificate is a valid X.509 public key certificate, 206 consistent with the PKIX profile [RFC5280], containing the fields 207 listed in this section. This profile is also based on [RFC6487] and 208 only the differences between this profile and the profile in 209 [RFC6487] are specified below. 211 3.1.1.1. Subject 213 This field identifies the router to which the certificate has been 214 issued. Consistent with [RFC6487], only two attributes are allowed 215 in the Subject field: common name and serial number. Moreover, the 216 only common name encoding options that are supported are 217 printableString and UTF8String. For BGPsec Router Certificates, it 218 is RECOMMENDED that the common name attribute contain the literal 219 string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded 220 as eight hexadecimal digits and that the serial number attribute 221 contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) 222 encoded as eight hexadecimal digits. If there is more than one AS 223 number, the choice of which to include in the common name is at the 224 discretion of the Issuer. If the same certificate is issued to more 225 than one router (hence the private key is shared among these 226 routers), the choice of the router ID used in this name is at the 227 discretion of the Issuer. Note that router IDs are not guaranteed to 228 be unique across the Internet, and thus the Subject name in a BGPsec 229 Router Certificate issued using this convention also is not 230 guaranteed to be unique across different issuers. However, each 231 certificate issued by an individual CA MUST contain a Subject name 232 that is unique within that context. 234 3.1.2. Subject Public Key Info 236 Refer to section 3.1 of [ID.sidr-bgpsec-algs]. 238 3.1.3. BGPsec Router Certificate Version 3 Extension Fields 240 3.1.3.1. Basic Constraints 242 BGPsec speakers are EEs; therefore, the Basic Constraints extension 243 must not be present, as per [RFC6487]. 245 3.1.3.2. Extended Key Usage 247 BGPsec Router Certificates MUST include the Extended Key Usage (EKU) 248 extension. As specified in [RFC6487] this extension MUST be marked 249 as non-critical. This document defines one EKU for BGPsec Router 250 Certificates: 252 id-kp OBJECT IDENTIFIER ::= 253 { iso(1) identified-organization(3) dod(6) internet(1) 254 security(5) mechanisms(5) pkix(7) kp(3) } 256 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 258 A BGPsec router MUST require the extended key usage extension to be 259 present in a BGPsec Router Certificate it receives. If multiple 260 KeyPurposeId values are included, the BGPsec routers need not 261 recognize all of them, as long as the required KeyPurposeId value is 262 present. BGPsec routers MUST reject certificates that do not contain 263 the BGPsec Router EKU even if they include the anyExtendedKeyUsage 264 OID defined in [RFC5280]. 266 3.1.3.3. Subject Information Access 268 This extension is not used in BGPsec Router Certificates. It MUST be 269 omitted. 271 3.1.3.4. IP Resources 273 This extension is not used in BGPsec Router Certificates. It MUST be 274 omitted. 276 3.1.3.5. AS Resources 278 Each BGPsec Router Certificate MUST include the AS Resource 279 Identifier Delegation extension, as specified in section 4.8.11 of 280 [RFC6487]. The AS Resource Identifier Delegation extension MUST 281 include one or more AS numbers, and the "inherit" element MUST NOT be 282 specified. 284 3.2. BGPsec Router Certificate Request Profile 285 Refer to section 6 of [RFC6487]. The only differences between this 286 profile and the profile in [RFC6487] are: 288 o The Basic Constraints extension: 290 If included, the CA MUST NOT honor the cA boolean if set to TRUE. 292 o The Extended Key Usage extension: 294 If included, id-kp-bgpsec-router MUST be present (see Section 295 3.1). If included, the CA MUST honor the request for id-kp- 296 bgpsec-router. 298 o The Subject Information Access extension: 300 If included, the CA MUST NOT honor the request to include the 301 extension. 303 o The SubjectPublicKeyInfo and PublicKey fields are specified in 304 [ID.sidr-bgpsec-algs]. 306 o The request is signed with the algorithms specified in [ID.sidr- 307 bgpsec-algs]. 309 3.3. BGPsec Router Certificate Validation 311 The validation procedure used for BGPsec Router Certificates is 312 identical to the validation procedure described in Section 7 of 313 [RFC6487] (and any RFC that updates this procedure), but using the 314 constraints applied come from this specification. For example, in 315 step 3: "the certificate contains all the field that must be present" 316 - refers to the fields that are required by this specification. 318 The differences are as follows: 320 o BGPsec Router Certificates MUST include the BGPsec Router EKU 321 defined in Section 3.1.3.2. 323 o BGPsec Router Certificates MUST NOT include the SIA extension. 325 o BGPsec Router Certificates MUST NOT include the IP Resource 326 extension. 328 o BGPsec Router Certificates MUST include the AS Resource Identifier 329 Delegation extension. 331 o BGPsec Router Certificate MUST include the "Subject Public Key 332 Info" described in [ID.sidr-bgpsec-algs] as it updates [ID.sidr- 333 rfc6485bis]. 335 NOTE: The cryptographic algorithms used by BGPsec routers are found 336 in [ID.sidr-bgpsec-algs]. Currently, the algorithms specified in 337 [ID.sidr-bgpsec-algs] and [ID.sidr-rfc6485bis] are different. BGPsec 338 RPs will need to support algorithms that are used to validate BGPsec 339 signatures as well as the algorithms that are needed to validate 340 signatures on BGPsec certificates, RPKI CA certificates, and RPKI 341 CRLs. 343 3.4. Router Certificates and Signing Functions in the RPKI 345 As described in Section 1, the primary function of BGPsec route 346 certificates in the RPKI is for use in the context of certification 347 of Autonomous System (AS) paths in the Border Gateway Protocol 348 Security protocol (BGPsec). 350 The private key associated with a router EE certificate may be used 351 multiple times in generating signatures in multiple instances of the 352 BGPsec_Path Attribute Signature Segments [ID.sidr-bgpsec-protocol]. 353 I.e., the BGPsec router certificate is used to validate multiple 354 signatures. 356 BGPsec router certificates are stored in the issuing CA's repository, 357 where a repository following RFC6481 MUST use a .cer filename 358 extension for the certificate file. 360 4. Design Notes 362 The BGPsec Router Certificate profile is based on the Resource 363 Certificate profile as specified in [ID.sidr-rfc6485bis]. As a 364 result, many of the design choices herein are a reflection of the 365 design choices that were taken in that prior work. The reader is 366 referred to [RFC6484] for a fuller discussion of those choices. 368 CAs are required by the Certificate Policy (CP) [RFC6484] to issue 369 properly formed BGPsec Router Certificates regardless of what is 370 present in the certification request so there is some flexibility 371 permitted in the certificate requests: 373 o BGPsec Router Certificates are always EE certificates; therefore, 374 requests to issue a CA certificate result in EE certificates; 376 o BGPsec Router Certificates are always EE certificates; therefore, 377 requests for Key Usage extension values keyCertSign and cRLSign 378 result in certificates with neither of these values; 380 o BGPsec Router Certificates always include the BGPsec Rouer EKU 381 value; therefore, request without the value result in certificates 382 with the value; and, 384 o BGPsec Router Certificates never include the Subject Information 385 Access extension; therefore, request with this extension result in 386 certificates without the extension. 388 Note that this behavior is similar to the CA including the AS 389 Resource Identifier Delegation extension in issued BGPsec Router 390 Certificates despite the fact it is not present in the request. 392 5. Implementation Considerations 394 This document permits the operator to include a list of ASNs in a 395 BGPsec Router Certificate. In that case, the router certificate would 396 become invalid if any one of the ASNs is removed from any superior CA 397 certificate along the path to a trust anchor. Operators could choose 398 to avoid this possibility by issuing a separate BGPsec Router 399 Certificate for each distinct ASN, so that the router certificates 400 for ASNs that are retained in the superior CA certificate would 401 remain valid. 403 6. Security Considerations 405 The Security Considerations of [RFC6487] apply. 407 A BGPsec Router Certificate will fail RPKI validation, as defined in 408 [RFC6487], because the algorithm suite is different. Consequently, a 409 RP needs to identify the EKU to determine the appropriate Validation 410 constraint. 412 A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to 413 encompass routers. It is a building block BGPsec and is used to 414 validate signatures on BGPsec Signature-Segment origination of 415 Signed-Path segments [ID.sidr-bgpsec-protocol]. Thus its essential 416 security function is the secure binding of one or more AS numbers to 417 a public key, consistent with the RPKI allocation/assignment 418 hierarchy. 420 Hash functions [ID.sidr-bgpsec-algs] are used when generating the two 421 key identifiers extension included in BGPsec certificates. However 422 as noted in [RFC6818], collision resistance is not a required 423 property of one-way hash functions when used to generate key 424 identifiers. Regardless, hash collisions are possible and if 425 detected an operator should be alerted. 427 7. IANA Considerations 428 This document makes use of two object identifiers in the SMI Registry 429 for PKIX. One is for the ASN.1 module in Appendix A and it comes 430 from the SMI Security for PKIX Module Identifier IANA registry (id- 431 mod-bgpsec-eku). The other is for the BGPsec router EKU defined in 432 Section 3.1.3.2 and Appendix A and it comes from the SMI Security for 433 PKIX Extended Key Purpose IANA registry. These OIDs were assigned 434 before management of the PKIX Arc was handed to IANA. No IANA 435 allocations are request of IANA, but please update the references in 436 those registries when this document is published by the RFC editor. 438 8. Acknowledgements 440 We would like to thank Geoff Huston, George Michaelson, and Robert 441 Loomans for their work on [RFC6487], which this work is based on. In 442 addition, the efforts of Steve Kent and Matt Lepinski were 443 instrumental in preparing this work. Additionally, we'd like to 444 thank Rob Austein, Roque Gagliano, Richard Hansen, Geoff Huston, 445 David Mandelberg, Sandra Murphy, and Sam Weiller for their reviews 446 and comments. 448 9. References 450 9.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, DOI 454 10.17487/RFC2119, March 1997, . 457 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 458 Addresses and AS Identifiers", RFC 3779, DOI 459 10.17487/RFC3779, June 2004, . 462 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 463 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 464 10.17487/RFC4271, January 2006, . 467 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 468 Housley, R., and W. Polk, "Internet X.509 Public Key 469 Infrastructure Certificate and Certificate Revocation List 470 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 471 . 473 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 474 X.509 PKIX Resource Certificates", RFC 6487, DOI 475 10.17487/RFC6487, February 2012, . 478 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 479 Infrastructure Certificate and Certificate Revocation List 480 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 481 2013, . 483 [ID.sidr-rfc6485bis] G. Huston and G. Michaelson, "The Profile for 484 Algorithms and Key Sizes for use in the Resource Public Key 485 Infrastructure", draft-ietf-sidr-rfc6485bis, work-in- 486 progress. 488 [ID.sidr-bgpsec-algs] S. Turner, "BGP Algorithms, Key Formats, & 489 Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in- 490 progress. 492 9.2. Informative References 494 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 495 RFC 4272, DOI 10.17487/RFC4272, January 2006, 496 . 498 [RFC5123] White, R. and B. Akyol, "Considerations in Validating the 499 Path in BGP", RFC 5123, DOI 10.17487/RFC5123, February 500 2008, . 502 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 503 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, 504 . 506 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 507 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 508 February 2012, . 510 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 511 Origin Authorizations (ROAs)", RFC 6482, DOI 512 10.17487/RFC6482, February 2012, . 515 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 516 Policy (CP) for the Resource Public Key Infrastructure 517 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 518 2012, . 520 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 521 "Manifests for the Resource Public Key Infrastructure 522 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 523 . 525 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 526 Procedure for the Resource Public Key Infrastructure 527 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 528 2013, . 530 [ID.sidr-bgpsec-protocol] Lepinksi, M., "BGPsec Protocol 531 Specification", draft-ietf-sidr-bgpsec-protocol, work-in- 532 progress. 534 Appendix A. ASN.1 Module 536 BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) 537 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) } 539 DEFINITIONS EXPLICIT TAGS ::= 541 BEGIN 543 -- EXPORTS ALL -- 545 -- IMPORTS NOTHING -- 547 -- OID Arc -- 549 id-kp OBJECT IDENTIFIER ::= { 550 iso(1) identified-organization(3) dod(6) internet(1) 551 security(5) mechanisms(5) kp(3) } 553 -- BGPsec Router Extended Key Usage -- 555 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 557 END 559 Authors' Addresses 561 Mark Reynolds 562 Island Peak Software 563 328 Virginia Road 564 Concord, MA 01742 566 Email: mcr@islandpeaksoftware.com 568 Sean Turner 569 sn3rd 571 EMail: sean@sn3rd.com 572 Stephen Kent 573 Raytheon BBN Technologies 574 10 Moulton St. 575 Cambridge, MA 02138 577 Email: kent@bbn.com