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