idnits 2.17.1 draft-ietf-sidr-bgpsec-pki-profiles-12.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 (October 14, 2015) is 3110 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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: BCP IECA 6 Expires: April 16, 2016 S. Kent 7 BBN 8 October 14, 2015 10 A Profile for BGPsec Router Certificates, 11 Certificate Revocation Lists, and Certification Requests 12 draft-ietf-sidr-bgpsec-pki-profiles-12 14 Abstract 16 This document defines a standard profile for X.509 certificates for 17 the purposes of supporting validation of Autonomous System (AS) paths 18 in the Border Gateway Protocol (BGP), as part of an extension to that 19 protocol known as BGPsec. BGP is a critical component for the proper 20 operation of the Internet as a whole. The BGPsec protocol is under 21 development as a component to address the requirement to provide 22 security for the BGP protocol. The goal of BGPsec is to design a 23 protocol for 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 under Resource Public Key Infrastructure 26 (RPKI) Certification Authority (CA) certificates, containing the AS 27 Identifier Delegation extension, to routers within the Autonomous 28 System (AS) or ASes. The certificate asserts that the router(s) 29 holding the private key are authorized to send out secure route 30 advertisements on behalf of the specified AS(es). This document also 31 profiles the Certificate Revocation List (CRL), profiles the format 32 of certification requests, and specifies Relying Party certificate 33 path validation procedures. The document extends the RPKI; 34 therefore, this documents updates the RPKI Resource Certificates 35 Profile (RFC 6487). 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 Copyright Notice 54 Copyright (c) 2015 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Describing Resources in Certificates . . . . . . . . . . . . . 3 72 3. Updates to [RFC6487] . . . . . . . . . . . . . . . . . . . . . 5 73 3.1 BGPsec Router Certificate Fields . . . . . . . . . . . . . 5 74 3.1.1.1. Subject . . . . . . . . . . . . . . . . . . . . . 5 75 3.1.2. Subject Public Key Info . . . . . . . . . . . . . . . 5 76 3.1.3. BGPsec Router Certificate Version 3 Extension Fields . 6 77 3.1.3.1. Basic Constraints . . . . . . . . . . . . . . . . 6 78 3.1.3.2. Extended Key Usage . . . . . . . . . . . . . . . . 6 79 3.1.3.3. Subject Information Access . . . . . . . . . . . . 6 80 3.1.3.4. IP Resources . . . . . . . . . . . . . . . . . . . 6 81 3.1.3.5. AS Resources . . . . . . . . . . . . . . . . . . . 6 82 3.2. BGPsec Router Certificate Request Profile . . . . . . . . 7 83 3.3. BGPsec Router Certificate Validation . . . . . . . . . . . 7 84 4. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 91 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 92 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 This document defines a profile for X.509 end-entity (EE) 98 certificates [RFC5280] for use in the context of certification of 99 Autonomous System (AS) paths in the Border Gateway Protocol Security 100 (BGPsec) protocol. Such certificates are termed "BGPsec Router 101 Certificates". The holder of the private key associated with a 102 BGPsec Router Certificate is authorized to send secure route 103 advertisements (BGPsec UPDATEs) on behalf of the AS(es) named in the 104 certificate. That is, a router holding the private key may send to 105 its BGP peers, route advertisements that contain one or more of the 106 specified AS number as the last item in the AS PATH attribute. A key 107 property that BGPsec will provide is that every AS along the AS PATH 108 can verify that the other ASes along the path have authorized the 109 advertisement of the given route (to the next AS along the AS PATH). 111 This document is a profile of [RFC6487], which is a profile of 112 [RFC5280], and it updates [RFC6487]. It establishes requirements 113 imposed on a Resource Certificate that is used as a BGPsec Router 114 Certificate, i.e., it defines constraints for certificate fields and 115 extensions for the certificate to be valid in this context. This 116 document also profiles the Certificate Revocation List (CRL) and 117 certification requests. Finally, this document specifies the Relying 118 Party (RP) certificate path validation procedures. 120 1.1. Terminology 122 It is assumed that the reader is familiar with the terms and concepts 123 described in "A Profile for X.509 PKIX Resource Certificates" 124 [RFC6487], "BGPsec Protocol Specification" [ID.sidr-bgpsec-protocol], 125 "A Border Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security 126 Vulnerabilities Analysis" [RFC4272], "Considerations in Validating 127 the Path in BGP" [RFC5123], and "Capability Advertisement with BGP-4" 128 [RFC5492]. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 [RFC2119]. 135 2. Describing Resources in Certificates 137 Figure 1 depicts some of the entities in the RPKI and some of the 138 products generated by RPKI entities. IANA issues a Certification 139 Authority (CA) to a Regional Internet Registries (RIR). The RIR, in 140 turn, issues a CA certificate to an Internet Service Providers (ISP). 141 The ISP in turn issues End-Entity (EE) Certificates to itself as well 142 as CRLs. These certificates are referred to as "Resource 143 Certificates", and are profiled in [RFC6487]. The [RFC6480] 144 envisioned using Resource Certificates to generate Manifests 145 [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482]. ROAs and 146 Manifests also include the Resource Certificates used to sign them. 148 +---------+ +------+ 149 | CA Cert |---| IANA | 150 +---------+ +------+ 151 \ 152 +---------+ +-----+ 153 | CA Cert |---| RIR | 154 +---------+ +-----+ 155 \ 156 +---------+ +-----+ 157 | CA Cert |---| ISP | 158 +---------+ +-----+ 159 / | | | 160 +-----+ / | | | +-----+ 161 | CRL |--+ | | +---| ROA | 162 +-----+ | | +-----+ 163 | | +----------+ 164 +----+ | +---| Manifest | 165 +-| EE |---+ +----------+ 166 | +----+ 167 +-----+ 168 Figure 1 170 This document defines another type of Resource Certificate, which is 171 referred to as a "BGPsec Router Certificate". The purpose of this 172 certificate is explained in Section 1 and falls within the scope of 173 appropriate uses defined within [RFC6484]. The issuance of BGPsec 174 Router Certificates has minimal impact on RPKI CAs because the RPKI 175 CA certificate and CRL profile remain unchanged (i.e., they are as 176 specified in [RFC6487]). Further, the algorithms used to generate 177 RPKI CA certificates that issue the BGPsec Router Certificates and 178 the CRLs necessary to check the validity of the BGPsec Router 179 Certificates remain unchanged (i.e., they are as specified in 180 [ID.sidr-rfc6485bis]). The only impact is that the RPKI CAs will 181 need to be able to process a profiled certificate request (see 182 Section 5) signed with algorithms found in [ID.sidr-bgpsec-algs]. 183 The use of BGPsec Router Certificates in no way affects RPKI RPs that 184 process Manifests and ROAs because the public key found in the BGPsec 185 Router Certificate is only ever used to verify the signature on the 186 BGPsec certificate request (only CAs process these) and the signature 187 on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec 188 routers process these). 190 Only the differences between this profile and the profile in 191 [RFC6487] are listed. Note that BGPsec Router Certificates are EE 192 certificates and as such there is no impact on process described in 193 [RFC6916]. 195 3. Updates to [RFC6487] 197 3.1 BGPsec Router Certificate Fields 199 A BGPsec Router Certificate is a valid X.509 public key certificate, 200 consistent with the PKIX profile [RFC5280], containing the fields 201 listed in this section. This profile is also based on [RFC6487] and 202 only the differences between this profile and the profile in 203 [RFC6487] are listed. 205 3.1.1.1. Subject 207 This field identifies the router to which the certificate has been 208 issued. Consistent with [RFC6487], only two attributes are allowed 209 in the Subject field: common name and serial number. Moreover, the 210 only common name encoding options that are supported are 211 printableString and UTF8String. For BGPsec Router Certificates, it 212 is RECOMMENDED that the common name attribute contain the literal 213 string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded 214 as eight hexadecimal digits and that the serial number attribute 215 contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) 216 encoded as eight hexadecimal digits. If there is more than one AS 217 number, the choice of which to include in the common name is at the 218 discretion of the Issuer. If the same certificate is issued to more 219 than one router (hence the private key is shared among these 220 routers), the choice of the router ID used in this name is at the 221 discretion of the Issuer. Note that router IDs are not guaranteed to 222 be unique across the Internet, and thus the Subject name in a BGPsec 223 Router Certificate issued using this convention also is not 224 guaranteed to be unique across different issuers. However, each 225 certificate issued by an individual CA MUST contain a Subject name 226 that is unique within that context. 228 3.1.2. Subject Public Key Info 230 Refer to section 3.1 of [ID.sidr-bgpsec-algs]. 232 3.1.3. BGPsec Router Certificate Version 3 Extension Fields 234 3.1.3.1. Basic Constraints 236 BGPsec speakers are EEs; therefore, the Basic Constraints extension 237 must not be present, as per [RFC6487]. 239 3.1.3.2. Extended Key Usage 241 BGPsec Router Certificates MUST include the Extended Key Usage (EKU) 242 extension. As specified in [RFC6487] this extension MUST be marked 243 as non-critical. This document defines one EKU for BGPsec Router 244 Certificates: 246 id-kp OBJECT IDENTIFIER ::= 247 { iso(1) identified-organization(3) dod(6) internet(1) 248 security(5) mechanisms(5) pkix(7) kp(3) } 250 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 252 Relying Parties MUST require the extended key usage extension to be 253 present in a BGPsec Router Certificate. If multiple KeyPurposeId 254 values are included, the relying parties need not recognize all of 255 them, as long as the required KeyPurposeId value is present. BGPsec 256 RPs MUST reject certificates that do not contain the BGPsec Router 257 EKU even if they include the anyExtendedKeyUsage OID defined in 258 [RFC5280]. 260 3.1.3.3. Subject Information Access 262 This extension is not used in BGPsec Router Certificates. It MUST be 263 omitted. 265 3.1.3.4. IP Resources 267 This extension is not used in BGPsec Router Certificates. It MUST be 268 omitted. 270 3.1.3.5. AS Resources 272 Each BGPsec Router Certificate MUST include the AS Resource 273 Identifier Delegation extension, as specified in section 4.8.11 of 274 [RFC6487]. The AS Resource Identifier Delegation extension MUST 275 include one or more AS numbers, and the "inherit" element MUST NOT be 276 specified. 278 3.2. BGPsec Router Certificate Request Profile 280 Refer to section 6 of [RFC6487]. The only differences between this 281 profile and the profile in [RFC6487] are: 283 o The ExtendedKeyUsage extension request MUST be included and the CA 284 MUST honor the request; 286 o The SubjectPublicKeyInfo and PublicKey fields are specified in 287 [ID.sidr-bgpsec-algs]; and, 289 o The request is signed with the algorithms specified in [ID.sidr- 290 bgpsec-algs]. 292 3.3. BGPsec Router Certificate Validation 294 The validation procedure used for BGPsec Router Certificates is 295 identical to the validation procedure described in Section 7 of 296 [RFC6487]. The exception is that the constraints applied come from 297 this specification (e.g., in step 3: the certificate contains all the 298 field that must be present - refers to the fields that are required 299 by this specification). 301 The differences are as follows: 303 o BGPsec Router Certificates MUST include the BGPsec EKU defined in 304 Section 3.1.3.1. 306 o BGPsec Router Certificates MUST NOT include the SIA extension. 308 o BGPsec Router Certificates MUST NOT include the IP Resource 309 extension. 311 o BGPsec Router Certificates MUST include the AS Resource Identifier 312 Delegation extension. 314 o BGPsec Router Certificate MUST include the "Subject Public Key 315 Info" described in [ID.sidr-bgpsec-algs] as it updates [ID.sidr- 316 rfc6485bis]. 318 NOTE: The cryptographic algorithms used by BGPsec routers are found 319 in [ID.sidr-bgpsec-algs]. Currently, the algorithms specified in 320 [ID.sidr-bgpsec-algs] and [ID.sidr-rfc6485bis] are different. BGPsec 321 RPs will need to support algorithms that are needed to validate 322 BGPsec signatures as well as the algorithms that are needed to 323 validate signatures on BGPsec certificates, RPKI CA certificates, and 324 RPKI CRLs. 326 4. Design Notes 328 The BGPsec Router Certificate profile is based on the Resource 329 Certificate profile as specified in [ID.sidr-rfc6485bis]. As a 330 result, many of the design choices herein are a reflection of the 331 design choices that were taken in that prior work. The reader is 332 referred to [RFC6484] for a fuller discussion of those choices. 334 5. Security Considerations 336 The Security Considerations of [RFC6487] apply. 338 A BGPsec certificate will fail RPKI validation, as defined in 339 [RFC6487], because the algorithm suite is different. Consequently, a 340 RP needs to identify the EKU before applying the correspondent 341 validation. 343 A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to 344 encompass routers. It is a building block of the larger BGPsec 345 security protocol used to validate signatures on BGPsec Signature- 346 Segment origination of Signed-Path segments [ID.sidr-bgpsec- 347 protocol]. Thus its essential security function is the secure 348 binding of one or more AS numbers to a public key, consistent with 349 the RPKI allocation/assignment hierarchy. 351 Hash functions [ID.sidr-bgpsec-algs] are used when generating the two 352 key identifiers extension included in BGPsec certificates. However 353 as noted in [RFC6818], collision resistance is not a required 354 property of one-way hash functions when used to generate key 355 identifiers. Regardless, hash collisions are possible and if 356 detected the operator should be alerted. 358 6. IANA Considerations 360 This document makes use of two object identifiers in the SMI Registry 361 for PKIX. One is for the ASN.1 module in Appendix A and it comes 362 from the SMI Security for PKIX Module Identifier IANA registry (id- 363 mod-bgpsec-eku). The other is for the BGPsec router EKU defined in 364 Section 3.1.3.2 and Appendix A and it comes from the SMI Security for 365 PKIX Extended Key Purpose IANA registry. These OIDs were assigned 366 before management of the PKIX Arc was handed to IANA. No IANA 367 allocations are request of IANA, but please update the references in 368 those registries when this document is published by the RFC editor. 370 7. Acknowledgements 372 We would like to thank Geoff Huston, George Michaelson, and Robert 373 Loomans for their work on [RFC6487], which this work is based on. In 374 addition, the efforts of Steve Kent and Matt Lepinski were 375 instrumental in preparing this work. Additionally, we'd like to 376 thank Roque Gagliano, Sandra Murphy, Geoff Huston, Richard Hansen, 377 and David Mandelberg for their reviews and comments. 379 8. References 381 8.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 387 Addresses and AS Identifiers", RFC 3779, June 2004. 389 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 390 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 392 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 393 Housley, R., and W. Polk, "Internet X.509 Public Key 394 Infrastructure Certificate and Certificate Revocation List 395 (CRL) Profile", RFC 5280, May 2008. 397 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 398 X.509 PKIX Resource Certificates", RFC 6487, February 2012. 400 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 401 Infrastructure Certificate and Certificate Revocation List 402 (CRL) Profile", RFC 6818, January 2013. 404 [ID.sidr-rfc6485bis] G. Huston, "The Profile for Algorithms and Key 405 Sizes for use in the Resource Public Key Infrastructure", 406 draft-ietf-sidr-rfc6485bis, work-in-progress. 408 [ID.sidr-bgpsec-algs] S. Turner, "BGP Algorithms, Key Formats, & 409 Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in- 410 progress. 412 8.2. Informative References 414 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 415 RFC 4272, January 2006. 417 [RFC5123] White, R. and B. Akyol, "Considerations in Validating the 418 Path in BGP", RFC 5123, February 2008. 420 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 421 with BGP-4", RFC 5492, February 2009. 423 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 424 Secure Internet Routing", RFC 6480, February 2012. 426 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 427 Origin Authorizations (ROAs)", RFC 6482, February 2012. 429 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 430 Policy (CP) for the Resource Public Key Infrastructure 431 (RPKI)", BCP 173, RFC 6484, February 2012. 433 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 434 "Manifests for the Resource Public Key Infrastructure 435 (RPKI)", RFC 6486, February 2012. 437 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 438 Procedure for the Resource Public Key Infrastructure 439 (RPKI)", BCP 182, RFC 6916, April 2013. 441 [ID.sidr-bgpsec-protocol] Lepinksi, M., "BGPsec Protocol 442 Specification", draft-ietf-sidr-bgpsec-protocol, work-in- 443 progress. 445 Appendix A. ASN.1 Module 447 BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) 448 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) } 450 DEFINITIONS EXPLICIT TAGS ::= 452 BEGIN 454 -- EXPORTS ALL -- 456 -- IMPORTS NOTHING -- 458 -- OID Arc -- 460 id-kp OBJECT IDENTIFIER ::= { 461 iso(1) identified-organization(3) dod(6) internet(1) 462 security(5) mechanisms(5) kp(3) } 464 -- BGPsec Router Extended Key Usage -- 466 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 468 END 470 Appendix B. Change Log 472 Please delete this section prior to publication. 474 B.0 Changes from sidr-bgpsec-pki-profiles-11 to sidr-bgpsec-pki- 475 profiles-12 477 Added security consideration to address SKI collisions. Also updated 478 the IANA considerations section. 480 B.1 Changes from sidr-bgpsec-pki-profiles-10 to sidr-bgpsec-pki- 481 profiles-11 483 Removed text in s3.1.3. Consistently used BGPsec to refer to BGP 484 Security. Fixed typos. Refer to RFC6485bis instead of RFC6485. 485 Included OIDs. 487 B.2. Changes from sidr-bgpsec-pki-profiles-09 to sidr-bgpsec-pki- 488 profiles-10 490 Updated dates. 492 B.3. Changes from sidr-bgpsec-pki-profiles-08 to sidr-bgpsec-pki- 493 profiles-09 495 Editorial fixes for the sake of brevity. 497 B.4. Changes from sidr-bgpsec-pki-profiles-07 to sidr-bgpsec-pki- 498 profiles-08 500 Fixed section numbering. 502 B.5. Changes from sidr-bgpsec-pki-profiles-06 to sidr-bgpsec-pki- 503 profiles-07 505 Added text to multiple AS numbers in a single certificate. Updated 506 reference to RFC 6916. 508 B.6. Changes from sidr-bgpsec-pki-profiles-05 to sidr-bgpsec-pki- 509 profiles-06 511 Keep alive version. 513 B.7. Changes from sidr-bgpsec-pki-profiles-04 to sidr-bgpsec-pki- 514 profiles-05 516 Keep alive version. 518 B.8. Changes from sidr-bgpsec-pki-profiles-03 to sidr-bgpsec-pki- 519 profiles-04 521 In s2.1, removed the phrase "another BGPSEC Router Certificate (only 522 BGPSEC routers process these)" because the BGPSEC certificates are 523 only ever EE certificates and they're never used to verify another 524 certificate only the PDUs that are signed. 526 Added new s3.1.3.1 to explicitly state that EE certificates are only 527 ever EE certs. 529 B.9. Changes from sidr-bgpsec-pki-profiles-02 to sidr-bgpsec-pki- 530 profiles-03 532 Updated s3.3 to clarify restrictions on path validation procedures 533 are in this specification (1st para was reworded). 535 Updated s3.3 to point to s3.1.3.1 for BGPSEC EKU (thanks Tom). 537 B.10. Changes from sidr-bgpsec-pki-profiles-01 to sidr-bgpsec-pki- 538 profiles-02 540 Updated references. 542 B.11. Changes from sidr-bgpsec-pki-profiles-00 to sidr-bgpsec-pki- 543 profiles-01 545 Added an ASN.1 Module and corrected the id-kp OID in s3.1.3.1. 547 B.12. Changes from turner-bgpsec-pki-profiles-02 to sidr-bgpsec-pki- 548 profiles-00 550 Added this change log. 552 Amplified that a BGPSEC RP will need to support both the algorithms 553 in [ID.sidr-bgpsec-algs] for BGPSEC and the algorithms in [ID.sidr- 554 rpki-algs] for certificates and CRLs. 556 Changed the name of AS Resource extension to AS Resource Identifier 557 Delegation to match what's in RFC 3779. 559 B.13. Changes from turner-bgpsec-pki-profiles -01 to -02 561 Added text in Section 2 to indicate that there's no impact on the 562 procedures defined in [RFC6916]. 564 Added a security consideration to let implementers know the BGPSEC 565 certificates will not pass RPKI validation [RFC6487] and that keying 566 off the EKU will help tremendously. 568 B.14. Changes from turner-bgpsec-pki-profiles -00 to -01 570 Corrected Section 2 to indicate that CA certificates are also RPKI 571 certificates. 573 Removed sections and text that was already in [RFC6487]. This will 574 make it easier for reviewers to figure out what is different. 576 Modified Section 6 to use 2119-language. 578 Removed requirement from Section 6 to check that the AS # in the 579 certificate is the last number in the AS path information of each BGP 580 UPDATE message. Moved to [ID.sidr-bgpsec-protocol]. 582 Authors' Addresses 584 Mark Reynolds 585 Island Peak Software 586 328 Virginia Road 587 Concord, MA 01742 589 Email: mcr@islandpeaksoftware.com 591 Sean Turner 592 IECA, Inc. 593 3057 Nutley Street, Suite 106 594 Fairfax, VA 22031 595 USA 597 EMail: turners@ieca.com 599 Steve Kent 600 Raytheon BBN Technologies 601 10 Moulton St. 602 Cambridge, MA 02138 604 Email: kent@bbn.com