idnits 2.17.1 draft-ietf-sidr-ltamgmt-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 5) being 72 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 51 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 146 has weird spacing: '...ttom-up path ...' == Line 147 has weird spacing: '...ttom-up path ...' == Line 148 has weird spacing: '...es that might...' == Line 292 has weird spacing: '...ntifier unc...' == Line 295 has weird spacing: '... points repl...' == (4 more instances...) -- The document date (Apr 5, 2013) is 4038 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4158' is mentioned on line 138, but not defined == Missing Reference: 'RFC6490' is mentioned on line 143, but not defined ** Obsolete undefined reference: RFC 6490 (Obsoleted by RFC 7730) == Missing Reference: 'RFC6484' is mentioned on line 498, but not defined == Unused Reference: 'RFC2119' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'RFC5396' is defined on line 1155, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 6480 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing M. Reynolds 3 Internet-Draft IPSw 4 Intended status: Standards Track S. Kent 5 Expires: October 2, 2013 BBN 6 M. Lepinski 7 BBN 8 Apr 5, 2013 10 Local Trust Anchor Management for the Resource Public Key Infrastructure 11 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on October 2, 2013. 36 Copyright and License Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 This document describes a facility to enable a relying party (RP) to 54 manage trust anchors (TAs) in the context of the Resource Public Key 55 Infrastructure (RPKI). It is common in RP software (not just in the 56 RPKI) to allow an RP to import TA material in the form of self-signed 57 certificates. However, this approach to incorporating TAs is 58 potentially dangerous. (These self-signed certificates rarely 59 incorporate any extensions that impose constraints on the scope of 60 the imported public keys, and the RP is not able to impose such 61 constraints.) The facility described in this document allows an RP to 62 impose constraints on such TAs. Because this mechanism is designed to 63 operate in the RPKI context, the most important constraints are the 64 Internet Number Resources (INRs) expressed via RFC 3779 extensions. 65 These extentions bind address spaces and/or autonomous system (AS) 66 numbers to entities. The primary motivation for the facility described 67 in this document is to enable an RP to ensure that INR information 68 that it has acquired via some trusted channel is not overridden by the 69 information acquired from the RPKI repository system or by the putative 70 TAs that the RP imports. Specifically, the mechanism allows an RP to 71 specify a set of overriding bindings between public key identifiers and 72 INR data. These bindings take precedence over any conflicting bindings 73 acquired by the putative TAs and the certificates downloaded from the 74 RPKI repository system. This mechanism is designed for local use by an RP, 75 but any entity that is accorded administrative control over a set of RPs 76 may use this mechanism to convey its view of the RPKI to RPs within its 77 jurisdiction. The means by which this latter use case is effected is 78 outside the scope of this document. 80 Table of Contents 82 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 84 2 Overview of Certificate Processing . . . . . . . . . . . . . . 5 85 2.1 Target Certificate Processing . . . . . . . . . . . . . . . 5 86 2.2 Perforation . . . . . . . . . . . . . . . . . . . . . . . . 5 87 2.3 TA Re-parenting . . . . . . . . . . . . . . . . . . . . . . 6 88 2.4 Paracertificates . . . . . . . . . . . . . . . . . . . . . 6 89 3 Format of the constraints file . . . . . . . . . . . . . . . . 8 90 3.1 Relying party subsection . . . . . . . . . . . . . . . . . 8 91 3.2 Flags subsection . . . . . . . . . . . . . . . . . . . . . 8 92 3.3 Tags subsection . . . . . . . . . . . . . . . . . . . . . . 9 93 3.3.1 Xvalidity_dates tag . . . . . . . . . . . . . . . . . . 10 94 3.3.2 Xcrldp tag . . . . . . . . . . . . . . . . . . . . . . 10 95 3.3.3 Xcp tag . . . . . . . . . . . . . . . . . . . . . . . . 11 96 3.3.4 Xaia tag . . . . . . . . . . . . . . . . . . . . . . . 11 97 3.4 Blocks subsection . . . . . . . . . . . . . . . . . . . . . 12 98 4 Certificate Processing Algorithm . . . . . . . . . . . . . . . 13 99 4.1 Proofreading algorithm . . . . . . . . . . . . . . . . . . 14 100 4.2 TA processing algorithm . . . . . . . . . . . . . . . . . . 15 101 4.2.1 Preparatory processing (stage 0) . . . . . . . . . . . 16 102 4.2.2 Target processing (stage 1) . . . . . . . . . . . . . . 17 103 4.2.3 Ancestor processing (stage 2) . . . . . . . . . . . . . 18 104 4.2.4 Tree processing (stage 3) . . . . . . . . . . . . . . . 19 105 4.2.5 TA re-parenting (stage 4) . . . . . . . . . . . . . . . 20 106 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21 107 5 Implications for Path Discovery . . . . . . . . . . . . . . . . 21 108 5.1 Two answers . . . . . . . . . . . . . . . . . . . . . . . . 21 109 5.2 One answer . . . . . . . . . . . . . . . . . . . . . . . . 22 110 5.3 No answer . . . . . . . . . . . . . . . . . . . . . . . . . 22 111 6 Implications for Revocation . . . . . . . . . . . . . . . . . . 22 112 6.1 No state bits set . . . . . . . . . . . . . . . . . . . . . 23 113 6.2 ORIGINAL state bit set . . . . . . . . . . . . . . . . . . 23 114 6.3 PARA state bit set . . . . . . . . . . . . . . . . . . . . 23 115 6.4 Both ORIGINAL and PARA state bits set . . . . . . . . . . . 24 116 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 24 117 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 118 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 119 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 120 10.1 Normative References . . . . . . . . . . . . . . . . . . . 24 121 10.2 Informative References . . . . . . . . . . . . . . . . . . 25 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 123 Appendix A: Sample Constraints File . . . . . . . . . . . . . . . 26 124 Appendix B: Optional Sorting Algorithm for Ancestor Processing . . 27 126 1 Introduction 128 The Resource Public Key Infrastructure (RPKI) [RFC6480] is a 129 PKI in which certificates are issued to facilitate management of 130 Internet Resource Numbers (INRs). Such resources are expressed in 131 the form of X.509v3 "resource" certificates with extensions defined 132 by RFC 3779 [RFC6487]. Validation of a resource certificate is 133 preceded by path discovery. In a PKI path discovery is effected by 134 constructing a certificate path between a target certificate and a 135 trust anchor (TA). No IETF standards define how to construct a 136 certificate path; commonly such paths are based on a bottom-up 137 search using Subject/Issuer name matching, but top-down and 138 meet-in-the-middle approaches may also be employed [RFC4158]. In 139 contrast, path validation is top-down, as defined by [RFC5280]. 141 In the RPKI, certificates can be acquired in various ways, but the 142 default is a top-down tree walk as described in [RFC6481], 143 initialized via a Trust Anchor Locator [RFC6490]. Note that the 144 process described there is not path discovery per sem but the 145 collecting of certificates to populate a local cache. Thus, the 146 common, bottom-up path discovery approach is not inconsistent 147 with these RFCs. Morevoer, a bottom-up path discovery approach 148 is more general, accommodating certificates that might be 149 acquired by other means, i.e., not from an RPKI repository. There 150 are circumstances under which an RP may wish to override the INR 151 specifications obtained through the RPKI distributed repository 152 system [RFC6481]. This document describes a mechanism by which 153 an RP may override any conflicting information expressed via 154 putative TAs and the certificates downloaded from the RPKI 155 repository system. Thus the algorithms described in this document 156 adopt a bottom-up path discovery approach. 158 To effect this local control, this document calls for a relying party 159 to specify a set of bindings between public key identifiers and 160 INRs through a text file known as a constraints file. The constraints 161 expressed in this file then take precedence over any competing claims 162 expressed by resource certificates acquired from the distributed 163 repository system. (The means by which a relying party acquires the 164 key identifier and the RFC 3779 extension data used to populate the 165 constraints file is outside the scope of this document.) The relying 166 party also may use a local publication point (the root of a local 167 directory tree that is made available as if it were a remote 168 repository) as a source of certificates and CRLs (and other RPKI 169 signed objects, e.g., ROAs and manifests) that do not appear in the 170 RPKI repository system. 172 In order to allow reuse of existing, standard path validation 173 mechanisms, the RP-imposed constraints are realized by having the RP 174 itself represented as the only TA known in the local certificate 175 validation context. To ensure that all RPKI certificates can be 176 validated relative to this TA, this RP TA certificate must contain 177 all-encompassing resource allocations, i.e. 0/0 for IPv4, 0::/0 for 178 IPv6 and 0-4294967295 for AS numbers. Thus, a conforming 179 implementation of this mechanism must be able to cause a self-signed 180 certification authority (CA) certificate to be created with a locally 181 generated key pair. It also must be able to issue CA certificates 182 subordinate to this TA. Finally, a conforming implementation of this 183 mechanism must process the constraints file and modify certificates 184 as needed in order to enforce the constraints asserted in the file. 186 The remainder of this document describes in detail the types of 187 certificate modification that may occur, the syntax and semantics of 188 the constraints file, and the implications of certificate modification 189 on path discovery and revocation. 191 1.1 Terminology 193 It is assumed that the reader is familiar with the terms and concepts 194 described in "Internet X.509 Public Key Infrastructure Certificate 195 and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 196 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in RFC 2119. 202 2 Overview of Certificate Processing 204 The fundamental aspect of the facility described in this document is 205 one of certificate modification. The constraints file, described in 206 more detail in the next section, contains assertions about INRs 207 that are to be specially processed. As a result of this processing, 208 certificates in the local copy of the RPKI repository are transformed 209 into new certificates satisfying the INR constraints so specified. 210 This enables the RP to override conflicting assertions about resource 211 holdings as acquired from the RPKI repository system. Three forms of 212 certificate modification can occur. (Every certificate is digitally 213 signed and thus cannot be modified without "breaking" its signature. 214 In the context of this document we assume that certificates that are 215 modified have been validated previously. Thus the content can be 216 modified, locally, without the need to preserve the integrity of the 217 signature. These modified certificates are referred to as 218 paracertificates (see section 2.4 below).) 220 2.1 Target Certificate Processing 222 If a certificate is acquired from the RPKI repository system and its 223 Subject key identifier (SKI) is listed in the constraints file, it 224 will be reissued directly under the RP TA certificate, with (possibly) 225 modified RFC 3779 extensions. (The SKI is used as a compact reference 226 to the public key in a target certificate.) The modified extensions 227 will include any RFC 3779 data expressed in the constraints file. Other 228 certificate fields may also be modified to maintain consistency. (These 229 fields are enumerated in Table 1, and discussed in Section 3.3.) In 230 Section 4.2, target certificate processing corresponds to stage one of 231 the algorithm. (When a target certificate is re-parented, all 232 subordinate signed products will still be valid, unless the set of 233 INRs in the targeted certificate is reduced.) 235 2.2 Perforation 237 When a target certificate is re-issued directly under the RP's TA, its 238 INRs MUST be removed from all of its parent (CA) certificates. (If 239 these INRs were not removed, then conflicting assertions about INRs 240 could arise and undermine the authority of the RP TA.) Thus, every 241 certificate acquired from the RPKI repository MUST be examined to 242 determine if it contains an RFC 3779 extension that intersects the 243 resource data in the constraints file. If there is an intersection 244 the certificate will be reissued directly under the RP TA, with 245 modified RFC 3779 extensions. We refer to the process of modifying 246 the RFC 3779 extension in an affected certificate as "perforation" 247 (because the process will create "holes" in these extensions). The 248 modified extensions will exclude any RFC 3779 data expressed in the 249 constraints file. In the certificate processing algorithm described 250 in Section 4.2, perforation corresponds to stage two of the algorithm 251 ("ancestor processing") and also to stage three of the algorithm 252 ("tree processing"). 254 2.3 TA Re-parenting 256 All valid, self-signed certificates offered as TAs in the public RPKI 257 certificate hierarchy, e.g., self-signed certificates issued by IANA 258 or RIRs, will be re-issued under the RP TA certificate. This processing 259 is done even though all but one of these certificates might not 260 intersect any resources specified in the constraints file. We refer to 261 this reissuance as "re-parenting" since the issuer (parent) of the 262 certificate has been changed. The issuer name is changed from that of 263 the certificate subject (this is a self-signed certificate) to that of 264 the RP TA. In the certificate processing algorithm described in Section 265 4.2, TA re-parenting corresponds to stage four of the algorithm. (In 266 a more generic PKI context, re-parenting enables an RP to insert 267 extensions in these certificates to impose constraings on path 268 processing in a fashion consistent with RFC 5280. In this fashion an 269 RP can impose name constraints, policy constraints, etc.) 271 2.4 Paracertificates 273 If a certificate is subject to any of the three forms of processing 274 just described, that certificate will be referred to as an "original" 275 certificate and the processed (output) certificate will be referred 276 to as a paracertificate. When an original certificate is transformed 277 into a paracertificate all the fields and extensions from the 278 original certificate will be retained, except as indicated in Table 279 1, below. 281 Original Certificate Field Action 283 Version unchanged 284 Serial number created per note A 285 Signature replaced if needed 286 with RP's signing alg 287 Issuer replaced with RP's name 288 Validity dates replaced per note B 289 Subject unchanged 290 Subject public key info unchanged 291 Extensions 292 Subject key identifier unchanged 293 Key usage unchanged 294 Basic constraints unchanged 295 CRL distribution points replaced per note B 296 Certificate policy replaced per note B 297 Authority info access replaced per note B 298 Authority key ident replaced with RP's 299 IP address block modified as described 300 AS number block modified as described 301 Subject info access unchanged 302 All other extensions unchanged 303 Signature Algorithm same as above 304 Signature value new 306 Table 1 Certificate Field Modifications 308 Note A. The serial number will be created by concatenating the 309 current time (the number of seconds since Jan 1, 1970) with a count 310 of the certificates created in the current run. Because all 311 paracertificates are issued directly below the RP TA, this algorithm 312 ensures serial number uniqueness. 314 Note B. These fields are derived (as described in Section 3.3 below) 315 from parameters in the constraints file (if present); otherwise, they 316 take on values from the certificates from which the paracertificates 317 are derived. 319 3 Format of the constraints file 321 This section describes the syntax of the constraints file. (The 322 syntax has been defined to enable creation and distribution of 323 constraint files to a set of RPs, by an authorized third party.) 324 The model described below is nominal; implementations need not match 325 all details of this model as presented, but the external behavior of 326 implementations MUST correspond to the externally observable 327 characteristics of this model in order to be compliant. It is 328 RECOMMENDED that the syntax described herein be supported, to 329 facilitate interoperability between creators and comsumers of 330 constraints files. 332 The constraints file consists of four logical subsections: the 333 replying party subsection, the flags subsection, the tags subsection 334 and the blocks subsection. The relying party subsection and the 335 blocks subsection are REQUIRED and MUST be present; the flags and 336 tags subsections are OPTIONAL. Each subsection is described in more 337 detail below. Note that the semicolon (;) character acts as the 338 comment character, to enable annotating constraints files. All 339 characters from a semicolon to the end of that line are ignored. In 340 addition, lines consisting only of whitespace are ignored. The 341 subsections MUST occur in the order indicated. An example constraints 342 file is given in Appendix A. 344 3.1 Relying party subsection 346 The relying party subsection is a REQUIRED subsection of the 347 constraints file. It MUST be the first subsection of the constraints 348 file, and it MUST consist of two lines of the form: 349 (RECOMMENDED) 351 PRIVATEKEYMETHOD value [ ... value ] 352 TACERTIFICATE value 354 The first line provides a pointer (including an access method) to 355 the RP's private key. This line consists of the string literal 356 PRIVATEKEYMETHOD, followed by one or more whitespace delimited string 357 values. These values are passed to the certificate processing 358 algorithm as described below. Note that this entry, as for all 359 entries in the constraints file, is case sensitive. 361 The second line of this subsection consists of the string literal 362 TACERTIFICATE, followed by exactly one string value. This value 363 is the name of a file containing the relying party's TA certificate. 364 The file name is passed to the certificate processing algorithm as 365 described below. 367 3.2 Flags subsection 369 The flags subsection of the constraints file is an OPTIONAL 370 subsection. If present it MUST immediately follow the relying party 371 subsection. The flags subsection consists of one or more lines of the 372 form 374 CONTROL flagname booleanvalue 376 Each such line is referred to as a control line. Each control line 377 MUST contain exactly three whitespace delimited strings. The first 378 string MUST be the literal CONTROL. The second string MUST be one of 379 the following three literals: 381 resource_nounion 382 intersection_always 383 treegrowth 385 The third string denotes a Boolean value, and MUST be one of the 386 literals TRUE or FALSE. Control flags influence the global operation 387 of the certificate processing algorithm; the semantics of the flags 388 is described in Section 4.2. Note that each flag has a default value, 389 so that if the corresponding CONTROL line does not appear in the 390 constraints file, the algorithm flag is considered to take the 391 corresponding default value. The default value for each flag is FALSE. 392 Thus, if any flag is not named in a control line it takes the value 393 FALSE. If the flags subsection is absent, all three flags assume the 394 default value FALSE. 396 3.3 Tags subsection 398 The tags subsection is an OPTIONAL subsection in the constraints 399 file. If present it MUST immediately follow the relying party 400 subsection (if the flags subsection is absent) or the flags 401 subsection (if it is present). The tags subsection consists of one or 402 more lines of the form 404 TAG tagname tagvalue [ ... tagvalue ] 406 Each such line is referred to as a tag line. Each tag line MUST 407 consist of at least three whitespace delimited string values, the 408 first of which must be the literal TAG. The second string value gives 409 the name of the tag, and subsequent string(s) give the value(s) of 410 the tag. The tag name MUST be one of the following four string 411 literals: 413 Xvalidity_dates 414 Xcrldp 415 Xcp 416 Xaia 418 The purpose of the tag lines is to provide an indication of the means 419 by which paracertificate fields, specifically those indicated above 420 under "Note B", of Table 1are constructed. Each tag has a default, so 421 that if the corresponding tag line is not present in the constraints 422 file, the default behavior is used when constructing the 423 paracertificates. The syntax and semantics of each tag line is 424 described next. 426 Note that the tag lines are considered to be global; the action of 427 each tag line (or the default action, if that tag line is not 428 present) applies to all paracertificates that are created as part of 429 the certificate processing algorithm. 431 3.3.1 Xvalidity_dates tag 433 This tag line is used to control the value of the notBefore and 434 notAfter fields in paracertificates. If this tag line is specified 435 and there is a single tagvalue which is the literal string C, the 436 paracertificate validity interval is copied from the original 437 certificate validity interval from which it is derived. If this tag 438 is specified and there is a single tagvalue which is the literal 439 string R, the paracertificate validity interval is copied from the 440 validity interval of the RP's TA certificate. If this tag is specified 441 and the tagvalue is neither of these literals, then exactly two 442 tagvalues MUST be specified. Each must be a Generalized Time string 443 of the form YYYYMMDDHHMMSSZ. The first tagvalue is assigned to the 444 notBefore field and the second tagvalue is assigned to the notAfter 445 field. It MUST be the case that the tagvalues can be parsed as valid 446 Generalized Time strings such that notBefore is less than notAfter, 447 and also such that notAfter represents a time in the future (i.e., 448 the paracertificate has not already expired). 450 If this tag line is not present in the constraints file the default 451 behavior is to copy the validity interval from the original 452 certificate to the corresponding paracertificate. 454 3.3.2 Xcrldp tag 456 This tag line is used to control the value of the CRL distribution 457 point extension in paracertificates. If this tag line is specified 458 and there is a single tagvalue that is the string literal C, the 459 CRLDP of the paracertificate is copied from the CRLDP of the original 460 certificate from which it is derived. If this tag line is specified 461 and there is a single tagvalue that is the string literal R, the 462 CRLDP of the paracertificate is copied from the CRLDP of the RP's TA 463 certificate. If this tag line is specified and there is a single 464 tagvalue that is not one of these two reserved literals, or if 465 there is more than one tagvalue, then each tagvalue is interpreted as 466 a URI that will be placed in the CRLDP sequence in the 467 paracertificate. 469 If this tag line is not present in the constraints file the default 470 behavior is to copy the CRLDP from the original certificate into the 471 corresponding paracertificate. 473 3.3.3 Xcp tag 475 This tag line is used to control the value of the policyQualifierId 476 field in paracertificates. If this tag line is specified there MUST 477 be exactly one tagvalue. If the tagvalue is the string literal C, the 478 paracertificate value is copied from the value in the corresponding 479 original certificate. If the tagvalue is the string literal R, the 480 paracertificate value is copied from the value in the RP's top level 481 TA certificate. If the tagvalue is the string literal D, the 482 paracertificate value is set to the default OID. If the tagvalue is 483 not one of these reserved string literals, then the tagvalue MUST be 484 an OID specified using the standard dotted notation. The value in the 485 paracertificate's policyQualifierId field is set to this OID. Note 486 the RFC 5280 specifies that only a single policy may be specified in 487 a certificate, so only a single tagvalue is permitted in this tag 488 line, even though the CertificatePolicy field is an ASN.1 sequence. 490 If this tag line is not specified the default behavior is to use the 491 default OID in creating the paracertificate. 493 This option permits the RP to convert a value of the 494 policyQualifierId field in a certificate (that would not be in 495 conformance with the RPKI CP) to a conforming value in the 496 paracertificate. This conversion enables use of RPKI validation 497 software that checks the policy field against that specified in the 498 RPKI CP [RFC6484]. 500 3.3.4 Xaia tag 502 This tag line is used to control the value of the Authority 503 Information Access (AIA) extension in the paracertificate. If this 504 tag line is present then it MUST have exactly one tagvalue. If this 505 tagvalue is the string literal C, then the AIA field in the 506 paracertificate is copied from the AIA field in the original 507 certificate from which it is derived. If this tag line is present and 508 the tagvalue is not the reserved string literal, then the tagvalue 509 MUST be a URI. This URI is set as the AIA extension of the 510 paracertificates that are created. 512 If this tag line is not specified the default behavior is to use copy 513 the AIA field from the original certificate to the AIA field of the 514 paracertificate. 516 3.4 Blocks subsection 518 The blocks subsection is a REQUIRED subsection of the constraints 519 file. If the tags subsection is present, the blocks subsection MUST 520 appear immediately after it. This MUST be the last subsection in 521 the constraints file. The blocks subsection consists of one or more 522 blocks, known as target blocks. A target block is used to specify an 523 association between a certificate (identified by an SKI) and a set 524 of resource assertions. Each target block contains four regions, an SKI 525 region, an IPv4 region, an IPv6 region and an AS number region. All 526 regions MUST be present in a target block. 528 The SKI region contains a single line beginning with the string 529 literal SKI and followed by forty hexadecimal characters giving the 530 subject key identifier of a certificate, known as the target 531 certificate. The hex character string MAY contain embedded whitespace 532 or colon characters (included to improve readability), which are 533 ignored. The IPv4 region consists of a line containing only the 534 string literal IPv4. This line is followed by zero or more lines 535 containing IPv4 prefixes in the format described in RFC 3779. The 536 IPv6 region consists of a line containing only the string literal 537 IPv6, followed by zero or more lines containing IPv6 prefixes using 538 the format described in RFC 3513. (The presence of the IPv4 and IPv6 539 literals is to simplify parsing of the constraints file.) Finally, 540 the AS number region consists of a line containing only the string 541 literal AS#, followed by zero or more lines containing AS numbers 542 (one per line). The AS numbers are specified in decimal notation as 543 recommended in RFC 5396. A target block is terminated by either the 544 end of the constraints file, or by the beginning of the next target 545 block, as signaled by its opening SKI region line. An example target 546 block is shown below. (The indentation used below is employed to 547 improve readability and is not required.) See also the complete 548 constraints file example in Appendix A. Note that whitespace, as 549 always, is ignored. 551 SKI 00:12:33:44:00:BA:BA:DE:EB:EE:00:99:88:77:66:55:44:33:22:11 552 IPv4 553 10.2.3/24 554 10.8/16 555 IPv6 556 1:2:3:4:5:6/112 557 AS# 558 123 559 567 561 The blocks subsection MUST contain at least one target block. Note 562 that it is OPTIONAL that the SKI refer to a certificate that is known 563 or resolvable within the context of the local RPKI repository. Also, 564 there is no REQUIRED or implied ordering of target blocks within the 565 block subsection. Since blocks may occur in any order, the outcome of 566 processing a constraints file may depend on the order in which target 567 blocks occur within the constraints file. The next section of this 568 document contains a detailed description of the certificate processing 569 algorithm. 571 4 Certificate Processing Algorithm 573 The section describes the certificate processing algorithm by which 574 paracertificates are created from original certificates in the 575 local RPKI repository. For the purposes of describing this algorithm, 576 it will be assumed that certificates are persistently associated 577 with state (or metadata) information. This state information is 578 nominally represented by an array of named bits associated with each 579 certificate. No specific implementation of this functionality is 580 mandated by this document. Any implementation that provides the 581 indicated functionality is acceptable, and need not actually consist 582 of a bit field associated with each certificate. 584 The following state bits used in certificate processing are 586 NOCHAIN 587 ORIGINAL 588 PARA 589 TARGET 591 If the NOCHAIN bit is set, this indicates that a full path between 592 the given certificate and a TA has not yet been discovered. If the 593 ORIGINAL bit is set, this indicates that the certificate in question 594 has been processed by some part of the processing algorithm described 595 in Section 4.2. If it was processed as part of stage one processing, 596 as described in section 4.2.2, the TARGET bit also will be set. 597 Finally, every paracertificate will have the PARA bit set. 599 At the beginning of algorithm processing each certificate in the 600 local RPKI repository has the ORIGINAL, PARA and TARGET bits clear. 601 If a certificate has a complete, validated path to a TA, or is itself 602 a TA, then that certificate will have the NOCHAIN bit clear, 603 otherwise it will have the NOCHAIN bit set. As the certificate 604 processing algorithm proceeds, the metadata state of original 605 certificates may change. In addition, since the certificate 606 processing algorithm may also be creating paracertificates, it is 607 responsible for actively setting or clearing the state of these four 608 bits on those paracertificates. 610 The certificate processing algorithm consists of two sub-algorithms: 612 "proofreading" and "TA processing". Conceptually, the proofreading 613 algorithm performs syntactic checks on the constraints file, 614 while the TA processing algorithm performs the actual certificate 615 transformation processing. If the proofreading algorithm does not 616 succeed in parsing the constraints file, the TA processing- 617 algorithm is not executed. Note also that if the constraints file is 618 not present, neither algorithm is executed and the local RPKI 619 repository is not modified. Each of the constituent algorithms will 620 now be described in detail. 622 4.1 Proofreading algorithm 624 The proofreading algorithm checks the constraints file for syntactic 625 errors, e.g., missing REQUIRED subsections, or malformed addresses. 626 Implementation of this algorithm is OPTIONAL. If it is implemented, 627 the following text defines correct operation for the algorithm. 628 The proofreading algorithms performs a set of heuristic checks, such 629 as checking for prefixes that are too large (e.g., larger than /8). 630 The proofreading algorithm also SHOULD examine resource regions (IPv4, 631 IPv6 and AS# regions) within the blocks subsection, and reorder such 632 resources within a region in ascending numeric order. On encountering 633 any error the proofreading algorithm SHOULD provide an error message 634 indicating the line on which the error occurred as well as informative 635 text that is sufficiently descriptive as to allow the user to identify 636 and correct the error. An implementation of the proofreading algorithm 637 MUST NOT assume that it has access to the local RPKI repository (even 638 read-only access). An implementation of the proofreading algorithm MUST 639 NOT alter the local RPKI repository in any way; it also MUST NOT change 640 any of the metadata associated with certificates in that repository. 641 (Recall that the processing described here is creating a copy of that 642 local repository.) For simplicity the remainder of this document 643 assumes that the proofreading algorithm produces a transformed output 644 file. This file contains the same syntactic information as the text 645 version of the constraints file. 647 The proofreading algorithm performs the following syntactic checks on 648 the constraints file: 649 - verifies the presence of the REQUIRED relying party subsection 650 and the REQUIRED blocks subsection. 651 - verifies the order of the two, three or four subsections as 652 stated above. 653 - verifies that the relying party subsection conforms to the 654 specification given in Section 3.1 above. 655 - verifies that, if present, the tags and flags subsections conform 656 to the specifications in Sections 3.2 and 3.3 above. 658 After these checks have been performed, the proofreading algorithm 659 then checks the blocks subsection: 660 - splits the blocks subsection into constituent target blocks, as 661 delimited by the SKI region line(s) 662 - verifies that at least one target block is present 663 - verifies that each SKI region line contains exactly forty hexadecimal 664 digits and contains no additional characters other than whitespace or 665 colon characters. 667 For each target the proofreading algorithm: 669 - verifies the presence of the IPv4, IPv6 and AS# regions, and 670 verifies that at least one such resource is present. 671 - verifies that, for each IPv4 prefix, IPv6 prefix and autonomous 672 system number given, that the indicated resource is syntactically 673 valid according to the appropriate RFC definition, as described in 674 Section 3.4. 675 - verifies that no IPv4 resource has a prefix larger than /8. 676 - optionally performing reordering within each of the three resource 677 regions so that stated resources occur in ascending numerical order. 679 (If the proofreading algorithm has performed any reordering of 680 information it MAY overwrite the constraints file. If it does so, 681 however, it MUST preserve all information contained within the file, 682 including information that is not parsed (such as comments). If the 683 proofreading algorithm has performed any reordering of information 684 but has not overwritten the constraints file, it MAY produce a 685 transformed output file, as described above. If the proofreading 686 algorithm has performed any reordering of information, but has 687 neither overwritten the constraints file nor produced a transformed 688 output file, it MUST provide an error message to the user indicating 689 what reordering was performed.) 691 4.2 TA processing algorithm 693 The TA processing algorithm acts on the constraints file (as processed 694 by the proofreading algorithm) and the contents of the local RPKI 695 repository to produce paracertificates for the purpose of enforcing 696 the resource allocations as expressed in the constraints file. The 697 TA processing algorithm operates in five stages, a preparatory stage 698 (stage 0), target processing (stage 1), ancestor processing (stage 2), 699 tree processing (state 3) and TA re-parenting (stage 4). Conceptually, 700 during the preparatory stage the proofreader output file is read and a 701 set of internal RP, tag and flag variables are set based on the contents 702 of that file. (If the constraint file has not specified one or more of 703 the tags and/or flags, those tags and flags are set to default 704 values.) During target processing all certificates specified by a 705 target block are processed, and the resources for those certificates 706 are (potentially) expanded; for each target found a new 707 paracertificate is manufactured with its various fields set, as shown 708 in Table 1, using the values of the internal variables set in the 709 preparatory stage and also, of course, the fields of the original 710 certificate (and, potentially, fields of the RP's TA certificate). In 711 stage 2 (ancestor) processing, all ancestors of the each target 712 certificate are found, and the claimed resources are then removed 713 (perforated). A new paracertificate with these diminished resources 714 is crafted, with its fields generated based on internal variable 715 settings, original certificate field values, and, potentially, the 716 fields of the RP's TA certificate. In tree processing (stage 3), the 717 entire local RPKI repository is searching for any other certificates 718 that have resources that intersect a target resource, and that were 719 not otherwise processed during a preceding stage. Perforation is 720 again performed for any such intersecting certificates, and 721 paracertificates created as in stage 2. In the fourth (last) stage, 722 TA re-parenting, any TA certificates in the local RPKI 723 repository that have not already been processed are now re-parented 724 under the RP's TA certificate. This transformation creates 725 paracertificates; however, these paracertificates may have RFC 3779 726 resources that were not altered during algorithm processing. The 727 final output of algorithm processing will be threefold: 728 - the metadata information on some (original) certificates in the 729 repository MAY be altered. 730 - paracertificates will be created, with the appropriate metadata, 731 and entered into the repository. 732 - the TA processing algorithm SHOULD produce a human readable 733 log of its actions, indicating which paracertificates were created 734 and why. The remainder of this section describes the processing 735 stages of the algorithm in detail. 737 4.2.1 Preparatory processing (stage 0) 739 During preparatory processing, the output of the proofreader 740 algorithm, is read. Internal variables are set corresponding to each tag 741 and flag, if present, or to their defaults, if absent. Internal variables 742 are set corresponding to the PRIVATEKEYMETHOD value string(s) and the 743 TACERTIFICATE string. The TA processing algorithm is queried to 744 determine if it supports the indicated private key access 745 methodology. This query is performed in an implementation-specific 746 manner. In particular, an implementation is free to vacuously return 747 success to this query. The TA processing algorithm next uses the 748 value string for the TACERTIFICATE to locate this certificate, 749 again in an implementation-specific manner. The certificate in 750 question may already be present in the local RPKI repository, or it 751 may be located elsewhere. The implementation is free to create the 752 top level certificate at this time, and then assign to this 753 newly-created certificate the name indicated. It is necessary only 754 that, at the conclusion of this processing, a valid trust anchor 755 certificate for the relying party has been created or otherwise 756 obtained. 758 Some form of access to the RP's private key and top level certificate 759 are required for subsequent correct operation of the algorithm. 760 Therefore, stage 0 processing MUST terminate if one or both 761 conditions are not satisfied. In the error case, the implementation 762 SHOULD provide an error message of sufficient detail that the user 763 can correct the error(s). If stage 0 processing does not succeed, no 764 further stages of TA processing are executed. 766 4.2.2 Target processing (stage 1) 768 During target processing, the TA processing algorithm reads all 769 target blocks in the proofreader output file. It then processes each 770 target block in the order specified in the file. In the description 771 that follows, except where noted, the operation of the algorithm on 772 a single target block will be described. Note, however, that all 773 stage 1 processing is executed before any processing in subsequent 774 stages is performed. 776 The algorithm first obtains the SKI region of the target block. It 777 then locates (in an implementation-dependent manner) the certificate 778 identified by the SKI. Note that this search is performed only 779 against (original) certificates, not against paracertificates. 780 If more than one original certificate is found matching this SKI, 781 there are two possible scenarios. If a resource holder has two 782 certificates issued by the same CA, with overlapping validity 783 intervals and the same key, but distinct subject names (typically, 784 by virtue of the SerialNumber parts being different), then these 785 two certificates are both considered to be (distinct) targets, and 786 are both processed. If, however, a resource holder has certificates 787 issued by two different CAs, containing different resources, but 788 using the same key, there is no unambiguous method to decide which 789 of the certificates is intended as the target. In this latter case 790 the algorithm MUST issue a warning to that effect, mark the target 791 block in question as unavailable for processing by subsequent stages 792 and proceed to the next target block. If no certificate is found 793 then the algorithm SHOULD issue a warning to that effect and proceed 794 to process the next target block. 796 If a single (original) certificate is found matching the indicated SKI, 797 then the algorithm takes the following actions. First, it sets the 798 ORIGINAL state bit for the certificate found. Second, it sets the 799 TARGET state bit for the certificate found. Third, it extracts the 800 INRs from the certificate. If the global resource_nounion flag is TRUE, 801 the algorithm compares the extracted certificate INRs with the INRs 802 specified in the constraints file. If the two resource sets are 803 different, the algorithm SHOULD issue a warning noting the difference. 804 An output resource set is then formed that is identical to the resource 805 set extracted from the certificate. If, however, the resource_nounion 806 flag is FALSE, then the output resource set is calculated by forming 807 the union of the resources extracted from the certificate and the 808 resources specified for this target block in the constraints file. A 809 paracertificate is then constructed according to Table 1, using fields 810 from the original certificate, the tags that had been set during 811 stage 0, and, if necessary, fields from the RP's TA certificate. The 812 INR resources of the paracertificate are equated to the derived output 813 resource set. The PARA state bit is set for the newly created 814 paracertificate. 816 4.2.3 Ancestor processing (stage 2) 818 The goal of ancestor processing is to discover all ancestors of a 819 target certificate and remove from those ancestors the resources 820 specified in the target blocks corresponding to the targets being 821 processed. Note that it is possible that, for a given chain from a 822 target certificate to a trust anchor, another target might be 823 encountered. This is handled by removing all the target resources of 824 all descendants. The set of all targets that are descendants of the 825 given certificate is formed. The union of all the target resources of 826 the corresponding target blocks is computed, and this union in then 827 removed from the shared ancestor. 829 In detail, the algorithm is as follows. First, all (original) target 830 certificates processed during stage 1 processing are collected. 831 Second, any collected certificates that have the NOCHAIN state bit set 832 are eliminated from the collection. (Note that, as a result of 833 eliminating such certificates, the resulting collection may be empty, 834 in which case this stage of algorithm processing terminates, and 835 processing advances to stage 3.) Next, an implementation MAY sort the 836 collection. The optional sorting algorithm is described in Appendix 837 B. Note that all stage 2 processing is completed before any stage 3 838 processing. 840 Two levels of nested iteration are performed. The outer iteration is 841 effected over all certificates in the collection; the inner iteration 842 is over all ancestors of the designated certificate being processed. 843 The first certificate in the collection is chosen, and a resource set 844 R is initialized based on the resources of the target block for that 845 certificate (since the certificate is in the collection, it must be a 846 target certificate, and thus correspond to a target block). The 847 parent of the certificate is then located using ordinary path 848 discovery over original certificates only. The ancestor's certificate 849 resources A are then extracted. These resources are then perforated 850 with respect to R. That is, an output set of resources is created by 851 forming the intersection I of A and R, and then taking the set 852 difference A - I as the output resources. A paracertificate is then 853 created containing resources that are these output resources, and 854 containing other fields and extensions from the original certificate 855 (and possibly the RP's TA certificate) according to the procedure 856 given in Table 1. The PARA state bit is set on this paracertificate 857 and the ORIGINAL state bit is set on A. If A is also a target 858 certificate, as indicated by its TARGET state bit being set, then 859 there will already have been a paracertificate created for it. This 860 previous paracertificate is destroyed in favor of the newly created 861 paracertificate. In this case also, the set R is augmented by adding 862 into it the set of resources of the target block for A. The algorithm 863 then proceeds to process the parent of A. This inner iteration 864 continues until the self-signed certificate at the root of the path 865 is encountered and processed. The outer iteration then continues by 866 clearing R and proceeding to the next certificate in the target 867 collection. 869 Note that ancestor processing has the potential for order dependency, 870 as mentioned earlier in this document. If sorting is not implemented, 871 or if the sorting algorithm fails to completely process the 872 collection of target certificates because the allotted maximum number 873 of iterations has been realized, it may be the case that an ancestor 874 of a certificate logically occurs before that certificate in the 875 collection. Whenever an existing paracertificate is replaced by a 876 newly created paracertificate during ancestor processing, the 877 algorithm SHOULD alert the user, and SHOULD log sufficient detail 878 such that the user is able to determine which resources were 879 perforated from the original certificate in order to create the (new) 880 paracertificate. 882 In addition, implementations MUST provide for conflict detection and 883 notification during ancestor processing. During ancestor processing 884 a certificate may be encountered two or more times and the 885 modifications dictated by the ancestor processing algorithm may be 886 in conflict. If this situation arises the algorithm MUST refrain 887 from processing that certificate. Further, the implementation MUST 888 present the user with an error message that contains enough detail 889 so that the user can locate those directives in the constraints file 890 that are creating the conflict. For example, during one stage of the 891 processing algorithm it may be directed that resources R1 be added to 892 a certificate C, while during a different stage of the processing 893 algorithm it may be directed that resources R2 be removed from 894 certificate C. If the resource sets R1 and R2 have a non-empty 895 intersection, that is a conflict. 897 4.2.4 Tree processing (stage 3) 899 The goal of tree processing is to locate other certificates 900 containing INRs that conflict with the resources allocated to a 901 target, by virtue of the INRs specified in the constraints file. 902 The certificates processed are not ancestors of any target. The 903 algorithm used is described below. 905 First, all target certificates are collected. Second, all target 906 certificates that have the NOCHAIN state bit set are eliminated 907 from this collection. Third, if the intersection_always 908 global flag is set, target blocks that occur in the constraints 909 file, but that did not correspond to a certificate in the local 910 repository, are added to the collection. In tree processing, 911 unlike ancestor processing, this collection is not sorted. An 912 iteration is now performed over each certificate (or set of target 913 block resources) in the collection. Note that the collection may be 914 empty, in which case this stage of algorithm processing terminates, 915 and processing advances to stage 4. Note also that all stage 3 916 processing is performed before any stage 4 processing. 918 Given a certificate or target resource block, each top level original 919 TA certificate is examined. If that TA certificate has an 920 intersection with the target block resources, then the certificate is 921 perforated with respect to those resources. A paracertificate is 922 created based on the contents of the original certificate (and 923 possibly the RP's TA certificate, as indicated in Table 1) using the 924 perforated resources. The ORIGINAL state bit is set on the original 925 certificate processed in this manner, and the PARA state bit is set 926 on the paracertificate just created. An inner iteration then begins 927 on the descendants of the original certificate just processed. There 928 are two ways in which this iteration may proceed. If the treegrowth 929 global flag is clear, then examination of the children proceeds until 930 all children are exhausted, or until one child is found with 931 intersecting resources. If the treegrowth global flag is set, all 932 children are examined. If a transfer of resources is in process, 933 more than one child may possess intersecting resources. In this case, 934 it is RECOMMENDED that the treegrowth flag be set. The inner iteration 935 proceeds until all descendants have been examined and no further 936 intersecting resources are found. The outer iteration then continues 937 with the next certificate or target resource block in the collection. 938 Note that unlike ancestor processing, there is no concept of a 939 potentially cumulating resource collection R; only the resources 940 in the target block are used for perforation. 942 4.2.5 TA re-parenting (stage 4) 944 In the final stage of TA algorithm processing, all TA certificates 945 (other than the RP's TA certificate) that have not already been 946 processed are now processed. At this stage all unprocessed TA 947 certificates have no intersection with any target resource blocks. 948 As such, in creating the corresponding paracertificates, the output 949 resource set is identical to the input resource set. Other 950 transformations as described in Table 1 are performed. The original 951 TA certificates have the ORIGINAL state bit set; the newly created 952 paracertificates have the PARA state bit set. Note that once stage 953 four processing is completely, only a single TA certificate will 954 remain in an unprocessed state, namely the relying party's own 955 TA certificate. 957 4.3 Discussion 959 The algorithm described in this document effectively creates two 960 coexisting certificate hierarchies: the original certificate 961 hierarchy and the paracertificate hierarchy. Original 962 certificates are not removed during any of the processing described 963 in the previous section. Some original certificates may move from 964 having no state bits set (or only the NOCHAIN state bit set) to 965 having one or both of the ORIGINAL and TARGET state bits set. In 966 addition, the NOCHAIN state bit will still be set if it was set 967 before any processing. The paracertificate hierarchy, however, is 968 intended to supersede the original hierarchy for ROA validation. 969 The presence of two hierarchies has implications for path 970 discovery, and for revocation. 972 If one thinks of a certificate as being "named" by its SKI, then 973 there can now be two certificates with the same name, an original 974 certificate and a paracertificate. The next two sections discuss the 975 implications of this duality in detail. Before proceeding, it is 976 worth noting that even without the existence of the paracertificate 977 hierarchy, cases may exist in which two or more original 978 certificates have the same SKI. As noted earlier, in Section 979 4.2.2, these cases may be subdivided into the case in which such 980 certificates are distinguishable by virtue of having different 981 subject names, but identical issuers and resource sets, versus all 982 other cases. In the distinguishable case, the path discovery 983 algorithm treats the original certificates as separate certificates, 984 and processes them separately. In all other cases, the original 985 certificates should be treated as indistinguishable, and path 986 validation should fail. 988 5 Implications for Path Discovery 990 Path discovery proceeds from a child certificate C by asking for a 991 parent certificate P such that the AKI of C is equal to the SKI of P. 992 With one hierarchy this question would produce at most one answer. 993 With two hierarchies, the original certificate hierarchy and the 994 paracertificate hierarchy, the question may produce two answers, one 995 answer, or no answer. Each of these cases is considered in turn. 997 5.1 Two answers 999 If two paths are discovered, it SHOULD be the case that one of the 1000 matches is a certificate with the ORIGINAL state bit set and the 1001 PARA state bit clear, while the other match inversely has the 1002 ORIGINAL state bit clear and the PARA state bit set. If any other 1003 combination of ORIGINAL and PARA state bits obtains, the path 1004 discovery algorithm MUST alert the user. In addition, the path 1005 discovery algorithm SHOULD refrain from attempting to make a 1006 choice as to which of the two certificates is the putative parent. In 1007 the no-error case, with the state bits are as indicated, the 1008 certificate with the PARA state bit set is chosen as the parent P. 1009 Note this means, in effect, that all children of the original 1010 certificate have been re-parented under the paracertificate. 1012 5.2 One answer 1014 If the matching certificate has neither the ORIGINAL state bit set 1015 nor the PARA state bit set, this certificate is the parent. If the 1016 matching certificate has the PARA state bit set but the ORIGINAL 1017 state bit not set, this certificate is the parent. (This situation 1018 would arise, for example, if the original certificate had been 1019 revoked by its issuer but the paracertificate had not been revoked by 1020 the RP.) If the matching certificate has the ORIGINAL state bit set 1021 but the PARA state bit not set, this is not an error but it is a 1022 situation in which path discovery MUST be forced to fail. The parent 1023 P MUST be set to NULL, and the NOCHAIN state bit must be set on C and 1024 all its descendants; the user SHOULD be warned. Even if the RP has 1025 revoked the paracertificate, the original certificate MAY persist. 1026 Forcing path discovery to unsuccessfully terminate is a reflection of 1027 the RP's preference for path discovery to fail as opposed to using 1028 the original hierarchy. Finally, if the matching certificate has both 1029 the ORIGINAL and PARA state bits set, this is an error. The parent P 1030 MUST be set to NULL, and the user MUST be warned. 1032 5.3 No answer 1034 This situation occurs when C has no parent in either the original 1035 hierarchy or the paracertificate hierarchy. In this case the parent P 1036 is NULL and path discovery terminates unsuccessfully. The NOCHAIN 1037 state bit must be set on C and all its descendants. 1039 6 Implications for Revocation 1041 In a standard implementation of revocation in a PKI, a valid CRL 1042 names a (sibling) certificate by serial number. That certificate is 1043 revoked and is purged from the local RPKI repository. The original 1044 certificate hierarchy and the paracertificate hierarchy created by 1045 applying the algorithms described above are closely related. It 1046 can thus be asked how revocation is handled in the presence of these 1047 two hierarchies. In particular do changes in one of the hierarchies 1048 trigger corresponding changes in the other hierarchy. There are four 1049 cases based on the state of the ORIGINAL and PARA bits. These are 1050 discussed in the subsections below. It should be noted that the 1051 existence of two hierarchies presents a particular challenge with 1052 respect to revocation. If a CRL arrives and is processed, that 1053 processing can result in the descrution of one of the path chains. 1054 In the case of a single hierarchy this would mean that certain objects 1055 would fail to validate. In the presence of two hierarchies, however, 1056 a CRL revocation may force the preferred path to be destroyed. If 1057 the RP later determines that the CRL revocation should not have 1058 occurred, he is faced with an undesirable situation: the deprecated 1059 path will be discovered. In order to prevent this outcome, an RP 1060 MUST be able to configure one or more additional repository URIs 1061 in support of local trust anchor management. 1063 6.1 No state bits set 1065 If the CRL names a certificate that has neither the ORIGINAL state 1066 bit set nor the PARA state bit set, revocation proceeds normally. All 1067 children of the revoked certificate have their state modified so that 1068 the NOCHAIN state bit is set. 1070 6.2 ORIGINAL state bit set 1072 If the CRL names a certificate with the ORIGINAL state bit set and 1073 the PARA state bit clear, then this certificate is revoked as usual. 1074 If this original certificate also has the TARGET state bit set, then 1075 the corresponding paracertificate (if it exists) is not revoked; if 1076 this original certificate has the TARGET state bit clear, then the 1077 corresponding paracertificate is revoked as well. Note that since all 1078 the children of the original certificate have been re-parented to be 1079 children of the corresponding paracertificate, as described above, 1080 the revocation algorithm MUST NOT set the NOCHAIN state bit on these 1081 children unless the paracertificate is also revoked. Note also that 1082 if the original certificate is revoked but the paracertificate is not 1083 revoked, the paracertificate retains its PARA state bit. This is to 1084 ensure that path discovery proceeds preferentially through the 1085 paracertificate hierarchy, as described above. 1087 6.3 PARA state bit set 1089 If the CRL names a certificate with the PARA state bit set and the 1090 ORIGINAL state bit clear, this CRL must have been issued, perforce, 1091 by the RP itself. This is because all the paracertificates are 1092 children of the RP's TA certificate. (Recall that a TA is not revoked 1093 via a CRL; it is merely removed from the repository.) The 1094 paracertificate is revoked and all children of the paracertificate 1095 have the NOCHAIN state bit set. No action is taken on the 1096 corresponding original certificate; in particular, its ORIGINAL state 1097 bit is not cleared. 1099 Note that the serial numbers of paracertificates are synthesized 1100 according to the procedure given in Table 1, rather than being 1101 assigned by an algorithm under the control of the (original) issuer. 1103 6.4 Both ORIGINAL and PARA state bits set 1105 This is an error. The revocation algorithm MUST alert the user and 1106 take no further action. 1108 ' 1109 7 Security Considerations 1111 The goal of the algorithm described in this document is to enable an 1112 RP to impose its own view of the RPKI, which is intrinsically a 1113 ecurity function. An RP using a constraints file is trusting the 1114 assertions made in that file. Errors in the constraints file used 1115 by an RP can undermine the security offered by the RPKI, to that RP. 1116 In particular, since the paracertificate hierarchy is intended to 1117 trump the original certificate hierarchy for the purposes of path 1118 discovery, an improperly constructed paracertificate hierarchy could 1119 validate ROAs that would otherwise be invalid. It could also 1120 declare as invalid ROAs that would otherwise be valid. As a result, 1121 an RP must carefully consider the security implications of the 1122 constraints file being used, especially if the file is provided by 1123 a third party. 1125 8 IANA Considerations 1127 [Note to IANA, to be removed prior to publication: there are no IANA 1128 considerations stated in this version of the document.] 1130 9 Acknowledgements 1132 The authors would like to acknowledge the significant contributions 1133 of Charles Gardiner, who was the original author of an internal 1134 version of this document, and who contributed significantly to its 1135 evolution into the current version. 1137 10 References 1139 10.1 Normative References 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, March 1997. 1144 [RFC3513] Hinden, R., and S. Deering, "Internet Protocol Version 6 1145 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1147 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1148 Addresses and AS Identifiers", RFC 3779, June 2004. 1150 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1151 Housley, R., and W. Polk, "Internet X.509 Public Key 1152 Infrastructure Certificate and Certificate Revocation 1153 List (CRL) Profile", RFC 5280, May 2008. 1155 [RFC5396] Huston, G., and G. Michaelson, "Textual Representation of 1156 Autonomous System (AS) Numbers", RFC 5396, December 2008. 1158 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1159 Secure Internet Routing", RFC 6480, February 2012. 1161 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile 1162 for Resource Certificate Policy Structure", RFC 6481, 1163 Feburary 2012. 1165 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile 1166 for X.509 PKIX Resource Certificates", RFC 6487, February 1167 2012. 1169 10.2 Informative References 1171 None. 1173 Authors' Addresses 1175 Stephen Kent 1176 Raytheon BBN Technologies 1177 10 Moulton St. 1178 Cambridge, MA 02138 1180 Email: kent@bbn.com 1182 Matthew Lepinski 1183 Raytheon BBN Technologies 1184 10 Moulton St. 1185 Cambridge, MA 02138 1187 Email: mlepinsk@bbn.com 1189 Mark C. Reynolds 1190 Island Peak Software 1191 328 Virginia Road 1192 Concord, MA 01742 1194 Email: mcr@islandpeaksoftware.com 1196 Appendix A: Sample Constraints File 1198 ; 1199 ; Sample constraints file for TBO LTA Test Corporation. 1200 ; 1201 ; TBO manages its own local (10.x.x.x) address space 1202 ; via the target blocks in this file. 1203 ; 1205 ; 1206 ; Relying party subsection. TBO uses ssh-agent as 1207 ; a software cryptographic agent. 1208 ; 1210 PRIVATEKEYMETHOD OBO(ssh-agent) 1211 TACERTIFICATE tbomaster.cer 1213 ; 1214 ; Flags subsection 1215 ; 1216 ; Always use the resources in this file to augment 1217 ; certificate resources. 1218 ; Always process resource conflicts in the tree, even 1219 ; if the target certificate is missing. 1220 ; Always search the entire tree. 1221 ; 1223 CONTROL resource_nounion FALSE 1224 CONTROL intersection_always TRUE 1225 CONTROL treegrowth TRUE 1227 ; 1228 ; Tags subsection 1229 ; 1230 ; Copy the original cert's validity dates. 1231 ; Use the default policy OID. 1232 ; Use our own CRLDP. 1233 ; Use our own AIA. 1234 ; 1236 TAG Xvalidity_dates C 1237 TAG Xcp D 1238 TAG Xcrldp rsync://tbo_lta_test.com/pub/CRLs 1239 TAG Xaia rsync://tbo_lta_test.com/pub/repos 1241 ; 1242 ; Block subsection 1243 ; 1244 ; 1245 ; First block: TBO Corporate 1246 ; 1248 ; Resource Holder: TBO Corporation 1250 SKI 00112233445566778899998877665544332211 1251 IPv4 1252 10.2.3/24 1253 10.8/16 1254 IPv6 1255 2001:db8::/32 1256 AS# 1257 60123 1258 5507 1260 ; 1261 ; Second block: TBO LTA Test Enforcement Division 1262 ; 1264 ; Resource Holder: TBO Corporation 1266 SKI 653420AF758421CF600029FF857422AA6833299F 1267 IPv4 1268 10.2.8/24 1269 10.47/16 1270 IPv6 1271 AS# 1272 60124 1274 ; 1275 ; Third block: TBO LTA Test Acceptance Corporation 1276 ; Quality financial services since sometime 1277 ; late yesterday. 1278 ; 1280 ; Resource Holder: TBO Acceptance Corporation 1282 SKI 19:82:34:90:8b:a0:9c:ef:00:af:a0:98:23:09:82:4b:ef:ab:98:09 1283 IPv4 1284 10.3.3/24 1285 IPv6 1286 AS# 1287 60125 1289 ; End of TBO constraints file 1291 Appendix B: Optional Sorting Algorithm for Ancestor Processing 1293 Sorting is performed in an effort to eliminate any order dependencies 1294 in ancestor processing, as described in section 4.2.3 of this 1295 document. The sorting algorithm does this by rearranging the 1296 processing of certificates such that if A is an ancestor of B, B is 1297 processed before A. The sorting algorithm is an OPTIONAL part of 1298 ancestor processing. Sorting proceeds as follows. The collection 1299 created at the beginning of ancestor processing is traversed and any 1300 certificate in the collection that is visited as a result of path 1301 discovery is temporarily marked. After the traversal, all unmarked 1302 certificates are moved to the beginning of the collection. The 1303 remaining marked certificates are unmarked, and a traversal again 1304 performed through this sub-collection of previously marked 1305 certificates. The sorting algorithm proceeds iteratively until all 1306 certificates have been sorted or until a predetermined fixed number 1307 of iterations has been performed. (Eight is suggested as a munificent 1308 value for the upper bound, since the number of sorting steps need not 1309 be any greater than the maximum depth of the tree.) Finally, the 1310 ancestor processing algorithm is applied in turn to each certificate 1311 in the remaining sorted collection. If the sorting algorithm fails to 1312 converge, that is if the maximum number of iterations has been 1313 reached and unsorted certificates remain, the implementation SHOULD 1314 warn the user.