idnits 2.17.1 draft-ietf-sidr-bgpsec-pki-profiles-15.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 (November 5, 2015) is 3095 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) -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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 IECA 6 Expires: May 8, 2016 S. Kent 7 BBN 8 November 5, 2015 10 A Profile for BGPsec Router Certificates, 11 Certificate Revocation Lists, and Certification Requests 12 draft-ietf-sidr-bgpsec-pki-profiles-15 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) 2015 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 . . . . . . . . 7 84 3.3. BGPsec Router Certificate Validation . . . . . . . . . . . 7 85 4. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 92 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 93 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 96 1. Introduction 98 This document defines a profile for X.509 end-entity (EE) 99 certificates [RFC5280] for use in the context of certification of 100 Autonomous System (AS) paths in the Border Gateway Protocol Security 101 protocol (BGPsec). Such certificates are termed "BGPsec Router 102 Certificates". The holder of the private key associated with a 103 BGPsec Router Certificate is authorized to send secure route 104 advertisements (BGPsec UPDATEs) on behalf of the AS(es) named in the 105 certificate. A router holding the private key is authorized to send 106 route advertisements (to its peers) that contain one or more of the 107 specified AS number as the last item in the AS PATH attribute. A key 108 property provided by BGPsec is that every AS along the AS PATH can 109 verify that the other ASes along the path have authorized the 110 advertisement of 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 Providers (ISP). The ISP in turn issues EE Certificates to itself to 144 enable verification of signatures on RPKI signed objects. The CA also 145 generate. The CA also generates Certificate Revocation Lists (CRLs). 146 These CA and EE certificates are referred to as "Resource 147 Certificates", and are profiled in [RFC6487]. The [RFC6480] 148 envisioned using Resource Certificates to enable verification of 149 Manifests [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482]. 150 ROAs and Manifests include the Resource Certificates used to verify 151 them. 153 +---------+ +------+ 154 | CA Cert |---| IANA | 155 +---------+ +------+ 156 \ 157 +---------+ +-----+ 158 | CA Cert |---| RIR | 159 +---------+ +-----+ 160 \ 161 +---------+ +-----+ 162 | CA Cert |---| ISP | 163 +---------+ +-----+ 164 / | | | 165 +-----+ / | | | +-----+ 166 | CRL |--+ | | +---| ROA | 167 +-----+ | | +-----+ 168 | | +----------+ 169 +----+ | +---| Manifest | 170 +-| EE |---+ +----------+ 171 | +----+ 172 +-----+ 173 Figure 1 175 This document defines another type of Resource Certificate, which is 176 referred to as a "BGPsec Router Certificate". The purpose of this 177 certificate is explained in Section 1 and falls within the scope of 178 appropriate uses defined within [RFC6484]. The issuance of BGPsec 179 Router Certificates has minimal impact on RPKI CAs because the RPKI 180 CA certificate and CRL profile remain unchanged (i.e., they are as 181 specified in [RFC6487]). Further, the algorithms used to generate 182 RPKI CA certificates that issue the BGPsec Router Certificates and 183 the CRLs necessary to check the validity of the BGPsec Router 184 Certificates remain unchanged (i.e., they are as specified in 185 [ID.sidr-rfc6485bis]). The only impact is that RPKI CAs will need to 186 be able to process a profiled certificate request (see Section 5) 187 signed with algorithms found in [ID.sidr-bgpsec-algs]. The use of 188 BGPsec Router Certificates in no way affects RPKI RPs that process 189 Manifests and ROAs because the public key found in the BGPsec Router 190 Certificate is used only to verify the signature on the BGPsec 191 certificate request (only CAs process these) and the signature on a 192 BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers 193 process these). 195 This document enumerates only the differences between this profile 196 and the profile in [RFC6487]. Note that BGPsec Router Certificates 197 are EE certificates and as such there is no impact on process 198 described in [RFC6916]. 200 3. Updates to [RFC6487] 202 3.1 BGPsec Router Certificate Fields 204 A BGPsec Router Certificate is a valid X.509 public key certificate, 205 consistent with the PKIX profile [RFC5280], containing the fields 206 listed in this section. This profile is also based on [RFC6487] and 207 only the differences between this profile and the profile in 208 [RFC6487] are specified below. 210 3.1.1.1. Subject 212 This field identifies the router to which the certificate has been 213 issued. Consistent with [RFC6487], only two attributes are allowed 214 in the Subject field: common name and serial number. Moreover, the 215 only common name encoding options that are supported are 216 printableString and UTF8String. For BGPsec Router Certificates, it 217 is RECOMMENDED that the common name attribute contain the literal 218 string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded 219 as eight hexadecimal digits and that the serial number attribute 220 contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) 221 encoded as eight hexadecimal digits. If there is more than one AS 222 number, the choice of which to include in the common name is at the 223 discretion of the Issuer. If the same certificate is issued to more 224 than one router (hence the private key is shared among these 225 routers), the choice of the router ID used in this name is at the 226 discretion of the Issuer. Note that router IDs are not guaranteed to 227 be unique across the Internet, and thus the Subject name in a BGPsec 228 Router Certificate issued using this convention also is not 229 guaranteed to be unique across different issuers. However, each 230 certificate issued by an individual CA MUST contain a Subject name 231 that is unique within that context. 233 3.1.2. Subject Public Key Info 235 Refer to section 3.1 of [ID.sidr-bgpsec-algs]. 237 3.1.3. BGPsec Router Certificate Version 3 Extension Fields 239 3.1.3.1. Basic Constraints 241 BGPsec speakers are EEs; therefore, the Basic Constraints extension 242 must not be present, as per [RFC6487]. 244 3.1.3.2. Extended Key Usage 246 BGPsec Router Certificates MUST include the Extended Key Usage (EKU) 247 extension. As specified in [RFC6487] this extension MUST be marked 248 as non-critical. This document defines one EKU for BGPsec Router 249 Certificates: 251 id-kp OBJECT IDENTIFIER ::= 252 { iso(1) identified-organization(3) dod(6) internet(1) 253 security(5) mechanisms(5) pkix(7) kp(3) } 255 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 257 A BGPsec router MUST require the extended key usage extension to be 258 present in a BGPsec Router Certificate it receives. If multiple 259 KeyPurposeId values are included, the BGPsec routers need not 260 recognize all of them, as long as the required KeyPurposeId value is 261 present. BGPsec routers MUST reject certificates that do not contain 262 the BGPsec Router EKU even if they include the anyExtendedKeyUsage 263 OID defined in [RFC5280]. 265 3.1.3.3. Subject Information Access 267 This extension is not used in BGPsec Router Certificates. It MUST be 268 omitted. 270 3.1.3.4. IP Resources 272 This extension is not used in BGPsec Router Certificates. It MUST be 273 omitted. 275 3.1.3.5. AS Resources 277 Each BGPsec Router Certificate MUST include the AS Resource 278 Identifier Delegation extension, as specified in section 4.8.11 of 279 [RFC6487]. The AS Resource Identifier Delegation extension MUST 280 include one or more AS numbers, and the "inherit" element MUST NOT be 281 specified. 283 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 ExtendedKeyUsage extension request MUST be included and the CA 289 MUST honor the request; 291 o The SubjectPublicKeyInfo and PublicKey fields are specified in 292 [ID.sidr-bgpsec-algs]; and, 294 o The request is signed with the algorithms specified in [ID.sidr- 295 bgpsec-algs]. 297 3.3. BGPsec Router Certificate Validation 299 The validation procedure used for BGPsec Router Certificates is 300 identical to the validation procedure described in Section 7 of 301 [RFC6487], but using the constraints applied come from this 302 specification. For example, in step 3: "the certificate contains all 303 the field that must be present" - refers to the fields that are 304 required by this specification. 306 The differences are as follows: 308 o BGPsec Router Certificates MUST include the BGPsec EKU defined in 309 Section 3.1.3.1. 311 o BGPsec Router Certificates MUST NOT include the SIA extension. 313 o BGPsec Router Certificates MUST NOT include the IP Resource 314 extension. 316 o BGPsec Router Certificates MUST include the AS Resource Identifier 317 Delegation extension. 319 o BGPsec Router Certificate MUST include the "Subject Public Key 320 Info" described in [ID.sidr-bgpsec-algs] as it updates [ID.sidr- 321 rfc6485bis]. 323 NOTE: The cryptographic algorithms used by BGPsec routers are found 324 in [ID.sidr-bgpsec-algs]. Currently, the algorithms specified in 325 [ID.sidr-bgpsec-algs] and [ID.sidr-rfc6485bis] are different. BGPsec 326 RPs will need to support algorithms that are used to validate BGPsec 327 signatures as well as the algorithms that are needed to validate 328 signatures on BGPsec certificates, RPKI CA certificates, and RPKI 329 CRLs. 331 4. Design Notes 333 The BGPsec Router Certificate profile is based on the Resource 334 Certificate profile as specified in [ID.sidr-rfc6485bis]. As a 335 result, many of the design choices herein are a reflection of the 336 design choices that were taken in that prior work. The reader is 337 referred to [RFC6484] for a fuller discussion of those choices. 339 5. Security Considerations 341 The Security Considerations of [RFC6487] apply. 343 A BGPsec Router Certificate will fail RPKI validation, as defined in 344 [RFC6487], because the algorithm suite is different. Consequently, a 345 RP needs to identify the EKU to determine the appropriate Validation 346 constraint. 348 A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to 349 encompass routers. It is a building block BGPsec and is used to 350 validate signatures on BGPsec Signature-Segment origination of 351 Signed-Path segments [ID.sidr-bgpsec-protocol]. Thus its essential 352 security function is the secure binding of one or more AS numbers to 353 a public key, consistent with the RPKI allocation/assignment 354 hierarchy. 356 Hash functions [ID.sidr-bgpsec-algs] are used when generating the two 357 key identifiers extension included in BGPsec certificates. However 358 as noted in [RFC6818], collision resistance is not a required 359 property of one-way hash functions when used to generate key 360 identifiers. Regardless, hash collisions are possible and if 361 detected an operator should be alerted. 363 6. IANA Considerations 365 This document makes use of two object identifiers in the SMI Registry 366 for PKIX. One is for the ASN.1 module in Appendix A and it comes 367 from the SMI Security for PKIX Module Identifier IANA registry (id- 368 mod-bgpsec-eku). The other is for the BGPsec router EKU defined in 369 Section 3.1.3.2 and Appendix A and it comes from the SMI Security for 370 PKIX Extended Key Purpose IANA registry. These OIDs were assigned 371 before management of the PKIX Arc was handed to IANA. No IANA 372 allocations are request of IANA, but please update the references in 373 those registries when this document is published by the RFC editor. 375 7. Acknowledgements 377 We would like to thank Geoff Huston, George Michaelson, and Robert 378 Loomans for their work on [RFC6487], which this work is based on. In 379 addition, the efforts of Steve Kent and Matt Lepinski were 380 instrumental in preparing this work. Additionally, we'd like to 381 thank Roque Gagliano, Sandra Murphy, Geoff Huston, Richard Hansen, 382 David Mandelberg, and Sam Weiller for their reviews and comments. 384 8. References 386 8.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 392 Addresses and AS Identifiers", RFC 3779, June 2004. 394 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 395 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 397 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 398 Housley, R., and W. Polk, "Internet X.509 Public Key 399 Infrastructure Certificate and Certificate Revocation List 400 (CRL) Profile", RFC 5280, May 2008. 402 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 403 X.509 PKIX Resource Certificates", RFC 6487, February 2012. 405 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 406 Infrastructure Certificate and Certificate Revocation List 407 (CRL) Profile", RFC 6818, January 2013. 409 [ID.sidr-rfc6485bis] G. Huston and G. Michaelson, "The Profile for 410 Algorithms and Key Sizes for use in the Resource Public Key 411 Infrastructure", draft-ietf-sidr-rfc6485bis, work-in- 412 progress. 414 [ID.sidr-bgpsec-algs] S. Turner, "BGP Algorithms, Key Formats, & 415 Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in- 416 progress. 418 8.2. Informative References 420 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 421 RFC 4272, January 2006. 423 [RFC5123] White, R. and B. Akyol, "Considerations in Validating the 424 Path in BGP", RFC 5123, February 2008. 426 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 427 with BGP-4", RFC 5492, February 2009. 429 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 430 Secure Internet Routing", RFC 6480, February 2012. 432 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 433 Origin Authorizations (ROAs)", RFC 6482, February 2012. 435 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 436 Policy (CP) for the Resource Public Key Infrastructure 437 (RPKI)", BCP 173, RFC 6484, February 2012. 439 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 440 "Manifests for the Resource Public Key Infrastructure 441 (RPKI)", RFC 6486, February 2012. 443 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 444 Procedure for the Resource Public Key Infrastructure 445 (RPKI)", BCP 182, RFC 6916, April 2013. 447 [ID.sidr-bgpsec-protocol] Lepinksi, M., "BGPsec Protocol 448 Specification", draft-ietf-sidr-bgpsec-protocol, work-in- 449 progress. 451 Appendix A. ASN.1 Module 453 BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) 454 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) } 456 DEFINITIONS EXPLICIT TAGS ::= 458 BEGIN 460 -- EXPORTS ALL -- 462 -- IMPORTS NOTHING -- 464 -- OID Arc -- 466 id-kp OBJECT IDENTIFIER ::= { 467 iso(1) identified-organization(3) dod(6) internet(1) 468 security(5) mechanisms(5) kp(3) } 470 -- BGPsec Router Extended Key Usage -- 472 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 474 END 476 Appendix B. Change Log 478 Please delete this section prior to publication. 480 B.0 Changes from sidr-bgpsec-pki-profiles-12 to sidr-bgpsec-pki- 481 profiles-13 483 Minor modifications to address WGLC comments. 485 B.1 Changes from sidr-bgpsec-pki-profiles-11 to sidr-bgpsec-pki- 486 profiles-12 488 Added security consideration to address SKI collisions. Also updated 489 the IANA considerations section. 491 B.2 Changes from sidr-bgpsec-pki-profiles-10 to sidr-bgpsec-pki- 492 profiles-11 494 Removed text in s3.1.3. Consistently used BGPsec to refer to BGP 495 Security. Fixed typos. Refer to RFC6485bis instead of RFC6485. 496 Included OIDs. 498 B.3. Changes from sidr-bgpsec-pki-profiles-09 to sidr-bgpsec-pki- 499 profiles-10 501 Updated dates. 503 B.4. Changes from sidr-bgpsec-pki-profiles-08 to sidr-bgpsec-pki- 504 profiles-09 506 Editorial fixes for the sake of brevity. 508 B.5. Changes from sidr-bgpsec-pki-profiles-07 to sidr-bgpsec-pki- 509 profiles-08 511 Fixed section numbering. 513 B.6. Changes from sidr-bgpsec-pki-profiles-06 to sidr-bgpsec-pki- 514 profiles-07 516 Added text to multiple AS numbers in a single certificate. Updated 517 reference to RFC 6916. 519 B.7. Changes from sidr-bgpsec-pki-profiles-05 to sidr-bgpsec-pki- 520 profiles-06 522 Keep alive version. 524 B.8. Changes from sidr-bgpsec-pki-profiles-04 to sidr-bgpsec-pki- 525 profiles-05 527 Keep alive version. 529 B.9. Changes from sidr-bgpsec-pki-profiles-03 to sidr-bgpsec-pki- 530 profiles-04 532 In s2.1, removed the phrase "another BGPSEC Router Certificate (only 533 BGPSEC routers process these)" because the BGPSEC certificates are 534 only ever EE certificates and they're never used to verify another 535 certificate only the PDUs that are signed. 537 Added new s3.1.3.1 to explicitly state that EE certificates are only 538 ever EE certs. 540 B.10. Changes from sidr-bgpsec-pki-profiles-02 to sidr-bgpsec-pki- 541 profiles-03 543 Updated s3.3 to clarify restrictions on path validation procedures 544 are in this specification (1st para was reworded). 546 Updated s3.3 to point to s3.1.3.1 for BGPSEC EKU (thanks Tom). 548 B.11. Changes from sidr-bgpsec-pki-profiles-01 to sidr-bgpsec-pki- 549 profiles-02 551 Updated references. 553 B.12. Changes from sidr-bgpsec-pki-profiles-00 to sidr-bgpsec-pki- 554 profiles-01 556 Added an ASN.1 Module and corrected the id-kp OID in s3.1.3.1. 558 B.13. Changes from turner-bgpsec-pki-profiles-02 to sidr-bgpsec-pki- 559 profiles-00 561 Added this change log. 563 Amplified that a BGPSEC RP will need to support both the algorithms 564 in [ID.sidr-bgpsec-algs] for BGPSEC and the algorithms in [ID.sidr- 565 rpki-algs] for certificates and CRLs. 567 Changed the name of AS Resource extension to AS Resource Identifier 568 Delegation to match what's in RFC 3779. 570 B.14. Changes from turner-bgpsec-pki-profiles -01 to -02 571 Added text in Section 2 to indicate that there's no impact on the 572 procedures defined in [RFC6916]. 574 Added a security consideration to let implementers know the BGPSEC 575 certificates will not pass RPKI validation [RFC6487] and that keying 576 off the EKU will help tremendously. 578 B.15. Changes from turner-bgpsec-pki-profiles -00 to -01 580 Corrected Section 2 to indicate that CA certificates are also RPKI 581 certificates. 583 Removed sections and text that was already in [RFC6487]. This will 584 make it easier for reviewers to figure out what is different. 586 Modified Section 6 to use 2119-language. 588 Removed requirement from Section 6 to check that the AS # in the 589 certificate is the last number in the AS path information of each BGP 590 UPDATE message. Moved to [ID.sidr-bgpsec-protocol]. 592 Authors' Addresses 594 Mark Reynolds 595 Island Peak Software 596 328 Virginia Road 597 Concord, MA 01742 599 Email: mcr@islandpeaksoftware.com 601 Sean Turner 602 IECA, Inc. 603 3057 Nutley Street, Suite 106 604 Fairfax, VA 22031 605 USA 607 EMail: turners@ieca.com 609 Stephen Kent 610 Raytheon BBN Technologies 611 10 Moulton St. 612 Cambridge, MA 02138 614 Email: kent@bbn.com