idnits 2.17.1 draft-ietf-sidr-rpki-validation-reconsidered-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2017) is 2490 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) -- Looks like a reference, but probably isn't: '0' on line 329 -- Looks like a reference, but probably isn't: '1' on line 330 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Standards Track APNIC 5 Expires: December 27, 2017 C. Martinez 6 LACNIC 7 T. Bruijnzeels 8 RIPE NCC 9 A. Newton 10 ARIN 11 D. Shaw 12 AFRINIC 13 June 25, 2017 15 RPKI Validation Reconsidered 16 draft-ietf-sidr-rpki-validation-reconsidered-08 18 Abstract 20 This document specifies an alternative to the certificate validation 21 procedure specified in RFC 6487 that reduces aspects of operational 22 fragility in the management of certificates in the RPKI, while 23 retaining essential security features. 25 The use of this updated procedure is signalled by form of a set of 26 alternative Object Identifiers (OIDs) indicating that the alternative 27 version of RFC 3779 X.509 Extensions for IP Addresses and AS 28 Identifiers, and certificate policy for the Resource Public Key 29 Infrastructure (RFC 6484) defined in this document should be used. 31 Furthermore this document provides an alternative to ROA (RFC 6482), 32 and BGPSec Router Certificate (BGPSec PKI Profiles - publication 33 requested) validation. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 27, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 69 2. Certificate Validation in the RPKI . . . . . . . . . . . . . 3 70 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 71 4. An Amended RPKI Certification Validation Process . . . . . . 5 72 4.1. Verified Resource Sets . . . . . . . . . . . . . . . . . 5 73 4.2. Differences with existing standards . . . . . . . . . . . 5 74 4.2.1. Certificate Policy (CP) for use with validation 75 reconsidered in the Resource PKI (RPKI) . . . . . . . 5 76 4.2.2. An alternative to RFC3779 X.509 Extensions for IP 77 Addresses and AS Identifiers . . . . . . . . . . . . 6 78 4.2.3. Addendum to RFC6268 . . . . . . . . . . . . . . . . . 11 79 4.2.4. An alternative to RFC6487 Profile for X.509 PKIX 80 Resource Certificates . . . . . . . . . . . . . . . . 13 81 4.2.5. An alternative ROA validation RFC6482 . . . . . . . . 16 82 4.2.6. An alternative to BGPSec Router Certificate 83 Validation . . . . . . . . . . . . . . . . . . . . . 17 84 4.3. An example . . . . . . . . . . . . . . . . . . . . . . . 17 85 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 19 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 91 9.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Requirements notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Certificate Validation in the RPKI 102 As currently defined in section 7.2 of [RFC6487], validation of PKIX 103 certificates that conform to the RPKI profile relies on the use of a 104 path validation process where each certificate in the validation path 105 is required to meet the certificate validation criteria. 107 These criteria require, in particular, that the Internet Number 108 Resources (INRs) of each certificate in the validation path are 109 "encompassed" by INRs on the issuing certificate. The first 110 certificate in the path is required to be a trust anchor, and its 111 resources are considered valid by definition. 113 For example, in the following sequence: 115 Certificate 1 (trust anchor): 116 Issuer TA, 117 Subject TA, 118 Resources 192.0.2.0/24, 198.51.100.0/24, 119 2001:db8::/32, AS64496-AS64500 121 Certificate 2: 122 Issuer TA, 123 Subject CA1, 124 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 126 Certificate 3: 127 Issuer CA1, 128 Subject CA2, 129 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 131 ROA 1: 132 Embedded Certificate 4 (EE certificate): 133 Issuer CA2, 134 Subject R1, 135 Resources 192.0.2.0/24 137 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 139 All certificates in this scenario are considered valid since the INRs 140 of each certificate are encompassed by those of the issuing 141 certificate. ROA1 is valid because the specified prefix is 142 encompassed by the embedded EE certificate, as required by [RFC6482]. 144 3. Operational Considerations 146 The allocations recorded in the RPKI change as a result of resource 147 transfers. For example, the CAs involved in transfer might choose to 148 modify CA certificates in an order that causes some of these 149 certificates to "over-claim" temporarily. A certificate is said to 150 "over-claim" if it includes INRs not contained in the INRs of the CA 151 that issued the certificate in question. 153 It may also happen that a child CA does not voluntarily request a 154 shrunk resource certificate when resources are being transferred or 155 reclaimed by the parent. Furthermore operational errors that may 156 occur during management of RPKI databases also may create CA 157 certificates that, temporarily, no longer encompass all of the INRs 158 of subordinate certificates. 160 Consider the following sequence: 162 Certificate 1 (trust anchor): 163 Issuer TA, 164 Subject TA, 165 Resources 192.0.2.0/24, 198.51.100.0/24, 166 2001:db8::/32, AS64496-AS64500 168 Certificate 2: 169 Issuer TA, 170 Subject CA1, 171 Resources 192.0.2.0/24, 2001:db8::/32 173 Certificate 3 (invalid): 174 Issuer CA1, 175 Subject CA2, 176 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 178 ROA 1 (invalid): 179 Embedded Certificate 4 (EE certificate, invalid): 180 Issuer CA2, 181 Subject R1, 182 Resources 192.0.2.0/24 184 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 186 Here Certificate 2 from the previous example was re-issued by TA to 187 CA1 and the prefix 198.51.100.0/24 was removed. However, CA1 failed 188 to re-issue a new Certificate 3 to CA2. As a result Certificate 3 is 189 now over-claiming and considered invalid; by recursion the embedded 190 Certificate 4 used for ROA1 is also invalid. And ROA1 is invalid 191 because the specified prefix contained in the ROA is no longer 192 encompassed by a valid embedded EE certificate, as required by 193 [RFC6482] 195 However, it should be noted that ROA1 does not make use of any of the 196 address resources that were removed from CA1's certificate, and thus 197 it would be desirable if ROA1 could still be viewed as valid. 198 Technically CA1 should re-issue a Certificate 3 to CA2 without 199 198.51.100.0/24, and then ROA1 would be considered valid according to 200 [RFC6482]. But as long as CA1 does not take this action, ROA1 201 remains invalid. It would be preferable if ROA1 could be considered 202 valid, since the assertion it makes was not affected by the reduced 203 scope of CA1's certificate. 205 4. An Amended RPKI Certification Validation Process 207 4.1. Verified Resource Sets 209 The problem described above can be considered as a low probability 210 problem today. However the potential impact on routing security 211 would be high if an over-claiming occurred near the apex of the RPKI 212 hierarchy, as this would invalidate the entirety of the sub-tree 213 located below this point. 215 The changes specified here to the validation procedure in [RFC6487] 216 do not change the probability of this problem, but they do limit the 217 impact to just the over-claimed resources. This revised validation 218 algorithm is intended to avoid causing CA certificates to be treated 219 as completely invalid as a result of over-claims. However, these 220 changes are designed to not degrade the security offered by the RPKI. 221 Specifically, ROAs and router certificates will be treated as valid 222 only if all of the resources contained in them are encompassed by all 223 superior certificates along a path to a trust anchor. 225 The way this is achieved conceptually is by maintaining a Verified 226 Resource Set (VRS) for each certificate that is separate from the 227 INRs found in the [RFC3779] resource extension in the certificate. 229 4.2. Differences with existing standards 231 4.2.1. Certificate Policy (CP) for use with validation reconsidered in 232 the Resource PKI (RPKI) 234 Note that section 1.2 of [RFC6484] defines the "Certificate Policy 235 (CP) for the Resource PKI (RPKI)" with the following OID: 237 id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1) 238 identified-organization(3) dod(6) internet(1) 239 security(5) mechanisms(5) pkix(7) cp(14) 2 } 241 This document requests an assignment of a new OID for an alternative 242 "Certificate Policy (CP) for use with validation reconsidered in the 243 Resource PKI (RPKI)" as follows: 245 id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1) 246 identified-organization(3) dod(6) internet(1) 247 security(5) mechanisms(5) pkix(7) cp(14) TBD1 } 249 This alternative Certificate Policy is the same as the Certificate 250 Policy described in [RFC6484], except that it indicates that the 251 validation rules described in Section 4.2.4.4 are to be used. 253 4.2.2. An alternative to RFC3779 X.509 Extensions for IP Addresses and 254 AS Identifiers 256 This document defines an alternative to [RFC3779]. All 257 specifications and procedures described in [RFC3779] apply, with the 258 following notable exceptions. 260 4.2.2.1. OID for id-pe-ipAddrBlocks-v2 262 This document request an OID for the extension id-pe-ipAddrBlocks-v2 263 (id-pe TBD2). 265 The following is an amended specification to be used as an 266 alternative to the specification in section 2.2.1 of [RFC3779]. 268 The OID for this extension is id-pe-ipAddrBlocks-v2. 270 id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD2 } 272 where [RFC5280] defines: 274 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 275 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 277 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 279 4.2.2.2. Syntax for id-pe-ipAddrBlocks-v2 280 id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD2 } 282 IPAddrBlocks ::= SEQUENCE OF IPAddressFamily 284 IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI -- 285 addressFamily OCTET STRING (SIZE (2..3)), 286 ipAddressChoice IPAddressChoice } 288 IPAddressChoice ::= CHOICE { 289 inherit NULL, -- inherit from issuer -- 290 addressesOrRanges SEQUENCE OF IPAddressOrRange } 292 IPAddressOrRange ::= CHOICE { 293 addressPrefix IPAddress, 294 addressRange IPAddressRange } 296 IPAddressRange ::= SEQUENCE { 297 min IPAddress, 298 max IPAddress } 300 IPAddress ::= BIT STRING 302 Note that the descriptions of objects referenced in the syntax above 303 are defined in sections 2.2.3.1 through 2.2.3.9 of [RFC3779]. 305 4.2.2.3. OID for id-pe-autonomousSysIds-v2 307 This document request an OID for the extension id-pe- 308 autonomousSysIds-v2 ( id-pe TBD3). 310 The following is an amended specification to be used as an 311 alternative to the specification in section 3.2.1 of [RFC3779]. 313 The OID for this extension is id-pe-autonomousSysIds-v2. 315 id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD3 } 317 where [RFC5280] defines: 319 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 320 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 322 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 324 4.2.2.4. Syntax for id-pe-autonomousSysIds-v2 326 id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD3 } 328 ASIdentifiers ::= SEQUENCE { 329 asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL, 330 rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL} 332 ASIdentifierChoice ::= CHOICE { 333 inherit NULL, -- inherit from issuer -- 334 asIdsOrRanges SEQUENCE OF ASIdOrRange } 336 ASIdOrRange ::= CHOICE { 337 id ASId, 338 range ASRange } 340 ASRange ::= SEQUENCE { 341 min ASId, 342 max ASId } 344 ASId ::= INTEGER 346 4.2.2.5. Amended IP Address Delegation Extension Certification Path 347 Validation 349 If the extension OID defined in Section 4.2.2.1 is used, then 350 Certificate path validation is performed as specified in 351 Section 4.2.4.4 rather than the procedure described in section 2.3 of 352 [RFC3779]. 354 4.2.2.6. Amended Autonomous System Identifier Delegation Extension 355 Certification Path Validation 357 If the extension OID defined in Section 4.2.2.3 is used, then 358 Certificate path validation is performed as specified in 359 Section 4.2.4.4 of rather than the procedure described in section 3.3 360 of [RFC3779]. 362 4.2.2.7. Amended ASN.1 module 364 This document requests an OID for id-mod-ip-addr-and-as-ident-v2, as 365 follows: 367 IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) 368 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 369 id-mod-ip-addr-and-as-ident-v2(TBD4) } 371 The following is an amended specification to be used as an 372 alternative to the specification in section appendix A of [RFC3779]. 374 This normative appendix describes the IP address and AS identifiers 375 extensions used by conforming PKI components in ASN.1 syntax. 377 IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) 378 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 379 id-mod-ip-addr-and-as-ident-v2(TBD4) } 381 DEFINITIONS EXPLICIT TAGS ::= 383 BEGIN 385 -- EXPORTS ALL -- 387 IMPORTS 389 -- PKIX specific OIDs and arcs -- 391 id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) 392 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 393 id-mod(0) id-pkix1-explicit(18) } 395 -- IP Address Block and AS Identifiers Syntax -- 397 IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) 398 identified-organization(3) dod(6) internet(1) security(5) 399 mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } 400 ; 402 -- Validation Reconsidered IP Address Delegation Extension OID -- 404 id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD2 } 406 -- Validation Reconsidered IP Address Delegation Extension Syntax -- 407 -- Syntax is imported from [RFC3779] -- 409 -- Validation Reconsidered Autonomous System Identifier -- 410 -- Delegation Extension OID -- 412 id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD3 } 414 -- Validation Reconsidered Autonomous System Identifier -- 415 -- Delegation Extension Syntax -- 417 -- Syntax is imported from [RFC3779] -- 419 END 421 4.2.3. Addendum to RFC6268 423 This document requests an OID for id-mod-ip-addr-and-as-ident-2v2 as 424 follows: 426 IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) 427 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 428 id-mod-ip-addr-and-as-ident-2v2(TBD5) } 430 [RFC6268] is an informational RFC that updates some auxiliary ASN.1 431 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 432 modules in Section 4.2.2.7 remain the normative version. 434 The following is an additional module confirming to the 2008 version 435 of ASN.1 to be used with the extensions defined in Section 4.2.2.1 436 and Section 4.2.2.3. 438 IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) 439 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 440 id-mod-ip-addr-and-as-ident-2v2(TBD5) } 442 DEFINITIONS EXPLICIT TAGS ::= 444 BEGIN 446 EXPORTS ALL; 447 IMPORTS 449 -- PKIX specific OIDs and arcs -- 451 id-pe 452 FROM PKIX1Explicit-2009 453 { iso(1) identified-organization(3) dod(6) internet(1) 454 security(5) mechanisms(5) pkix(7) id-mod(0) 455 id-mod-pkix1-explicit-02(51)} 457 EXTENSION 458 FROM PKIX-CommonTypes-2009 459 { iso(1) identified-organization(3) dod(6) internet(1) 460 security(5) mechanisms(5) pkix(7) id-mod(0) 461 id-mod-pkixCommon-02(57)} 463 -- IP Address Block and AS Identifiers Syntax -- 465 IPAddrBlocks, ASIdentifiers 466 FROM IPAddrAndASCertExtn-2010 467 { iso(1) identified-organization(3) dod(6) 468 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 469 id-mod-ip-addr-and-as-ident-2(72) } 470 ; 472 -- 473 -- Extensions contains the set of extensions defined in this 474 -- module 475 -- 476 -- These are intended to be placed in public key certificates 477 -- and thus should be added to the CertExtensions extension 478 -- set in PKIXImplicit-2009 defined for [RFC5280] 479 -- 481 Extensions EXTENSION ::= { 482 ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 483 } 485 -- Validation Reconsidered IP Address Delegation Extension OID -- 487 ext-pe-ipAddrBlocks-v2 EXTENSION ::= { 488 SYNTAX IPAddrBlocks 489 IDENTIFIED BY id-pe-ipAddrBlocks-v2 490 } 492 id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD2 } 494 -- Validation Reconsidered IP Address Delegation -- 495 -- Extension Syntax -- 497 -- Syntax is imported from [RFC6268] -- 499 -- Validation Reconsidered Autonomous System Identifier -- 500 -- Delegation Extension OID -- 502 ext-pe-autonomousSysIds-v2 EXTENSION ::= { 503 SYNTAX ASIdentifiers 504 IDENTIFIED BY id-pe-autonomousSysIds-v2 505 } 507 id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe TBD3 } 509 -- Validation Reconsidered Autonomous System Identifier -- 510 -- Delegation Extension Syntax -- 512 -- Syntax is imported from [RFC6268] -- 514 END 516 4.2.4. An alternative to RFC6487 Profile for X.509 PKIX Resource 517 Certificates 519 This document defines an alternative Profile for X.509 PKIX Resource 520 Certificates. This profile follows all definitions and procedures 521 described in [RFC6487] with the following notable exceptions. 523 4.2.4.1. Amended Certificate Policies 525 The following is an amended specification to be used in this profile, 526 in place of section 4.8.9 of [RFC6487]. 528 This extension MUST be present and MUST be marked critical. It MUST 529 include exactly one policy of type id-cp-ipAddr-asNumber-v2, as 530 specified in the updated RPKI CP in Section 4.2.1. 532 4.2.4.2. Amended IP Resources 534 The following is an amended specification to be used in this profile, 535 in place of section 4.8.10 of [RFC6487]. 537 Either the IP Resources extension, or the AS Resources extension, or 538 both, MUST be present in all RPKI certificates, and if present, MUST 539 be marked critical. 541 This extension contains the list of IP address resources as per 542 Section 4.2.2.1. The value may specify the "inherit" element for a 543 particular Address Family Identifier (AFI) value. In the context of 544 resource certificates describing public number resources for use in 545 the public Internet, the Subsequent AFI (SAFI) value MUST NOT be 546 used. 548 This extension MUST either specify a non-empty set of IP address 549 records, or use the "inherit" setting to indicate that the IP address 550 resource set of this certificate is inherited from that of the 551 certificate's issuer. 553 4.2.4.3. Amended AS Resources 555 The following is an amended specification to be used in this profile, 556 in place of section 4.8.11 of [RFC6487]. 558 Either the AS Resources extension, or the IP Resources extension, or 559 both, MUST be present in all RPKI certificates, and if present, MUST 560 be marked critical. 562 This extension contains the list of AS number resources as per 563 Section 4.2.2.3, or it may specify the "inherit" element. Routing 564 Domain Identifier (RDI) values are NOT supported in this profile and 565 MUST NOT be used. 567 This extension MUST either specify a non-empty set of AS number 568 records, or use the "inherit" setting to indicate that the AS number 569 resource set of this certificate is inherited from that of the 570 certificate's issuer. 572 4.2.4.4. Amended Resource Certificate Path Validation 574 The following is an amended specification for path validation to be 575 used in place of section 7.2 of [RFC6487] allowing for the validation 576 of both certificates following the profile defined in [RFC6487], as 577 well as certificates following the profile described above. 579 The following algorithm is employed to validate CA and EE resources 580 certificates. It is modelled on the path validation algorithm from 581 [RFC5280], but modified to make use of the IP Address Delegation and 582 AS Identifier Delegation Extensions from [RFC3779]. 584 There are two inputs to the validation algorithm: 586 1. a trust anchor 588 2. a certificate to be validated 590 The algorithm is initialized with two new variables for use in the 591 RPKI: Validated Resource Set-IP (VRS-IP) and Validated Resource Set- 592 AS (VRS-AS). These sets are used to track the set of INRs (IP 593 address space and AS Numbers) that are considered valid for each CA 594 certificate. The VRS-IP and VRS-AS sets are initially set to the IP 595 Address Delegation and AS Identifier Delegation values, respectively, 596 from the trust anchor used to perform validation. 598 This path validation algorithm verifies, among other things, that a 599 prospective certification path (a sequence of n certificates) 600 satisfies the following conditions: 602 a. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is 603 the issuer of certificate ('x' + 1); 605 b. certificate '1' is issued by a trust anchor; 607 c. certificate 'n' is the certificate to be validated; and 609 d. for all 'x' in {1, ..., n}, certificate 'x' is valid. 611 Certificate validation requires verifying that all of the following 612 conditions hold, in addition to the certification path validation 613 criteria specified in Section 6 of [RFC5280]. 615 1. The signature of certificate x (x>1) is verified using the public 616 key of the issuer's certificate (x-1), using the signature 617 algorithm specified for that public key (in certificate x-1). 619 2. The current time lies within the interval defined by the 620 NotBefore and NotAfter values in the Validity field of 621 certificate x. 623 3. The Version, Issuer, and Subject fields of certificate x satisfy 624 the constraints established in Section 4.1-4.7 of this 625 specification. 627 4. If certificate x uses the Certificate Policy defined in section 628 4.8.9 of [RFC6487], then the certificate MUST contain all 629 extensions defined in section 4.8 of [RFC6487] that must be 630 present. The value(s) for each of these extensions MUST satisfy 631 the constraints established for each extension in the respective 632 sections. Any extension not thus identified MUST NOT appear in 633 certificate x. 635 5. If certificate x uses the Certificate Policy defined in 636 Section 4.2.4.1, then all extensions defined in section 4.8 of 637 [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be 638 present. The certificate MUST contain an extension as defined in 639 Section 4.2.4.2 or Section 4.2.4.3, or both. The value(s) for 640 each of these extensions MUST satisfy the constraints established 641 for each extension in the respective sections. Any extension not 642 thus identified MUST NOT appear in certificate x. 644 6. Certificate x MUST NOT have been revoked, i.e., it MUST NOT 645 appear on a CRL issued by the CA represented by certificate x-1 647 7. Compute the VRS-IP and VRS-AS set values as indicated below: 649 * If the IP Address Delegation extension is present in 650 certificate x and x=1, set the VRS-IP to the resources found 651 in this extension. 653 * If the IP Address Delegation extension is present in 654 certificate x and x>1, set the VRS-IP to the intersection of 655 the resources between this extension and the value of the VRS- 656 IP computed for certificate x-1. 658 * If the IP Address Delegation extension is absent in 659 certificate x, set the VRS-IP to NULL. 661 * If the IP Address Delegation extension is present in 662 certificate x and x=1, set the VRS-IP to the resources found 663 in this extension. 665 * If the AS Identifier Delegation extension is present in 666 certificate x and x>1, set the VRS-AS to the intersection of 667 the resources between this extension and the value of the VRS- 668 AS computed for certificate x-1 670 * If the AS Identifier Delegation extension is absent in 671 certificate x, set the VRS-AS to NULL. 673 8. If there is any difference in resources in the VRS-IP and the IP 674 Address Delegation extension on certificate x, or the VRS-AS and 675 the AS Identifier Delegation extension on certificate x, then: 677 * If certificate x uses the Certificate Policy defined in 678 Section 4.2.4.1 a warning listing the over-claiming resources 679 for certificate x SHOULD be issued. 681 * If certificate x uses the Certificate Policy defined in 682 section 4.8.9 of [RFC6487], then certificate x MUST be 683 rejected. 685 These rules allow a CA certificate to contain resources that are not 686 present in (all of) the certificates along the path from the trust 687 anchor to the CA certificate. If none of the resources in the CA 688 certificate are present in all certificates along the path, no 689 subordinate certificates could be valid. However, the certificate is 690 not immediately rejected as this may be a transient condition. Not 691 immediately rejecting the certificate does not result in a security 692 problem because the associated VRS sets accurately reflect the 693 resources validly associated with the certificate in question. 695 4.2.5. An alternative ROA validation RFC6482 697 Section 4 of [RFC6482] currently has the following text on the 698 validation of resources on a ROA: 700 o The IP address delegation extension [RFC3779] is present in the 701 end-entity (EE) certificate (contained within the ROA), and each 702 IP address prefix(es) in the ROA is contained within the set of IP 703 addresses specified by the EE certificate's IP address delegation 704 extension. 706 If the end-entity certificate uses the Certificate Policy defined in 707 Section 4.2.4.1, then the following approach must be used instead. 709 o The amended IP address delegation extension described in 710 Section 4.2.4.2 is present in the end-entity (EE) certificate 711 (contained within the ROA), and each IP address prefix(es) in the 712 ROA is contained within the VRS-IP set that is specified as an 713 outcome of EE certificate validation described in Section 4.2.4.4. 715 Note that this ensures that ROAs can be valid only, if all IP address 716 prefixes in the ROA are encompassed by the VRS-IP of all certificates 717 along the path to the trust anchor used to verify it. 719 Operators MAY issue separate ROAs for each IP address prefix, so that 720 the loss of one or more IP address prefixes from the VRS-IP of any 721 certificate along the path to the trust anchor would not invalidate 722 authorizations for other IP address prefixes. 724 4.2.6. An alternative to BGPSec Router Certificate Validation 726 If a BGPsec Router Certificate ([I-D.ietf-sidr-bgpsec-pki-profiles]) 727 uses the Certificate Policy defined in Section 4.2.4.1, then in 728 addition to the BGPsec Router Certificate Validation defined in 729 section 3.3 of [I-D.ietf-sidr-bgpsec-pki-profiles], the following 730 constraint MUST be met: 732 o The VRS-AS of BGPsec Router Certificates MUST encompass all ASNs 733 in the AS Resource Identifier Delegation extension. 735 Operators MAY issue separate BGPsec Router Certificates for different 736 ASNs, so that the loss of on ASN from the VRS-AS of any certificate 737 along the path to the trust anchor would not invalidate router keys 738 for other ASNs. 740 4.3. An example 742 Consider the following example under the amended approach: 744 Certificate 1 (trust anchor): 745 Issuer TA, 746 Subject TA, 747 Resources 192.0.2.0/24, 198.51.100.0/24, 748 2001:db8::/32, AS64496-AS64500 750 Verified Resource Set: 192.0.2.0/24, 198.51.100.0/24, 751 2001:db8::/32, AS64496-AS64500 752 Warnings: none 754 Certificate 2: 755 Issuer TA, 756 Subject CA1, 757 Resources 192.0.2.0/24, 2001:db8::/32, AS64496 759 Verified Resource Set: 192.0.2.0/24, 760 2001:db8::/32, AS64496 761 Warnings: none 763 Certificate 3: 764 Issuer CA1, 765 Subject CA2, 766 Resources 192.0.2.0/24, 198.51.100.0/24, AS64496 768 Verified Resource Set: 192.0.2.0/24, AS64496 769 Warnings: over-claim for 198.51.100.0/24 771 ROA 1 (valid): 772 Embedded Certificate 4 (EE certificate): 773 Issuer CA2, 774 Subject R1, 775 Resources 192.0.2.0/24 777 Verified resources: 192.0.2.0/24 778 Warnings: none 780 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 782 ROA1 is considered valid because the prefix matches the Verified 783 Resource Set on the embedded EE certificate. 785 ROA 2 (invalid): 786 Embedded Certificate 5 (EE certificate invalid): 787 Issuer CA2, 788 Subject R2, 789 Resources 198.51.100.0/24 791 EE certificate is invalid due to over-claim for 198.51.100.0/24 793 Prefix 198.51.100.0/24, Max Length 24, ASN 64496 795 ROA2 is considered invalid because the embedded EE certificate is 796 considered invalid. 798 BGPSec Certificate 1 (valid): 799 Issuer CA2 800 Subject ROUTER-64496 801 Resources AS64496 802 Verified resources: AS64496 803 Warnings: none 805 BGPSec Certificate 2 (invalid): 806 Issuer CA2 807 Subject ALL-ROUTERS 808 Resources AS64496-AS64497 810 EE certificate is invalid due to over-claim for AS64497 812 This problem can be mitigated by issuing separate certificates 813 for each AS number. 815 5. Deployment Considerations 817 Because this document introduces new OIDs and an alternative the 818 Profile for X.509 PKIX Resource Certificates described in [RFC6487], 819 the use of such certificates in the global RPKI will lead to the 820 rejection of such certificates by Relying Party tools that do not 821 (yet) implement the alternative profile described in this document. 823 For this reason it is important that such tools are updated before 824 Certificate Authorities start to use this specification. 826 However, because the choice of algorithm is well-defined for each 827 certificate and/or RPKI signed object, there is no strict requirement 828 for all Certificate Authorities to migrate to this new algorithm 829 within a specific time period. The choice to opt-in to this can be 830 made by each CA independently. CAs MAY also choose to use the new 831 algorithm for new certificates or objects only, without pro-actively 832 re-issuing existing objects - for example because the latter would 833 require an active authorisation by a user of the system. 835 6. Security Considerations 837 The authors believe that the revised validation algorithm introduces 838 no new security vulnerabilities into the RPKI, because it cannot lead 839 to any ROA and/or Router Certificates to be accepted if they contain 840 resources that are not held by the issuer. 842 7. IANA Considerations 844 IANA is to add the following to the SMI Security for PKIX Certificate 845 Policies registry: 847 Decimal Description References 849 TBD1 id-cp-ipAddr-asNumber-v2 [section 4.2.1] 851 IANA is to add the following to the SMI Security for PKIX Certificate 852 Extension registry: 854 Decimal Description References 856 TBD2 id-pe-ipAddrBlocks-v2 [section 4.2.2.1] 857 TBD3 id-pe-autonomousSysIds-v2 [section 4.2.2.3] 859 IANA is to add the following to the SMI Security for PKIX Module 860 Identifier registry: 862 Decimal Description References 864 TBD4 id-mod-ip-addr-and-as-ident-v2 [section 4.2.2.7] 865 TBD5 id-mod-ip-addr-and-as-ident-2v2 [section 4.2.3] 867 8. Acknowledgements 869 The authors would like to thank Stephen Kent for reviewing and 870 contributing to this document. We would like to thank Rob Austein 871 for suggesting that separate OIDs should be used to make the 872 behaviour of Relying Party tools deterministic, and we would like to 873 thank Russ Hously, Sean Turner and Tom Petch for their contributions 874 on OID and ASN.1 updates. Finally we would like to thank Tom 875 Harrison for a general review of this document. 877 9. References 879 9.1. Normative References 881 [I-D.ietf-sidr-bgpsec-pki-profiles] 882 Reynolds, M., Turner, S., and S. Kent, "A Profile for 883 BGPsec Router Certificates, Certificate Revocation Lists, 884 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 885 profiles-21 (work in progress), January 2017. 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, 889 DOI 10.17487/RFC2119, March 1997, 890 . 892 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 893 Addresses and AS Identifiers", RFC 3779, 894 DOI 10.17487/RFC3779, June 2004, 895 . 897 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 898 Housley, R., and W. Polk, "Internet X.509 Public Key 899 Infrastructure Certificate and Certificate Revocation List 900 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 901 . 903 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 904 Origin Authorizations (ROAs)", RFC 6482, 905 DOI 10.17487/RFC6482, February 2012, 906 . 908 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 909 Policy (CP) for the Resource Public Key Infrastructure 910 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 911 2012, . 913 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 914 X.509 PKIX Resource Certificates", RFC 6487, 915 DOI 10.17487/RFC6487, February 2012, 916 . 918 9.2. Informative References 920 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 921 for the Cryptographic Message Syntax (CMS) and the Public 922 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 923 DOI 10.17487/RFC6268, July 2011, 924 . 926 Authors' Addresses 928 Geoff Huston 929 Asia Pacific Network Information Centre 930 6 Cordelia St 931 South Brisbane, QLD 4101 932 Australia 934 Phone: +61 7 3858 3100 935 Email: gih@apnic.net 936 George Michaelson 937 Asia Pacific Network Information Centre 938 6 Cordelia St 939 South Brisbane, QLD 4101 940 Australia 942 Phone: +61 7 3858 3100 943 Email: ggm@apnic.net 945 Carlos M. Martinez 946 Latin American and Caribbean IP Address Regional Registry 947 Rambla Mexico 6125 948 Montevideo 11400 949 Uruguay 951 Phone: +598 2604 2222 952 Email: carlos@lacnic.net 954 Tim Bruijnzeels 955 RIPE Network Coordination Centre 956 Singel 258 957 Amsterdam 1016 AB 958 The Netherlands 960 Email: tim@ripe.net 962 Andrew Lee Newton 963 American Registry for Internet Numbers 964 3635 Concorde Parkway 965 Chantilly, VA 20151 966 USA 968 Email: andy@arin.net 970 Daniel Shaw 971 African Network Information Centre (AFRINIC) 972 11th Floor, Standard Chartered Tower 973 Cybercity, Ebene 974 Mauritius 976 Phone: +230 403 51 00 977 Email: daniel@afrinic.net