idnits 2.17.1 draft-ietf-sidr-ltamgmt-05.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 == Line 257 has weird spacing: '...ntifier unc...' == Line 260 has weird spacing: '... points repl...' == Line 333 has weird spacing: '...lagname boole...' == Line 363 has weird spacing: '...tagname tagva...' -- The document date (June 4, 2012) is 4342 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: 'I-D.sidr-arch' is mentioned on line 123, but not defined == Missing Reference: 'I-D.sidr-res-cert-prof' is mentioned on line 127, but not defined == Missing Reference: 'ID.sidr-res-cert-prof' is mentioned on line 457, but not defined == Unused Reference: 'RFC2119' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'RFC5396' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: 'RFC6480' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'RFC6481' is defined on line 1112, but no explicit reference was found in the text == Unused Reference: 'RFC6487' is defined on line 1116, 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: 2 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: December 6, 2012 BBN 6 M. Lepinski 7 BBN 8 June 4, 2012 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 December 6, 2012. 36 Copyright and License Notice 38 Copyright (c) 2012 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 to allow an RP to import TA 56 material in the form of self-signed certificates. The facility 57 described in this document allows an RP to impose constraints on such 58 TAs. Because this mechanism is designed to operate in the RPKI 59 context, the relevant constraints are the RFC 3779 extensions that 60 bind address spaces and/or autonomous system (AS) numbers to 61 entities. The primary motivation for this facility is to enable an RP 62 to ensure that resource allocation information that it has acquired 63 via some trusted channel is not overridden by the information 64 acquired from the RPKI repository system or by the putative TAs that 65 the RP imports. Specifically, the mechanism allows an RP to specify a 66 set of bindings between public key identifiers and RFC 3779 extension 67 data and will override any conflicting bindings expressed via the 68 putative TAs and the certificates downloaded from the RPKI repository 69 system. Although this mechanism is designed for local use by an RP, 70 an entity that is accorded administrative control over a set of RPs 71 may use this mechanism to convey its view of the RPKI to a set of RPs 72 within its jurisdiction. The means by which this latter use case is 73 effected is outside the scope of this document. 75 Table of Contents 77 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2 Overview of Certificate Processing . . . . . . . . . . . . . . 5 80 2.1 Target Certificate Processing . . . . . . . . . . . . . . . 5 81 2.2 Perforation . . . . . . . . . . . . . . . . . . . . . . . . 5 82 2.3 TA Re-parenting . . . . . . . . . . . . . . . . . . . . . . 6 83 2.4 Paracertificates . . . . . . . . . . . . . . . . . . . . . 6 84 3 Format of the constraints file . . . . . . . . . . . . . . . . 8 85 3.1 Relying party subsection . . . . . . . . . . . . . . . . . 8 86 3.2 Flags subsection . . . . . . . . . . . . . . . . . . . . . 8 87 3.3 Tags subsection . . . . . . . . . . . . . . . . . . . . . . 9 88 3.3.1 Xvalidity_dates tag . . . . . . . . . . . . . . . . . . 10 89 3.3.2 Xcrldp tag . . . . . . . . . . . . . . . . . . . . . . 10 90 3.3.3 Xcp tag . . . . . . . . . . . . . . . . . . . . . . . . 11 91 3.3.4 Xaia tag . . . . . . . . . . . . . . . . . . . . . . . 11 92 3.4 Blocks subsection . . . . . . . . . . . . . . . . . . . . . 12 93 4 Certificate Processing Algorithm . . . . . . . . . . . . . . . 13 94 4.1 Proofreading algorithm . . . . . . . . . . . . . . . . . . 14 95 4.2 TA processing algorithm . . . . . . . . . . . . . . . . . . 15 96 4.2.1 Preparatory processing (stage 0) . . . . . . . . . . . 16 97 4.2.2 Target processing (stage 1) . . . . . . . . . . . . . . 17 98 4.2.3 Ancestor processing (stage 2) . . . . . . . . . . . . . 18 99 4.2.4 Tree processing (stage 3) . . . . . . . . . . . . . . . 19 100 4.2.5 TA re-parenting (stage 4) . . . . . . . . . . . . . . . 20 101 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21 102 5 Implications for Path Discovery . . . . . . . . . . . . . . . . 21 103 5.1 Two answers . . . . . . . . . . . . . . . . . . . . . . . . 21 104 5.2 One answer . . . . . . . . . . . . . . . . . . . . . . . . 22 105 5.3 No answer . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 6 Implications for Revocation . . . . . . . . . . . . . . . . . . 22 107 6.1 No state bits set . . . . . . . . . . . . . . . . . . . . . 23 108 6.2 ORIGINAL state bit set . . . . . . . . . . . . . . . . . . 23 109 6.3 PARA state bit set . . . . . . . . . . . . . . . . . . . . 23 110 6.4 Both ORIGINAL and PARA state bits set . . . . . . . . . . . 24 111 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 24 112 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 113 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 114 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 115 10.1 Normative References . . . . . . . . . . . . . . . . . . . 24 116 10.2 Informative References . . . . . . . . . . . . . . . . . . 25 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 118 Appendix A: Sample Constraints File . . . . . . . . . . . . . . . 26 119 Appendix B: Optional Sorting Algorithm for Ancestor Processing . . 27 121 1 Introduction 123 The Resource Public Key Infrastructure (RPKI) [I-D.sidr-arch] is a 124 PKI in which certificates are issued to facilitate management of IP 125 addresses and autonomous system number resources. Such resources are 126 expressed in the form of X.509v3 "resource" certificates with 127 extensions as defined by RFC 3779 [I-D.sidr-res-cert-prof]. 128 Validation of a resource certificate is preceded by path discovery. 129 Path discovery is effected by constructing a certificate path 130 (upward) from a target certificate to a trust anchor. Path validation 131 proceeds from the TA in question to the target certificate, using the 132 public key from each certificate along the path to verify the 133 signature of its subordinate certificate. In the RPKI it is 134 anticipated that one or more putative TAs, aligned with the resource 135 allocation hierarchy, will be available in the form of self-signed 136 certificates configured by an RP. There are circumstances under which 137 an RP may wish to override the resource specifications obtained 138 through the RPKI distributed repository system [I-D.sidr-repos- 139 struct]. This document describes a mechanism by which an RP may 140 override any conflicting information expressed via the putative TAs 141 and the certificates downloaded from the RPKI repository system. 143 To effect this local control, this document calls for a relying party 144 to specify a set of bindings between public key identifiers and 145 resources (IP resources and/or AS number resources) through a text 146 file known as a constraints file. The constraints expressed in this 147 file then take precedence over any competing claims expressed by 148 resource certificates acquired from the distributed repository 149 system. (The means by which a relying party acquires the key 150 identifier and the RFC 3779 extension data used to populate the 151 constraints file is outside the scope of this document.) The relying 152 party also may use a local publication point (the root of a local 153 directory tree that is made available as if it were a remote 154 repository) as a source of certificates and CRLs (and other RPKI 155 signed objects, e.g. ROAs and manifests) that do not appear in the 156 RPKI repository system. 158 In order to allow reuse of existing, standard path validation 159 mechanisms, the RP-imposed constraints are realized by having the RP 160 itself represented as the only TA known in the local certificate 161 validation context. To ensure that all RPKI certificates can be 162 validated relative to this TA, this RP TA certificate must contain 163 all-encompassing resource allocations, i.e. 0/0 for IPv4, 0::/0 for 164 IPv6 and 0-4294967295 for AS numbers. Thus, a conforming 165 implementation of this mechanism must be able to cause a self-signed 166 certification authority (CA) certificate to be created with a locally 167 generated key pair. It also must be able to issue CA certificates 168 subordinate to this TA. Finally, a conforming implementation of this 169 mechanism must process the constraints file and modify certificates 170 as needed in order to enforce the constraints asserted in the file. 172 The remainder of this document describes in detail the types of 173 certificate modification that may occur, the semantics of the 174 constraints file, and the implications of certificate modification on 175 path discovery and revocation. 177 1.1 Terminology 179 It is assumed that the reader is familiar with the terms and concepts 180 described in "Internet X.509 Public Key Infrastructure Certificate 181 and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 182 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119. 188 2 Overview of Certificate Processing 190 The fundamental aspect of the facility described in this document is 191 one of certificate modification. The constraints file, described in 192 more detail in the next section, contains assertions about resources 193 that are to be specially processed. As a result of this processing, 194 certificates in the local copy of the RPKI repository are transformed 195 into new certificates satisfying the resource constraints so 196 specified. This enables the RP to override conflicting assertions 197 about resource holdings as acquired from the RPKI repository system. 198 Three forms of certificate modification can occur. 200 2.1 Target Certificate Processing 202 If a certificate is acquired from the RPKI repository system and its 203 SKI is listed in the constraints file, it will be reissued directly 204 under the RP TA certificate, with (possibly) modified RFC 3779 205 extensions. The modified extensions will include any RFC 3779 data 206 expressed in the constraints file. In Section 4.2, target certificate 207 processing corresponds to stage one of the algorithm. 209 2.2 Perforation 211 Any certificate acquired from the RPKI repository that contains an 212 RFC 3779 extension that intersects the resource data in the 213 constraints file will be reissued directly under the RP TA, with 214 modified RFC 3779 extensions. We refer to the process of modifying 215 the RFC 3779 extension in an affected certificate as "perforation" 216 (because the process will create "holes" in these extensions). The 217 modified extensions will exclude any RFC 3779 data expressed in the 218 constraints file. In the certificate processing algorithm described 219 in Section 4.2, perforation corresponds to stage two of the algorithm 220 ("ancestor processing") and also to stage three of the algorithm 221 ("tree processing"). 223 2.3 TA Re-parenting 225 For consistency, all valid, self-signed certificates that would have 226 been regarded as TAs in the public RPKI certificate hierarchy, e.g. 227 self-signed certificates issued by IANA or the RIRs, will be re- 228 issued under the RP TA certificate. This processing is done even 229 though all but one of these certificates might not intersect any 230 resources specified in the constraints file. We refer to this 231 reissuance as "re-parenting" since the Issuer (parent) of the 232 certificate has been changed. In the certificate processing algorithm 233 described in Section 4.2, TA re-parenting corresponds to stage four 234 of the algorithm. 236 2.4 Paracertificates 238 If a certificate is subject to any of the three forms of processing 239 just described, that certificate will be referred to as an "original" 240 certificate and the processed (output) certificate will be referred 241 to as a paracertificate. When an original certificate is transformed 242 into a paracertificate all the fields and extensions from the 243 original certificate will be retained, except as indicated in Table 244 1, below. 246 Original Certificate Field Action 248 Version unchanged 249 Serial number created per note A 250 Signature replaced if needed 251 with RP's signing alg 252 Issuer replaced with RP's name 253 Validity dates replaced per note B 254 Subject unchanged 255 Subject public key info unchanged 256 Extensions 257 Subject key identifier unchanged 258 Key usage unchanged 259 Basic constraints unchanged 260 CRL distribution points replaced per note B 261 Certificate policy replaced per note B 262 Authority info access replaced per note B 263 Authority key ident replaced with RP's 264 IP address block modified as described 265 AS number block modified as described 266 Subject info access unchanged 267 All other extensions unchanged 268 Signature Algorithm same as above 269 Signature value new 271 Table 1 Certificate Field Modifications 273 Note A. The serial number will be created by concatenating the 274 current time (the number of seconds since Jan 1, 1970) with a count 275 of the certificates created in the current run. 277 Note B. These fields are derived (as described in section 3.3 below) 278 from parameters in the constraints file (if present); otherwise, they 279 take on values from the certificates from which the paracertificates 280 are derived. 282 3 Format of the constraints file 284 This section describes a general model for the syntax of the 285 constraints file. The model described below is nominal; 286 implementations need not match details of this model as presented, 287 but the external behavior of implementations MUST correspond to the 288 externally observable characteristics of this model in order to be 289 compliant. 291 The constraints file consists of four logical subsections: the 292 replying party subsection, the flags subsection, the tags subsection 293 and the blocks subsection. The relying party subsection and the 294 blocks subsection are REQUIRED and MUST be present; the flags and 295 tags subsections are OPTIONAL. Each subsection is described in more 296 detail below. Note that the semicolon (;) character acts as the 297 comment character, to enable annotating constraints files. All 298 characters from a semicolon to the end of that line are ignored. In 299 addition, lines consisting only of whitespace are ignored. The 300 subsections MUST occur in the order indicated. An example constraints 301 file is given in Appendix A. 303 3.1 Relying party subsection 305 The relying party subsection is a REQUIRED subsection of the 306 constraints file. It MUST be the first subsection of the constraints 307 file, and it MUST consist of two lines of the form: 309 PRIVATEKEYMETHOD value [ ... value ] 310 TOPLEVELCERTIFICATE value 312 The first line provides guidance to the certificate processing 313 algorithm on the method that will be used to gain access to the RP's 314 private key. This line consists of the string literal 315 PRIVATEKEYMETHOD, followed by one or more whitespace delimited string 316 values. These values are passed to the certificate processing 317 algorithm as described below. Note that this entry, as for all 318 entries in the constraints file, is case sensitive. 320 The second line of this subsection consists of the string literal 321 TOPLEVELCERTIFICATE, followed by exactly one string value. This value 322 is the name of a file containing the relying party's TA certificate. 323 The file name is passed to the certificate processing algorithm as 324 described below. 326 3.2 Flags subsection 328 The flags subsection of the constraints file is an OPTIONAL 329 subsection. If present it MUST immediately follow the relying party 330 subsection. The flags subsection consists of one or more lines of the 331 form 333 CONTROL flagname booleanvalue 335 Each such line is referred to as a control line. Each control line 336 MUST contain exactly three whitespace delimited strings. The first 337 string MUST be the literal CONTROL. The second string MUST be one of 338 the following three literals: 340 resource_nounion 341 intersection_always 342 treegrowth 344 The third string denotes a boolean value, and MUST be one of the 345 literals TRUE or FALSE. Control flags influence the global operation 346 of the certificate processing algorithm; the semantics of the flags 347 is described in detail in Section 4.2. Note that each flag has a 348 default value, so that if the corresponding CONTROL line does not 349 appear in the constraints file, the algorithm flag is considered to 350 take the corresponding default value. The default value for each flag 351 is FALSE. Thus, if any flag is not named in a control line it takes 352 the value FALSE. Further, if the flags subsection is absent, all 353 three flags take the value FALSE. 355 3.3 Tags subsection 357 The tags subsection is an OPTIONAL subsection in the constraints 358 file. If present it MUST immediately follow the relying party 359 subsection (if the flags subsection is absent) or the flags 360 subsection (if it is present). The tags subsection consists of one or 361 more lines of the form 363 TAG tagname tagvalue [ ... tagvalue ] 365 Each such line is referred to as a tag line. Each tag line MUST 366 consist of at least three whitespace delimited string values, the 367 first of which must be the literal TAG. The second string value gives 368 the name of the tag, and subsequent string(s) give the value(s) of 369 the tag. The tag name MUST be one of the following four string 370 literals: 372 Xvalidity_dates 373 Xcrldp 374 Xcp 375 Xaia 377 The purpose of the tag lines is to provide an indication of the means 378 by which paracertificate fields, specifically those indicated above 379 under "Note B", are constructed. Each tag has a default, so that if 380 the corresponding tag line is not present in the constraints file, 381 the default behavior is used when constructing the paracertificates. 382 The syntax and semantics of each tag line is described next. 384 Note that the tag lines are considered to be global; the action of 385 each tag line (or the default action, if that tag line is not 386 present) applies to all paracertificates that are created as part of 387 the certificate processing algorithm. 389 3.3.1 Xvalidity_dates tag 391 This tag line is used to control the value of the notBefore and 392 notAfter fields in paracertificates. If this tag line is specified 393 and there is a single tagvalue which is the literal string C, the 394 paracertificate validity interval is copied from the original 395 certificate validity interval from which it is derived. If this tag 396 is specified and there is a single tagvalue which is the literal 397 string R, the paracertificate validity interval is copied from the 398 validity interval of the relying party's top level (TA) certificate. 399 If this tag is specified and the tagvalue is neither of these 400 literals, then exactly two tagvalues MUST be specified. Each must be 401 a Generalized Time string of the form YYYYMMDDHHMMSSZ. The first 402 tagvalue is assigned to the notBefore field and the second tagvalue 403 is assigned to the notAfter field. It MUST be the case that the 404 tagvalues may be parsed as valid Generalized Time strings such that 405 notBefore is less than notAfter, and also such that notAfter 406 represents a time in the future (i.e., the paracertificate has not 407 already expired). 409 If this tag line is not present in the constraints file the default 410 behavior is to copy the validity interval from the original 411 certificate to the corresponding paracertificate. 413 3.3.2 Xcrldp tag 415 This tag line is used to control the value of the CRL distribution 416 point extension in paracertificates. If this tag line is specified 417 and there is a single tagvalue that is the string literal C, the 418 CRLDP of the paracertificate is copied from the CRLDP of the original 419 certificate from which it is derived. If this tag line is specified 420 and there is a single tagvalue that is the string literal R, the 421 CRLDP of the paracertificate is copied from the CRLDP of the RP's top 422 level certificate. If this tag line is specified and there is a 423 single tagvalue that is not one of these two reserved literals, or if 424 there is more than one tagvalue, then each tagvalue is interpreted as 425 a URI that will be placed in the CRLDP sequence in the 426 paracertificate. 428 If this tag line is not present in the constraints file the default 429 behavior is to copy the CRLDP from the original certificate into the 430 corresponding paracertificate. 432 3.3.3 Xcp tag 434 This tag line is used to control the value of the policyQualifierId 435 field in paracertificates. If this tag line is specified there MUST 436 be exactly one tagvalue. If the tagvalue is the string literal C, the 437 paracertificate value is copied from the value in the corresponding 438 original certificate. If the tagvalue is the string literal R, the 439 paracertificate value is copied from the value in the RP's top level 440 TA certificate. If the tagvalue is the string literal D, the 441 paracertificate value is set to the default OID. If the tagvalue is 442 not one of these reserved string literals, then the tagvalue MUST be 443 an OID specified using the standard dotted notation. The value in the 444 paracertificate's policyQualifierId field is set to this OID. Note 445 the RFC 5280 specifies that only a single policy may be specified in 446 a certificate, so only a single tagvalue is permitted in this tag 447 line, even though the CertificatePolicy field is an ASN.1 sequence. 449 If this tag line is not specified the default behavior is to use the 450 default OID in creating the paracertificate. 452 This option permits the RP to convert a value of the 453 policyQualifierId field in a certificate (that would not be in 454 conformance with the RPKI CP) to a conforming value in the 455 paracertificate. This conversion enables use of RPKI validation 456 software that checks the policy field against that specified in the 457 RPKI CP [ID.sidr-res-cert-prof]. 459 3.3.4 Xaia tag 461 This tag line is used to control the value of the Authority 462 Information Access (AIA) extension in the paracertificate. If this 463 tag line is present then it MUST have exactly one tagvalue. If this 464 tagvalue is the string literal C, then the AIA field in the 465 paracertificate is copied from the AIA field in the original 466 certificate from which it is derived. If this tag line is present and 467 the tagvalue is not the reserved string literal, then the tagvalue 468 MUST be a URI. This URI is set as the AIA extension of the 469 paracertificates that are created. 471 If this tag line is not specified the default behavior is to use copy 472 the AIA field from the original certificate to the AIA field of the 473 paracertificate. 475 3.4 Blocks subsection 477 The blocks subsection is a REQUIRED subsection of the constraints 478 file. If the tags subsection is present, the blocks subsection MUST 479 appear immediately after it. If the tags subsection is absent, but 480 the flags subsection is present, the block subsection MUST appear 481 immediately after it. Otherwise, the blocks subsection MUST appear 482 immediately after the relying party subsection. The blocks subsection 483 consists of one or more blocks, known as target blocks. A target 484 block is used to specify an association between a certificate (given 485 by a hash of its public key information) and a set of resource 486 assertions. Each target block contains four regions, an SKI region, 487 an IPv4 region, an IPv6 region and an AS number region. All regions 488 are REQUIRED to be present in a target block. 490 The SKI region contains a single line beginning with the string 491 literal SKI and followed by forty hexadecimal characters giving the 492 subject key identifier of a certificate, known as the target 493 certificate. The hex character string MAY contain embedded whitespace 494 or colon characters (included to improve readability), which are 495 ignored. The IPv4 region consists of a line containing only the 496 string literal IPv4. This line is followed by zero or more lines 497 containing IPv4 prefixes in the format described in RFC 3779. The 498 IPv6 region consists of a line containing only the string literal 499 IPv6, followed by zero or more lines containing IPv6 prefixes using 500 the format described in RFC 3513. (The presence of the IPv4 and IPv6 501 literals is to simplify parsing of the constraints file.) Finally, 502 the AS number region consists of a line containing only the string 503 literal AS#, followed by zero or more lines containing AS numbers 504 (one per line). The AS numbers are specified in decimal notation as 505 recommended in RFC 5396. A target block is terminated by either the 506 end of the constraints file, or by the beginning of the next target 507 block, as signaled by its opening SKI region line. An example target 508 block is shown below. See also the complete constraints file example 509 given in Appendix A. Note that whitespace, as always, is ignored. 511 SKI 00:12:33:44:00:BA:BA:DE:EB:EE:00:99:88:77:66:55:44:33:22:11 512 IPv4 513 10.2.3/24 514 10.8/16 515 IPv6 516 1:2:3:4:5:6/112 517 AS# 518 123 519 567 521 The blocks subsection MUST contain at least one target block. Note 522 that it is OPTIONAL that the SKI refer to a certificate that is known 523 or resolvable within the context of the local RPKI repository. Also, 524 there is no REQUIRED or implied ordering of target blocks within the 525 block subsection. As a result of the fact that blocks may occur in 526 any order, it MAY result that the outcome of processing a constraints 527 file depends on the order in which target blocks occur within the 528 constraints file. The next section of this document contains a 529 detailed description of the certificate processing algorithm. 531 4 Certificate Processing Algorithm 533 The section describes the certificate processing algorithm through 534 which paracertificates are created from original certificates in the 535 local RPKI repository. For the purposes of describing this algorithm, 536 it will be assumed that certificates may be persistently associated 537 with state (or metadata) information. This state information will be 538 further construed as having the form of any array of named bits that 539 are associated with each certificate. No specific implementation of 540 this functionality is mandated by this document. Any implementation 541 that provides the indicated functionality is acceptable, and need not 542 actually consist of a bit field associated with each certificate. 544 The state bits used in certificate processing are 546 NOCHAIN 547 ORIGINAL 548 PARA 549 TARGET 551 If the NOCHAIN bit is set, this indicates that a full path between 552 the given certificate and a TA has not yet been discovered. If the 553 ORIGINAL bit is set, this indicates that the certificate is question 554 has been processed by some part of the processing algorithm described 555 in Section 4.2. If it was processed as part of stage one processing, 556 as described in section 4.2.2, the TARGET bit will also be set. 557 Finally, any paracertificate will have the PARA bit set. 559 At the beginning of algorithm processing each certificate in the 560 local RPKI repository has the ORIGINAL, PARA and TARGET bits clear. 561 If a certificate has a complete, validated path to a TA, or is itself 562 a TA, then that certificate will have the NOCHAIN bit clear, 563 otherwise it will have the NOCHAIN bit set. As the certificate 564 processing algorithm is executed, the bit state of original 565 certificates may change. In addition, since the certificate 566 processing algorithm may also be creating paracertificates, it is 567 responsible for actively setting or clearing the state of these four 568 bits on those paracertificates. 570 The certificate processing algorithm consists of two sub-algorithms: 572 "proofreading" and "TA processing". Conceptually, the proofreading 573 sub-algorithm performs syntactic checks on the constraints file, 574 while the TA processing sub-algorithm performs the actual certificate 575 transformation processing. If the proofreading sub-algorithm does not 576 succeed in parsing the constraints file, the TA processing sub- 577 algorithm is not executed. Note also that if the constraints file is 578 not present, neither sub-algorithm is executed and the local RPKI 579 repository is not modified. Each of the constituent algorithms will 580 now be described in detail. 582 4.1 Proofreading algorithm 584 The goal of the proofreading algorithm is to check the constraints 585 file for syntactic errors, such as missing REQUIRED subsections, or 586 malformed addresses such as 1.2.300/24. It also performs a set of 587 heuristic checks, such as checking for prefixes that are too large 588 (larger than /8). The proofreading algorithm SHOULD also examine 589 resource regions (IPv4, IPv6 and AS# regions) within the blocks 590 subsection, and reorder such resources within a region in ascending 591 numeric order. On encountering any error the proofreading algorithm 592 SHOULD provide an error message indicating the line on which the 593 error occurred as well as informative text that is sufficiently 594 descriptive as to allow the user to identify and correct the error. 595 An implementation of the proofreading algorithm MUST NOT assume that 596 it has access to the local RPKI repository (even read-only access). 597 An implementation of the proofreading algorithm MUST NOT alter the 598 local RPKI repository in any way; it also MUST NOT change any of the 599 state/metadata information associated with certificates in that 600 repository. (Recall that the processing described here is creating a 601 copy of that local repository.) Finally, the proofreading algorithm 602 MAY produce a transformed output file containing the same syntactic 603 information as in the text version of the constraints file, so long 604 as the format of the transformed file is understood by the TA 605 processing algorithm. 607 The proofreading algorithm performs the following syntactic checks on 608 the constraints file. It checks for the presence of the REQUIRED 609 relying party subsection and the REQUIRED blocks subsection. It 610 checks that the order of the two, three or four subsections is as 611 stated above. It checks that the relying party subsection conforms to 612 the specification given in section 3.1 above. If present, it checks 613 that the tags and flags subsections conform to the specifications in 614 sections 3.2 and 3.3 above. It then checks the blocks subsection. It 615 splits the blocks subsection into constituent target blocks, as 616 delimited by the SKI region line(s), and verifies that at least one 617 target block is present. It verifies that each SKI region line 618 contains exactly forty hexadecimal digits and contains no additional 619 characters other than whitespace or colon characters. For each target 620 block, it then verifies the presence of the IPv4, IPv6 and AS# 621 regions, and also verifies that at least one such resource is 622 present. For each IPv4 prefix, IPv6 prefix and autonomous system 623 number given, it checks that the indicated resource is syntactically 624 valid according to the appropriate RFC definition, as described in 625 section 3.4. It also verifies that no IPv4 resource has a prefix 626 larger than /8. The proofreading algorithm SHOULD performing 627 reordering within each of the three resource regions so that stated 628 resources occur in ascending numerical order. If the proofreading 629 algorithm has performed any reordering of information it MAY 630 overwrite the constraints file. If it does so, however, it MUST 631 preserve all information contained within the file, including 632 information that is not parsed (such as comments). If the 633 proofreading algorithm has performed any reordering of information 634 but has not overwritten the constraints file, it MAY produce a 635 transformed output file, as described above. If the proofreading 636 algorithm has performed any reordering of information, but has 637 neither overwritten the constraints file nor produced a transformed 638 output file, it MUST provide an error message to the user indicating 639 what reordering was performed. 641 4.2 TA processing algorithm 643 The TA processing algorithm acts on the constraints file (or the 644 output file produced by the proofreading algorithm) and the contents 645 of the local RPKI repository to produce paracertificates for the 646 purpose of enforcing the resource allocations as expressed in the 647 constraints file. The TA processing algorithm operates in five 648 stages, a preparatory stage (stage 0), target processing (stage 1), 649 ancestor processing (stage 2), tree processing (state 3) and TA re- 650 parenting (stage 4). Conceptually, during the preparatory stage the 651 constraints (or proofreader output) file is read and a set of 652 internal RP, tag and flag variables are set based on the contents of 653 that file. (If the constraint file has not specified one or more of 654 the tags and/or flags, those tags and flags are set to default 655 values.) During target processing all certificates specified by a 656 target block are processed, and the resources for those certificates 657 are (potentially) expanded; for each target found a new 658 paracertificate is manufactured with its various fields set, as shown 659 in Table 1, using the values of the internal variables set in the 660 preparatory stage and also, of course, the fields of the original 661 certificate (and, potentially, fields of the RP's TA certificate). In 662 stage 2 (ancestor) processing, all ancestors of the each target 663 certificate are found, and the claimed resources are then removed 664 (perforated). A new paracertificate with these diminished resources 665 is crafted, with its fields generated based on internal variable 666 settings, original certificate field values, and, potentially, the 667 fields of the RP's TA certificate. In tree processing (stage 3), the 668 entire local RPKI repository is searching for any other certificates 669 that have resources that intersect a target resource, and that were 670 not otherwise processed during a preceding stage. Perforation is 671 again performed for any such intersecting certificates, and 672 paracertificates created as in stage 2. Finally, in the fourth and 673 last stage, TA re-parenting, any TA certificates in the local RPKI 674 repository that have not already been processed are now re-parented 675 under the RP's TA certificate. This transformation will create 676 paracertificates; however, these paracertificates may have RFC 3779 677 resources that were not altered during algorithm processing. The 678 final output of algorithm processing will be threefold. First, the 679 state/metadata information on some (original) certificates in the 680 repository MAY be altered. Second, paracertificates will be created, 681 with the appropriate metadata, and entered into the repository. 682 Finally, the TA processing algorithm SHOULD produce a human readable 683 log of its actions, indicating which paracertificates were created 684 and why. The remainder of this section describes the processing 685 stages of the algorithm in detail. 687 4.2.1 Preparatory processing (stage 0) 689 During preparatory processing, the constraints file, or the 690 corresponding output file of the proofreader algorithm, is read. 691 Internal variables are set corresponding to each tag and flag, if 692 present, or to their defaults, if absent. Internal variables are also 693 set corresponding to the PRIVATEKEYMETHOD value string(s) and the 694 TOPLEVELCERTIFICATE string. The TA processing algorithm is queried to 695 determine if it supports the indicated private key access 696 methodology. This query is performed in an implementation-specific 697 manner. In particular, an implementation is free to vacuously return 698 success to this query. The TA processing algorithm next uses the 699 value string for the TOPLEVELCERTIFICATE to locate this certificate, 700 again in an implementation-specific manner. The certificate in 701 question may already be present in the local RPKI repository, or it 702 may be located elsewhere. The implementation is also free to create 703 the top level certificate at this time, and then assign to this 704 newly-created certificate the name indicated. It is necessary only 705 that, at the conclusion of this processing, a valid trust anchor 706 certificate for the relying party has been created or otherwise 707 obtained. 709 Some form of access to the RP's private key and top level certificate 710 are required for subsequent correct operation of the algorithm. 711 Therefore, stage 0 processing MUST terminate if one or both 712 conditions are not satisfied. In the error case, the implementation 713 SHOULD provide an error message of sufficient detail that the user 714 can correct the error(s). If stage 0 processing does not succeed, no 715 further stages of TA processing are executed. 717 4.2.2 Target processing (stage 1) 719 During target processing, the TA processing algorithm reads all 720 target blocks in the constraints file or corresponding proofreader 721 output file. It then processes each target block in the order 722 specified in the file. In the description that follows, except where 723 noted, the operation of the algorithm on a single target block will 724 be described. Note, however, that all stage 1 processing is executed 725 before any processing in subsequent stages is performed. 727 The algorithm first obtains the SKI region of the target block. It 728 then locates, in an implementation-dependent manner, the certificate 729 the SKI extension field of which contains that value. Note that if 730 paracertificates have been created by virtue of previous target 731 blocks being processed, those paracertificates are not searched in 732 attempting to locate a certificate with a matching SKI; only original 733 certificates are searched. If more than one original certificate is 734 found matching this SKI, there are two possible scenarios. If a 735 resource holder has two certificates issued by the same CA, with 736 overlapping validity intervals and the same key, but distinct subject 737 names (typically, by virtue of the SerialNumber parts being 738 different), then these two certificates are both considered to be 739 (distinct) targets, and are both processed. If, however, a resource 740 holder has certificates issued by two different CAs, containing 741 different resources, but using the same key, there is no unambiguous 742 method to decide which of the certificates is intended as the target. 743 In this latter case the algorithm MUST issue a warning to that 744 effect, mark the target block in question as unavailable for 745 processing by subsequent stages and proceed to the next target block. 746 If no certificate is found then the algorithm SHOULD issue a warning 747 to that effect and proceed to process the next target block. 749 If a single original certificate is found matching the indicated SKI, 750 then the algorithm takes the following actions. First, it sets the 751 ORIGINAL state bit for the certificate found. Second, it sets the 752 TARGET state bit for the certificate found. Third, it extracts the 753 RFC 3779 resources from the certificate. If the global 754 resource_nounion flag is TRUE, it compares the extracted certificate 755 resources with the resources specified in the constraints file. If 756 the two resource sets are different, the algorithm SHOULD issue a 757 warning noting the difference. An output resource set is then formed 758 that is identical to the resource set extracted from the certificate. 759 If, however, the resource_nounion flag is FALSE, then the output 760 resource set is calculated by forming the union of the resources 761 extracted from the certificate and the resources specified for this 762 target block in the constraints file. A paracertificate is then 763 constructed according to Table 1, using fields from the original 764 certificate, the tags that had been set during stage 0, and, if 765 necessary, fields from the RP's TA certificate. The RFC 3779 766 resources of the paracertificate are equated to the derived output 767 resource set. The PARA state bit is set for the newly created 768 paracertificate. 770 4.2.3 Ancestor processing (stage 2) 772 The goal of ancestor processing is to discover all ancestors of 773 target certificates and remove from those ancestors the resources 774 specified in the target blocks corresponding to the targets being 775 processed. Note that it is possible that, for a given chain from a 776 target certificate to a trust anchor, another target might be 777 encountered. This is handled by removing all the target resources of 778 all descendents. The set of all targets that are descendants of the 779 given certificate is formed. The union of all the target resources of 780 the corresponding target blocks is computed, and this union in then 781 removed from the shared ancestor. 783 In detail, the algorithm is as follows. First, all original target 784 certificates processed during stage 1 processing are collected. 785 Second, any such certificates that have the NOCHAIN state bit set are 786 eliminated from the collection. (Note that, as a result of 787 eliminating such certificates, the resulting collection may be empty, 788 in which case this stage of algorithm processing terminates, and 789 processing advances to stage 3.) Next, an implementation MAY sort the 790 collection. The optional sorting algorithm is described in Appendix 791 B. Note that all stage 2 processing is completed before any stage 3 792 processing. 794 Two levels of nested iteration are performed. The outer iteration is 795 effected over all certificates in the collection; the inner iteration 796 is over all ancestors of the designated certificate being processed. 797 The first certificate in the collection is chosen, and a resource set 798 R is initialized based on the resources of the target block for that 799 certificate (since the certificate is in the collection, it must be a 800 target certificate, and thus correspond to a target block). The 801 parent of the certificate is then located using ordinary path 802 discovery over original certificates only. The ancestor's certificate 803 resources A are then extracted. These resources are then perforated 804 with respect to R. That is, an output set of resources is created by 805 forming the intersection I of A and R, and then taking the set 806 difference A - I as the output resources. A paracertificate is then 807 created containing resources that are these output resources, and 808 containing other fields and extensions from the original certificate 809 (and possibly the RP's TA certificate) according to the procedure 810 given in Table 1. The PARA state bit is set on this paracertificate 811 and the ORIGINAL state bit is set on A. If A is also a target 812 certificate, as indicated by its TARGET state bit being set, then 813 there will already have been a paracertificate created for it. This 814 previous paracertificate is destroyed in favor of the newly created 815 paracertificate. In this case also, the set R is augmented by adding 816 into it the set of resources of the target block for A. The algorithm 817 then proceeds to process the parent of A. This inner iteration 818 continues until the self-signed certificate at the root of the path 819 is encountered and processed. The outer iteration then continues by 820 clearing R and proceeding to the next certificate in the target 821 collection. 823 Note that ancestor processing has the potential for order dependency, 824 as mentioned earlier in this document. If sorting is not implemented, 825 or if the sorting algorithm fails to completely process the 826 collection of target certificates because the allotted maximum number 827 of iterations has been realized, it may be the case that an ancestor 828 of a certificate logically occurs before that certificate in the 829 collection. Whenever an existing paracertificate is replaced by a 830 newly created paracertificate during ancestor processing, the 831 algorithm SHOULD alert the user, and SHOULD log sufficient detail 832 such that the user is able to determine which resources were 833 perforated from the original certificate in order to create the (new) 834 paracertificate. 836 In addition, implementations MUST provide for conflict detection and 837 notification during ancestor processing. In particular, if a 838 certificate is encountered two or more times during any part of the 839 ancestor processing algorithm, and the modifications dictated by the 840 ancestor processing algorithm are in conflict, the implementation 841 MUST refrain from processing that certificate. Further, the 842 implementation MUST present the user with an error message that 843 contains enough detail that the user can locate those directives in 844 the constraints file that are creating the conflict. For example, 845 during one stage of the processing algorithm it may be directed that 846 resources R1 be added to a certificate C, while during a different 847 stage of the processing algorithm it may be directed that resources 848 R2 be removed from certificate C. If the resource sets R1 and R2 have 849 a non-empty intersection, that is a conflict. 851 4.2.4 Tree processing (stage 3) 853 The goal of tree processing is to locate other certificates the 854 resources of which might conflict with the resources allocated to a 855 target by virtue of their being mentioned in the constraints file. In 856 this stage of processing, certificates that are not ancestors of any 857 target are considered. In detail, the algorithm used is as follows. 858 First, all target certificates are again collected. Second, all 859 target certificates that have the NOCHAIN state bit set are 860 eliminated from this collection. Third, if the intersection_always 861 global flag is set, those target blocks that occur in the constraints 862 file, but that did not correspond to a certificate in the local 863 repository, are also added to the collection. In tree processing, 864 unlike ancestor processing, this collection is not sorted. An 865 iteration is now performed over each certificate (or set of target 866 block resources) in the collection. Note that the collection may be 867 empty, in which case this stage of algorithm processing terminates, 868 and processing advances to stage 4. Note also that all stage 3 869 processing is performed before any stage 4 processing. 871 Given a certificate or target resource block, each top level original 872 TA certificate is examined. If that TA certificate has an 873 intersection with the target block resources, then the certificate is 874 perforated with respect to those resources. A paracertificate is 875 created based on the contents of the original certificate (and 876 possibly the RP's TA certificate, as indicated in Table 1) using the 877 perforated resources. The ORIGINAL state bit is set on the original 878 certificate processed in this manner, and the PARA state bit is set 879 on the paracertificate just created. An inner iteration then begins 880 on the descendants of the original certificate just processed. There 881 are two ways in which this iteration may proceed. If the treegrowth 882 global flag is clear, then examination of the children proceeds until 883 all children are exhausted, or until one child is found with 884 intersecting resources. If the treegrowth global flag is set, all 885 children are examined. Since a transfer of resources may be in 886 process such that more than one child possesses intersecting 887 resources, it is RECOMMENDED that the treegrowth flag be set. The 888 inner iteration proceeds until all descendants have been examined and 889 no further intersecting resources are found. The outer iteration then 890 continues with the next certificate or target resource block in the 891 collection. Note that unlike ancestor processing, there is no concept 892 of a potentially cumulating resource collection R; only the resources 893 in the target block are used for perforation. 895 4.2.5 TA re-parenting (stage 4) 897 In the final stage of TA algorithm processing, all TA certificates 898 (other than the RP's TA certificate) that have not already been 899 processed in a previous stage are now processed. It will be the case 900 that all such unprocessed TA certificates have no intersection with 901 any target resource blocks. As such, in creating the corresponding 902 paracertificates, the output resource set is identical to the input 903 resource set. Other transformations as described in Table 1 are 904 performed. The original TA certificates have the ORIGINAL state bit 905 set; the newly created paracertificates have the PARA state bit set. 906 Note that once stage four processing is completely, only a single TA 907 certificate will remain in an unprocessed state, namely the relying 908 party's own TA certificate. 910 4.3 Discussion 912 The algorithm described in this document effectively creates two 913 coexisting certificate hierarchies: the original certificate 914 hierarchy and the paracertificate hierarchy. Note that original 915 certificates are not removed during any of the processing described 916 in the previous section. Some original certificates may move from 917 having no state bits set (or only the NOCHAIN state bit set) to 918 having one or both of the ORIGINAL and TARGET state bits set. In 919 addition, the NOCHAIN state bit will still be set if it was set 920 before any processing. The paracertificate hierarchy, however, is 921 intended to supersede the original hierarchy for the purposes of ROA 922 validation. The presence of two hierarchies has implications for the 923 handling of path discovery, and also for the handling of revocation. 924 If one thinks of a certificate as being "named" by its SKI, then 925 there can now be two certificates with the same name, one an original 926 certificate and the other a paracertificate. The next two sections 927 discuss the implications of this duality in detail. Before 928 proceeding, it is worth noting that even without the existence of the 929 paracertificate hierarchy, cases may exist in which two or more 930 original certificates have the same SKI. As noted earlier, in Section 931 4.2.2, these cases may be subdivided into the case in which such 932 certificates are distinguishable by virtue of having different 933 subject names, but identical issuers and resource sets, versus all 934 other cases. In the distinguishable case, the path discovery 935 algorithm treats the original certificates as separate certificates, 936 and processes them separately. In all other cases, the original 937 certificates should be treated as indistinguishable, and path 938 validation should fail. 940 5 Implications for Path Discovery 942 Path discovery proceeds from a child certificate C by asking for a 943 parent certificate P such that the AKI of C is equal to the SKI of P. 944 With one hierarchy this question would produce at most one answer. 945 With two hierarchies, the original certificate hierarchy and the 946 paracertificate hierarchy, the question may produce two answers, one 947 answer, or no answer. Each of these cases is considered in turn. 949 5.1 Two answers 951 In this case, it SHOULD be the case that one of the matches is a 952 certificate with the ORIGINAL state bit set and the PARA state bit 953 clear, while the other match inversely has the ORIGINAL state bit 954 clear and the PARA state bit set. If any other combination of 955 ORIGINAL and PARA state bits obtains, the path discovery algorithm 956 MUST alert the user. In addition, the path discovery algorithm SHOULD 957 refrain from attempting to make a choice as to which of the two 958 certificates is the putative parent. In the no-error case, with the 959 state bits are as indicated, the certificate with the PARA state bit 960 set is chosen as the parent P. Note this means, in effect, that all 961 children of the original certificate have been re-parented under the 962 paracertificate. 964 5.2 One answer 966 If the matching certificate has neither the ORIGINAL state bit set 967 nor the PARA state bit set, this certificate is the parent. If the 968 matching certificate has the PARA state bit set but the ORIGINAL 969 state bit not set, this certificate is the parent. (This situation 970 would arise, for example, if the original certificate had been 971 revoked by its issuer but the paracertificate had not been revoked by 972 the RP.) If the matching certificate has the ORIGINAL state bit set 973 but the PARA state bit not set, this is not an error but it is a 974 situation in which path discovery MUST be forced to fail. The parent 975 P MUST be set to NULL, and the NOCHAIN state bit must be set on C and 976 all its descendants; the user SHOULD be warned. Even if the RP has 977 revoked the paracertificate, the original certificate MAY persist. 978 Forcing path discovery to unsuccessfully terminate is a reflection of 979 the RP's preference for path discovery to fail as opposed to using 980 the original hierarchy. Finally, if the matching certificate has both 981 the ORIGINAL and PARA state bits set, this is an error. The parent P 982 MUST be set to NULL, and the user MUST be warned. 984 5.3 No answer 986 This situation occurs when C has no parent in either the original 987 hierarchy or the paracertificate hierarchy. In this case the parent P 988 is NULL and path discovery terminates unsuccessfully. The NOCHAIN 989 state bit must be set on C and all its descendants. 991 6 Implications for Revocation 993 In a standard implementation of revocation in a PKI, a valid CRL 994 names a (sibling) certificate by serial number. That certificate is 995 revoked and is purged from the local RPKI repository. In the 996 mechanism described in this document, the original certificate 997 hierarchy and the paracertificate hierarchy are closely related. It 998 can thus be asked how revocation is handled in the presence of these 999 two hierarchies, in particular with regard to whether changes in one 1000 of the hierarchies triggers corresponding changes in the other 1001 hierarchy. There are four cases based on the state of the ORIGINAL 1002 and PARA bits. These will be discussed in the subsections below. It 1003 should be noted that the existence of two hierarchies presents a 1004 particular challenge with respect to revocation. If a CRL arrives and 1005 is processed, that can result in the destruction of one of the path 1006 chains. In the case of a single hierarchy this would mean that 1007 certain objects would fail to validate. In the presence of two 1008 hierarchies, however, a CRL revocation may force the preferred path 1009 to be destroyed. If the RP later determines that the CRL revocation 1010 should not have occurred, he is faced with an undesirable situation: 1011 the deprecated path will be discovered. In order to prevent this 1012 outcome, an RP MUST be able to configure one or more additional 1013 repository URIs in support of local trust anchor management. 1015 6.1 No state bits set 1017 If the CRL names a certificate that has neither the ORIGINAL state 1018 bit set nor the PARA state bit set, revocation proceeds normally. All 1019 children of the revoked certificate have their state modified so that 1020 the NOCHAIN state bit is set. 1022 6.2 ORIGINAL state bit set 1024 If the CRL names a certificate with the ORIGINAL state bit set and 1025 the PARA state bit clear, then this certificate is revoked as usual. 1026 If this original certificate also has the TARGET state bit set, then 1027 the corresponding paracertificate (if it exists) is not revoked; if 1028 this original certificate has the TARGET state bit clear, then the 1029 corresponding paracertificate is revoked as well. Note that since all 1030 the children of the original certificate have been re-parented to be 1031 children of the corresponding paracertificate, as described above, 1032 the revocation algorithm MUST NOT set the NOCHAIN state bit on these 1033 children unless the paracertificate is also revoked. Note also that 1034 if the original certificate is revoked but the paracertificate is not 1035 revoked, the paracertificate retains its PARA state bit. This is to 1036 ensure that path discovery proceeds preferentially through the 1037 paracertificate hierarchy, as described above. 1039 6.3 PARA state bit set 1041 If the CRL names a certificate with the PARA state bit set and the 1042 ORIGINAL state bit clear, this CRL must have been issued, perforce, 1043 by the RP itself. This is because all the paracertificates are 1044 children of the RP's TA certificate. (Recall that a TA is not revoked 1045 via a CRL; it is merely removed from the repository.) The 1046 paracertificate is revoked and all children of the paracertificate 1047 have the NOCHAIN state bit set. No action is taken on the 1048 corresponding original certificate; in particular, its ORIGINAL state 1049 bit is not cleared. 1051 Note that the serial numbers of paracertificates are synthesized 1052 according to the procedure given in Table 1, rather than being 1053 assigned by an algorithm under the control of the (original) issuer. 1055 6.4 Both ORIGINAL and PARA state bits set 1057 This is an error. The revocation algorithm MUST alert the user and 1058 take no further action. 1060 ' 1061 7 Security Considerations 1063 The goal of the algorithm described in this document is to enable an 1064 RP to impose its own constraints on its view of the RPKI, which 1065 itself is a security function. An RP using a constraints file is 1066 trusting the assertions made in that file. Errors in the constraints 1067 file used by an RP can undermine the security offered by the RPKI, to 1068 that RP. In particular, since the paracertificate hierarchy is 1069 intended to trump the original certificate hierarchy for the purposes 1070 of path discovery, an improperly constructed paracertificate 1071 hierarchy could validate origin attestations that would otherwise be 1072 invalid, or could declare as invalid origin attestations that would 1073 otherwise be valid. As a result, an RP must carefully consider the 1074 security implications of the constraints file being used. 1076 8 IANA Considerations 1078 [Note to IANA, to be removed prior to publication: there are no IANA 1079 considerations stated in this version of the document.] 1081 9 Acknowledgements 1083 The authors would like to acknowledge the significant contributions 1084 of Charles Gardiner, who was the original author of an internal 1085 version of this document, and who contributed significantly to its 1086 evolution into the current version. 1088 10 References 1090 10.1 Normative References 1092 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1093 Requirement Levels", BCP 14, RFC 2119, March 1997. 1095 [RFC3513] Hinden, R., and S. Deering, "Internet Protocol Version 6 1096 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1098 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1099 Addresses and AS Identifiers", RFC 3779, June 2004. 1101 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1102 Housley, R., and W. Polk, "Internet X.509 Public Key 1103 Infrastructure Certificate and Certificate Revocation 1104 List (CRL) Profile", RFC 5280, May 2008. 1106 [RFC5396] Huston, G., and G. Michaelson, "Textual Representation of 1107 Autonomous System (AS) Numbers", RFC 5396, December 2008. 1109 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1110 Secure Internet Routing", RFC 6480, February 2012. 1112 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile 1113 for Resource Certificate Policy Structure", RFC 6481, 1114 Feburary 2012. 1116 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile 1117 for X.509 PKIX Resource Certificates", RFC 6487, February 1118 2012. 1120 10.2 Informative References 1122 None. 1124 Authors' Addresses 1126 Stephen Kent 1127 Raytheon BBN Technologies 1128 10 Moulton St. 1129 Cambridge, MA 02138 1131 Email: kent@bbn.com 1133 Matthew Lepinski 1134 Raytheon BBN Technologies 1135 10 Moulton St. 1136 Cambridge, MA 02138 1138 Email: mlepinsk@bbn.com 1140 Mark Reynolds 1141 Island Peak Software 1142 328 Virginia Road 1143 Concord, MA 01742 1145 Email: mcr@islandpeaksoftware.com 1147 Appendix A: Sample Constraints File 1149 ; 1150 ; Sample constraints file for TBO LTA Test Corporation. 1151 ; 1152 ; TBO manages its own local (10.x.x.x) address space 1153 ; via the target blocks in this file. 1154 ; 1156 ; 1157 ; Relying party subsection. TBO uses ssh-agent as 1158 ; a software cryptographic agent. 1159 ; 1161 PRIVATEKEYMETHOD OBO(ssh-agent) 1162 TOPLEVELCERTIFICATE tbomaster.cer 1164 ; 1165 ; Flags subsection 1166 ; 1167 ; Always use the resources in this file to augment 1168 ; certificate resources. 1169 ; Always process resource conflicts in the tree, even 1170 ; if the target certificate is missing. 1171 ; Always search the entire tree. 1172 ; 1174 CONTROL resource_nounion FALSE 1175 CONTROL intersection_always TRUE 1176 CONTROL treegrowth TRUE 1178 ; 1179 ; Tags subsection 1180 ; 1181 ; Copy the original cert's validity dates. 1182 ; Use the default policy OID. 1183 ; Use our own CRLDP. 1184 ; Use our own AIA. 1185 ; 1187 TAG Xvalidity_dates C 1188 TAG Xcp D 1189 TAG Xcrldp rsync://tbo_lta_test.com/pub/CRLs 1190 TAG Xaia rsync://tbo_lta_test.com/pub/repos 1192 ; 1193 ; Block subsection 1194 ; 1196 ; 1197 ; First block: TBO corporate 1198 ; 1200 SKI 00112233445566778899998877665544332211 1201 IPv4 1202 10.2.3/24 1203 10.8/16 1204 IPv6 1205 2000:2:3:4:5:6/112 1206 AS# 1207 60123 1208 5507 1210 ; 1211 ; Second block: TBO LTA Test Enforcement Division 1212 ; 1214 SKI 653420AF758421CF600029FF857422AA6833299F 1215 IPv4 1216 10.2.8/24 1217 10.47/16 1218 IPv6 1219 AS# 1220 60124 1222 ; 1223 ; Third block: TBO LTA Test Acceptance Corporation 1224 ; Quality financial services since sometime 1225 ; late yesterday. 1226 ; 1228 SKI 19:82:34:90:8b:a0:9c:ef:00:af:a0:98:23:09:82:4b:ef:ab:98:09 1229 IPv4 1230 10.3.3/24 1231 IPv6 1232 AS# 1233 60125 1235 ; End of TBO constraints file 1237 Appendix B: Optional Sorting Algorithm for Ancestor Processing 1239 Sorting is performed in an effort to eliminate any order dependencies 1240 in ancestor processing, as described in section 4.2.3 of this 1241 document. The sorting algorithm does this by rearranging the 1242 processing of certificates such that if A is an ancestor of B, B is 1243 processed before A. The sorting algorithm is an OPTIONAL part of 1244 ancestor processing. Sorting proceeds as follows. The collection 1245 created at the beginning of ancestor processing is traversed and any 1246 certificate in the collection that is visited as a result of path 1247 discovery is temporarily marked. After the traversal, all unmarked 1248 certificates are moved to the beginning of the collection. The 1249 remaining marked certificates are unmarked, and a traversal again 1250 performed through this sub-collection of previously marked 1251 certificates. The sorting algorithm proceeds iteratively until all 1252 certificates have been sorted or until a predetermined fixed number 1253 of iterations has been performed. (Eight is suggested as a munificent 1254 value for the upper bound, since the number of sorting steps need not 1255 be any greater than the maximum depth of the tree.) Finally, the 1256 ancestor processing algorithm is applied in turn to each certificate 1257 in the remaining sorted collection. If the sorting algorithm fails to 1258 converge, that is if the maximum number of iterations has been 1259 reached and unsorted certificates remain, the implementation SHOULD 1260 warn the user.