idnits 2.17.1 draft-ietf-sidr-rpki-manifests-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2010) is 4943 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 862 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-16 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-04 ** Downref: Normative reference to an Informational draft: draft-huston-sidr-rpki-algs (ref. 'ID.ietf-sidr-rpki-algs') == Outdated reference: A later version (-04) exists of draft-ietf-sidr-signed-object-01 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-11 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-keyroll-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing R. Austein 3 Internet-Draft ISC 4 Intended status: Standards Track G. Huston 5 Expires: April 18, 2011 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 October 15, 2010 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-08.txt 14 Abstract 16 This document defines a "manifest" for use in the Resource Public Key 17 Infrastructure (RPKI). A manifest is a signed object that contains a 18 listing of all the signed objects in the repository publication point 19 associated with an authority responsible for publishing in the 20 repository. For each certificate, Certificate Revocation List (CRL), 21 or other type of signed objects issued by the authority that are 22 published at this repository publication point, the manifest contains 23 both the name of the file containing the object, and a hash of the 24 file content. Manifests are intended to enable a relying party (RP) 25 to detect certain forms of attacks against a repository. 26 Specifically, if a RP checks a manifest's contents against the signed 27 objects retrieved from a repository publication point, then the RP 28 can detect "stale" (valid) data and deletion of signed objects. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 18, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Manifest Definition . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. eContentType . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.3. ContentType Attribute . . . . . . . . . . . . . . . . . . 7 72 4.4. Manifest Validation . . . . . . . . . . . . . . . . . . . 7 73 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 8 75 5.2. End Entity Manifest Generation . . . . . . . . . . . . . . 9 76 5.3. Common Considerations for Manifest Generation . . . . . . 10 77 6. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 10 78 6.1. Tests for Determining Manifest State . . . . . . . . . . . 11 79 6.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 12 80 6.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 13 81 6.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 13 82 6.5. Mismatch between Manifest and Publication Point . . . . . 14 83 6.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 15 84 7. Publication Repositories . . . . . . . . . . . . . . . . . . . 16 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 91 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 The Resource Public Key Infrastructure (RPKI) [ID.ietf-sidr-arch] 97 makes use of a distributed repository system 98 [ID.ietf-sidr-repos-struct] to make available a variety of objects 99 needed by relying parties (RPs). Because all of the objects stored 100 in the repository system are digitally signed by the entities that 101 created them, attacks that modify these published objects are 102 detectable by RPs. However, digital signatures provide no protection 103 against attacks that substitute "stale" versions of signed objects 104 (i.e., objects that were valid and have not expired, but have since 105 been superseded) or attacks that remove an object that should be 106 present in the repository. To assist in the detection of such 107 attacks, the RPKI repository system can make use of a signed object 108 called a "manifest". 110 A manifest is a signed object that enumerates all the signed objects 111 in the repository publication point that are associated with an 112 authority responsible for publishing at that publication point. Each 113 manifest contains both the name of the file containing the object, 114 and a hash of the file content, for every signed object issued by an 115 authority that is published at the authority's repository publication 116 point. A manifest is intended to allow an RP to detect unauthorized 117 object removal, or the substitution of "stale" versions of objects at 118 a publication point. A manifest also intended to allow an RP to 119 detect similar outcomes that may result from a man-in-the middle 120 attack on the retrieval of objects from the repository. Manifests 121 are intended to be used both in Certification Authority (CA) 122 publication points in repositories (containing subordinate 123 certificates, Certificate Revocation Lists (CRLs) and other signed 124 objects) and in End Entity (EE) publication points in repositories 125 (containing only signed objects). 127 Manifests are modelled on CRLs, as the issues involved in detecting 128 stale manifests, and detection of potential attacks using manifest 129 replays, etc are similar to those for CRLs. The syntax of the 130 manifest payload differs from CRLs, since RPKI repositories contain 131 objects not covered by CRLs,e.g., digitally signed objects, such as 132 Route Origination Authorizations (ROAs). 134 1.1. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119. 140 2. Manifest Scope 142 A manifest associated with a CA's repository publication point 143 contains: 145 * the set of (non-expired, non-revoked) certificates issued and 146 published by this CA, 147 * the most recent CRL issued by this CA, and 148 * all signed objects that are verifiable using a "single-use" EE 149 certificate [I-D.sidr-res-certs], issued by this CA. 151 Where multiple CA instances share a common publication point, as can 152 occur when an entity performs a key-rollover operation 153 [ID.sidr-keyroll], the repository publication point will contain 154 multiple manifests. In this case, each manifest describes only the 155 collection of published products of its associated CA instance. 157 A manifest associated with a "multi-use" EE certificate 158 [I-D.sidr-res-certs] where an EE has a defined repository publication 159 point (i.e., the SIA extension of the EE certificate has an 160 accessMethod OID of id-ad-signedObjectRepository), contains all 161 published objects that are verifiable using this EE certificate, and 162 the accessMethod id-as-rpkiManifest points to the publication point 163 of the EE's manifest. 165 3. Manifest Signing 167 A CA's manifest is verified using an EE certificate that is 168 designated in [I-D.sidr-res-certs] as a "single-use" EE certificate. 169 The SIA field of the "single-use" EE certificate contains the access 170 method OID of id-ad-signedObject. 172 The CA MAY chose to sign only one manifest with the private key of 173 the EE certificate, and generate a new EE certificate for each new 174 version of the manifest. This form of use of a "single-use" EE 175 certificate is termed a "one-time-use" EE certificate. 177 Alternatively, the CA MAY chose to use the same EE certificate's 178 private key to sign a sequence of manifests. Because only a single 179 manifest (issued under a single CA instance) is current at any point 180 in time, the EE certificate is used to verify only a single object at 181 a time. As long as the sequence of objects verified by this EE 182 certificate are published using the same file name, then this 183 sequential, multiple use of this "single-use" EE certificate is also 184 valid. This form of use of a "single-use" EE certificate is termed a 185 "sequential-use" EE certificate. 187 A "multi-use" EE's manifest of it's publication repository is signed 188 with the EE's private key. 190 4. Manifest Definition 192 A manifest is a RPKI signed object, as specified in 193 [ID.sidr-signed-object]. The RPKI signed object template requires 194 specification of the following data elements in the context of the 195 manifest structure. 197 4.1. eContentType 199 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 200 has the numerical value of 1.2.840.113549.1.9.16.1.26. 202 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 203 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 205 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 207 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 209 4.2. eContent 211 The content of a Manifest is defined as follows: 213 Manifest ::= SEQUENCE { 214 version [0] INTEGER DEFAULT 0, 215 manifestNumber INTEGER (0..MAX), 216 thisUpdate GeneralizedTime, 217 nextUpdate GeneralizedTime, 218 fileHashAlg OBJECT IDENTIFIER, 219 fileList SEQUENCE (SIZE 0..MAX) OF FileAndHash 220 } 222 FileAndHash ::= SEQUENCE { 223 file IA5String, 224 hash BIT STRING 225 } 227 4.2.1. Manifest 229 The manifestNumber, thisUpdate, and nextUpdate fields are modelled 230 after the corresponding fields in X.509 CRLs (see [RFC5280]). 231 Analogous to CRLs, a manifest is nominally current until the time 232 specified in nextUpdate or until a manifest is issued with a greater 233 manifest number, whichever comes first. 235 If a "one-time-use" EE certificate is employed to verify a manifest, 236 the EE certificate MUST have an validity period that coincides with 237 the interval from thisUpdate to nextUpdate, to prevent needless 238 growth of the CA's CRL. 240 If a "sequential-use" EE certificate is employed to verify a 241 manifest, the EE certificate's validity period needs to be no shorter 242 than the nextUpdate time of the current manifest. The extended 243 validity time raises the possibility of a substitution attack using a 244 stale manifest, as described in Section 6.4. 246 The data elements of the Manifest structure are defined as follows: 248 version: 249 The version number of this version of the manifest specification 250 MUST be 0. 252 manifestNumber: 253 This field is an integer that is incremented each time a new 254 manifest is issued for a given publication point. This field 255 allows a RP to detect gaps in a sequence of published manifest. 257 As the manifest is modelled on the CRL specification, the 258 ManifestNumber is analogous to the CRLNumber, and the guidance in 259 [RFC5280] for CRLNumber values is appropriate as to the range of 260 number values that can be used for the manifestNumber. Manifest 261 numbers can be expected to contain long integers. Manifest 262 verifiers MUST be able to handle number values up to 20 octets. 263 Conforming Manifest issuers MUST NOT use number values longer than 264 20 octets 266 thisUpdate: 267 This field contains the time when the manifest was created. This 268 field has the same format constraints as specified in [RFC5280] 269 for the CRL field of the same name. 271 nextUpdate: 272 This field contains the time at which the next scheduled manifest 273 will be issued. The value of nextUpdate MUST be later than the 274 value of thisUpdate. The specification of the GeneralizedTime 275 value is the same as required for the thisUpdate field. 277 If the authority alters any of the items that it has published in 278 the repository publication point, then the authority MUST issue a 279 new manifest before the nextUpdate time. If a manifest 280 encompasses a CRL, the nextUpdate field of the manifest MUST match 281 that of the CRL's nextUpdate field, as the manifest will be 282 reissued when a new CRL is published. If a "one-time-use" EE 283 certificate is used to verify the manifest, then when a new 284 manifest is issued before the time specified in nextUpdate of the 285 current manifest, the CA MUST also issue a new CRL that includes 286 the EE certificate corresponding to the old manifest. 288 fileHashAlg: 289 This field contains the OID of the hash algorithm used to hash the 290 files that the authority has placed into the repository. The hash 291 algorithm used MUST conform to the RPKI Algorithms and Key Size 292 Profile specification [ID.ietf-sidr-rpki-algs]. 294 fileList: 295 This field is a sequence of FileAndHash objects. There is one 296 FileAndHash entry for each currently valid signed object that has 297 been published by the authority (at this publication point). Each 298 FileAndHash is an ordered pair consisting of the name of the file 299 in the repository that contains the object in question, and a hash 300 of the file's contents. 302 4.3. ContentType Attribute 304 The mandatory Content-Type Attribute MUST have its attrValues field 305 set to the same OID as eContentType. This OID is id-ct-rpkiManifest, 306 and has the numerical value of 1.2.840.113549.1.9.16.1.26. 308 4.4. Manifest Validation 310 To determine whether a manifest is valid, the RP MUST perform the 311 following checks in addition to those specified in 312 [ID.sidr-signed-object]: 314 1. The eContentType in the EncapsulatedContentInfo is id-ad- 315 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 317 2. The version of the rpkiManifest is 0. 319 3. In the rpkiManifest, thisUpdate precedes nextUpdate. 321 If the above procedure indicates that the manifest is invalid, then 322 the manifest MUST be discarded and treated as though no manifest were 323 present. 325 5. Manifest Generation 326 5.1. CA Manifest Generation 328 For a CA publication point in the RPKI repository system, a CA MUST 329 perform the following steps to generate a manifest: 331 1. If no key pair exists, or if using a "one-time-use" EE 332 certificate with a new key pair, generate a key pair. 334 2. If using a "one-time-use" EE certificate, or if a key pair was 335 generated in step 1, issue a "single-use" EE certificate for this 336 key pair. 338 This EE certificate has an SIA extension access description 339 field with an accessMethod OID value of id-ad-signedobject 340 where the associated accessLocation references the publication 341 point of the manifest as an object URL. 343 This EE certificate MUST describe its Internet Number 344 Resources (INRs) using the "inherit" attribute, rather than 345 explicit description of a resource set (see [RFC3779]). 347 In the case of a "one-time-use" EE certificate, the validity 348 times of the EE certificate MUST exactly match the thisUpdate 349 and nextUpdate times of the manifest. 351 In the case of a "sequential-use" EE certificate the validity 352 times of the EE certificate MUST encompass the time interval 353 from thisUpdate to nextUpdate. 355 3. The EE certificate MUST NOT be published in the authority's 356 repository publication point. 358 4. Construct the manifest content. Note that the manifest does not 359 include a self reference (i.e., its own file name and hash), 360 since it would be impossible to compute the hash of the manifest 361 itself prior to it being signed. The manifest content is 362 described in Section 4.2.1. The manifest's fileList includes the 363 file name and hash pair for each object issued by this CA that 364 has been published at this repository publication point. The 365 collection of objects to be included in the manifest includes all 366 certificates issued by this CA that are published at the CA's 367 repository publication point, the most recent CRL issued by the 368 CA, and all objects verified by "single-use" EE certificates that 369 were issued by this CA that are published at this repository 370 publication point. 372 5. Encapsulate the Manifest content using the CMS SignedData content 373 type (as specified Section 4), sign the manifest using the 374 private key corresponding to the subject key contained in the EE 375 certificate, and publish the manifest in repository system 376 publication point that is described by the manifest. 378 6. In the case of a key pair that is to be used only once, in 379 conjunction with a "one-time-use" EE certificate, the private key 380 associated with this key pair SHOULD now be destroyed. 382 5.2. End Entity Manifest Generation 384 EE repository publication points are used only in conjunction with 385 "multi-use" EE Certificates. In this case the EE Certificate has two 386 accessMethods specified in its SIA field. The accessDescription 387 element that contains an accessMethod value of id-ad- 388 signedObjectRepository has an associated accessLocation directory URL 389 that points to the repository publication point of the objects 390 verifiable using this EE certificate, as specified in 391 [I-D.sidr-res-certs]. The accessDescription element that contains an 392 accessMethod value of id-ad-rpkiManifest has an associated 393 accessLocation that points to the EE's published manifest object as 394 an object URL. This manifest enumerates every signed object to be 395 found in that publication point (that can be verified using this EE 396 certificate), and the hash value of each object (excluding the 397 manifest itself). 399 To create a manifest, each "multi-use" EE MUST perform the following 400 steps:. 402 1. Construct the Manifest content. Note that the manifest does not 403 include a self reference (i.e., its own file name and hash), 404 since it would be impossible to compute the hash of the manifest 405 itself prior to it being signed. The manifest content is 406 described in Section 4.2.1. The manifest's fileList includes the 407 file names and hash pair for each object that is verifiable using 408 that EE certificate that has been published at this repository 409 publication point. 411 2. Encapsulate the Manifest content using the CMS SignedData content 412 type (as specified in Section 4), sign the manifest using the 413 private key corresponding to the subject key contained in the EE 414 certificate, and publish the manifest in repository system 415 publication point that is described by the manifest. 417 "Single Use" EE certificates (EE certificates with an SIA 418 accessMethod OID of id-as-signedObject) do not have repository 419 publication points. The object that is verifiable using the "Single 420 Use" EE certificate is published in the repository publication point 421 of the CA certificate that issued the EE certificate, and is listed 422 in the corresponding manifest for this CA certificate. 424 5.3. Common Considerations for Manifest Generation 426 A new manifest MUST be issued on or before the nextUpdate time. 428 An authority MUST issue a new manifest in conjunction with the 429 finalization of changes made to objects in the publication point. An 430 authority MAY perform a number of object operations on a publication 431 repository within the scope of a repository change before issuing a 432 single manifest that covers all the operations within the scope of 433 this change. Repository operators SHOULD implement some form of 434 repository update procedure that mitigates, to the extent possible, 435 the risk that RPs who are performing retrieval operations on the 436 repository are exposed to inconsistent transient intermediate states 437 during updates to the repository and the associated manifest. 439 Since the manifest object URL is included in the SIA of issued 440 Certificates, a new manifest MUST NOT invalidate the manifest object 441 URL of previously issued certificates. This implies that the 442 manifest's publication name in the repository, in the form of an 443 object URL, is unchanged across manifest generation cycles. 445 In the case of a CA publication point manifest, when the CA entity is 446 performing a key rollover, the entity MAY chose to have two CAs 447 instances simultaneously publishing at the same publication point. 448 In this case there will be one manifest associated with each active 449 CA instance that is publishing into the common repository publication 450 point. 452 In the case of an EE publication point, the manifest lists all 453 published objects verified using that EE certificate. Multiple EEs 454 MAY share a common repository publication point, in which case there 455 will be one manifest associated with each active EE that is 456 publishing into the common repository publication point. 458 6. Relying Party Use of Manifests 460 The goal of an RP is to determine which signed objects to use for 461 validating assertions about INRs and their use (e.g., which ROAs to 462 use in the construction of route filters). Ultimately, this 463 selection is a matter of local policy. However, in the following 464 sections, we describe a sequence of tests that the RP SHOULD perform 465 to determine the manifest state of the given publication point. We 466 then discuss the risks associated with using signed objects in the 467 publication point, given the manifest state; we also provide suitable 468 warning text that SHOULD be placed in a user-accessible log file. It 469 is the responsibility of the RP to weigh these risks against the risk 470 of routing failure that could occur if valid data is rejected, and to 471 implement a suitable local policy. Note that if a certificate is 472 deemed unfit for use due to local policy, then any signed object that 473 is validatable using this certificate also SHOULD be deemed unfit for 474 use (regardless of the status of the manifest at its own publication 475 point). 477 6.1. Tests for Determining Manifest State 479 For a given publication point, the RP SHOULD perform the following 480 tests to determine the manifest state of the publication point: 482 1. For each entity using this publication point, select the entity's 483 current manifest (The "current" manifest is the manifest issued 484 by this CA having highest manifestNumber among all valid 485 manifests, and where manifest validity is defined in 486 Section 4.4). 488 1. If the publication point does not contain a valid manifest, 489 see Section Section 6.2. Lacking a valid manifest, the 490 following tests cannot be performed. 492 2. Check that the current time (translated to UTC) is between 493 thisUpdate and nextUpdate. 495 1. If the current time does not lie within this interval then 496 see Section 6.4, but still continue with the following tests. 498 3. Check that every file at the publication point appears in one and 499 only one current manifest, and that every file listed in each 500 current manifest that is published at this publication point also 501 is published at the publication point. 503 1. If there exist files at the publication point that do not 504 appear on any manifest, or files listed in a manifest that do 505 not appear at the publication point then see Section 6.5, but 506 still continue with the following test. 508 4. Verify that listed hash value of every file listed in each 509 manifest matches the value obtained by hashing the file at the 510 publication point. 512 1. If the computed hash value of a file listed on the manifest 513 does not match the hash value contained in the manifest, then 514 see Section 6.6. 516 5. Check that the contents of each current manifest conforms to the 517 manifest's scope constraints, as specified in Section 2. 519 1. If a current manifest contains entries for objects that are 520 not within the scope of the manifest, then the out-of-scope 521 entries SHOULD be disregarded in the context of this 522 manifest. If there is no other current manifest that 523 describes these objects within that other manifest's scope, 524 then see Section 6.2. 526 For each signed object, if all of the following conditions hold: 528 * the manifest for its publication, and the associated 529 publication point, pass all of the above checks; 530 * the signed object is valid; and 531 * the manifests for every certificate on the certification path 532 used to validate the signed object, and the associated 533 publication points, pass all of the above checks; 534 then the RP can conclude that no attack against the repository system 535 has compromised the given signed object, and the signed object MUST 536 be treated as valid. 538 6.2. Missing Manifests 540 The absence of a current manifest at a publication point could occur 541 due to an error by the publisher or due to (malicious or accidental) 542 deletion or corruption of all valid manifests. 544 When no valid manifest is available, there is no protection against 545 attacks that delete signed objects or replay old versions of signed 546 objects. All signed objects at the publication point, and all 547 descendant objects that are validated using a certificate at this 548 publication point SHOULD be viewed as suspect, but MAY be used by the 549 RP, as per local policy. 551 The primary risk in using signed objects at this publication point is 552 that a superseded (but not stale) CRL would cause an RP to improperly 553 accept a revoked certificate as valid (and thus rely upon signed 554 objects that are validated using that certificate). This risk is 555 somewhat mitigated if the CRL for this publication point has a short 556 time between thisUpdate and nextUpdate (and the current time is 557 within this interval). The risk in discarding signed objects at this 558 publication point is that an RP may incorrectly discard a large 559 number of valid objects. This gives significant power to an 560 adversary that is able to delete a manifest at the publication point. 562 Regardless of whether signed objects from this publication are deemed 563 fit for use by an RP, this situation SHOULD result in a warning to 564 the effect that: "No manifest is available for , and 565 thus there may have been undetected deletions or replay substitutions 566 from the publication point." 568 In the case where an RP has access to a local cache of previously 569 issued manifests that are valid, the RP MAY use the most recently 570 previously issued valid manifests for this RPKI repository 571 publication collection in this case for each entity that publishes at 572 his publication point. 574 6.3. Invalid Manifests 576 The presence of an invalid manifest at a publication point could 577 occur due to an error by the publisher or due to (malicious or 578 accidental) corruption of a valid manifest. An invalid manifest MUST 579 never be used even if the manifestNumber is greater than that of 580 other valid manifests. 582 There are no risks associated with using signed objects at a 583 publication point containing an invalid manifest, provided that valid 584 manifests that collectively cover all the signed objects are also 585 present. 587 If an invalid manifest is present at a publication point that also 588 contains one or more valid manifests, this situation SHOULD result in 589 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 591 or an error by the publisher. Processing for this publication point 592 will continue using the most recent valid manifest(s)." 594 In the case where the RP has access to a local cache of previously 595 issued (valid) manifests, an RP MAY make use of that locally cached 596 data. Specifically, the RP use use the locally cached, most recent, 597 previously issued. valid manifest issued by the entity that (appears 598 to have) issued the invalid manifest. 600 6.4. Stale Manifests 602 A manifest is considered stale if the current time is after the 603 nextUpdate time for the manifest. This could be due to publisher 604 failure to promptly publish a new manifest, or due to (malicious or 605 accidental) corruption or suppression of a more recent manifest. 607 All signed objects at the publication point issued by the entity that 608 has published the stale manifest, and all descendant signed objects 609 that are validated using a certificate issued by the entity that has 610 published the stale manifest at this publication point SHOULD be 611 viewed as somewhat suspect, but MAY be used by the RP as per local 612 policy. 614 The primary risk in using such signed objects is that a newer 615 manifest exists that, if present, would indicate that certain objects 616 are have been removed or replaced. (For example, the new manifest 617 might show the existence of a newer CRL and the removal of one or 618 more revoked certificates). Thus, the use of objects from a stale 619 manifest may cause an RP to incorrectly treat invalid objects as 620 valid. The risk is that the CRL covered by the stale manifest has 621 been superseded, and thus an RP will to improperly treat improperly 622 treat a revoked certificate as valid. This risk is somewhat 623 mitigated if the time between the nextUpdate field of the manifest 624 and the current time is short. The risk in discarding signed objects 625 at this publication point is that the RP may incorrectly discard a 626 large number of valid objects. This gives significant power to an 627 adversary that is able to prevent the publication of a new manifest 628 at a given publication point. 630 Regardless of whether signed objects from this publication are deemed 631 fit for use by an RP, this situation SHOULD result in a warning to 632 the effect that: "A manifest found at is no longer 633 current. It is possible that undetected deletions have occurred at 634 this publication point." 636 Note that there is also the potential for the current time to be 637 before the thisUpdate time for the manifest. This case could be due 638 to publisher error, or a local clock error, and in such a case this 639 situation SHOULD result in a warning to the effect that: "A manifest 640 found at has an incorrect thisUpdate field. This 641 could be due to publisher error, or a local clock error, and 642 processing for this publication point will continue using this 643 otherwise valid manifest." 645 6.5. Mismatch between Manifest and Publication Point 647 If there exist valid signed objects that do not appear in any 648 manifest, then, provided the manifest is not stale (see Section 6.4) 649 it is likely that their omission is an error by the publisher. It is 650 also possible that this state could be the result of a (malicious or 651 accidental) replacement of a current manifest with an older, but 652 still valid manifest. However, regarding the appropriate 653 interpretation such objects, it remains the case that if the objects 654 were intended to be invalid, then they should have been revoked using 655 whatever revocation mechanism is appropriate for the signed object in 656 question.) Therefore, there is little risk in using such signed 657 objects. If the publication point contains a stale manifest, then 658 there is a greater risk that the objects in question were revoked, 659 along with a missing Certificate Revocation List (CRL), the absence 660 of which is undetectable since the manifest is stale. In any case, 661 the use of signed objects not present on a manifest, or descendant 662 objects that are validated using such signed objects, is a matter of 663 local policy. 665 Regardless of whether objects not appearing on a manifest are deemed 666 fit for use by the RP, this situation SHOULD result in a warning to 667 the effect that: "The following files are present in the repository 668 at , but are not listed on any manifest 669 for ." 671 If there exists files listed on the manifest that do not appear in 672 the repository, then these objects are likely to have been improperly 673 (via malice or accident) deleted from the repository. A primary 674 purpose of manifests is to detect such deletions. Therefore, in such 675 a case this situation SHOULD result in a warning to the effect that: 676 "The following files that should have been present in the repository 677 at , are missing . This indicates an 678 attack against this publication point, or the repository, or an error 679 by the publisher." 681 6.6. Hash Values Not Matching Manifests 683 A file appearing on a manifest with an incorrect hash value could 684 occur because of publisher error, but it also may indicate that an 685 attack has occurred. 687 If an object appeared on a previous valid manifest with a correct 688 hash value, and it now appears with an invalid hash value, then it is 689 likely that the object has been superseded by a new (unavailable) 690 version of the object. If the object is used, there is a risk that 691 the RP will be treating a stale object as valid. This risk is more 692 significant if the object in question is a CRL. If the object can be 693 validated using the RPKI, the use of these objects is a matter of 694 local policy. 696 If an object appears on a manifest with an invalid hash and has never 697 previously appeared on a manifest, then it is unclear whether the 698 available version of the object is more or less recent than the 699 version indicated by the manifest. If the manifest is stale (see 700 Section 6.4), then it becomes more likely that the available version 701 is more recent that the version indicated on the manifest, but this 702 is never certain. Whether to use such objects is a matter of local 703 policy. However, in general, it is better to use a possibly outdated 704 version of the object than to discard the object completely. 706 While it is a matter of local policy, in the case of CRLs, an RP 707 SHOULD endeavour to use the most recently issued valid CRL, even 708 where the hash value in the manifest matches an older CRL, or does 709 not match any available CRL for a CA instance. The thisUpdate field 710 of the CRL can be used to establish the most recent CRL in the case 711 where an RP has more than one valid CRL for a CA instance. 713 Regardless of whether objects with incorrect hashes are deemed fit 714 for use by the RP, this situation SHOULD result in a warning to the 715 effect that: "The following files at the repository 716 appear on a manifest with incorrect hash values . It is 717 possible that these objects have been superseded by a more recent 718 version. It is very likely that this problem is due to an attack on 719 the publication point, although it also could be due to a publisher 720 error." 722 7. Publication Repositories 724 The RPKI publication system model requires that every publication 725 point be associated with one or more CAs or one or more EEs, and be 726 non-empty. Upon creation of the publication point associated with a 727 CA, the CA MUST create and publish a manifest as well as a CRL. The 728 manifest will contain at least one entry, the CRL issued by the CA 729 upon repository creation. Upon the creation of the publication point 730 associated with an EE, the EE MUST create and publish a manifest. 731 The manifest in an otherwise empty repository publication point 732 associated with an EE will contain no entries in the manifest's 733 fileList sequence (i.e., the ASN.1 SEQUENCE will have a length of 734 zero) [ID.ietf-sidr-repos-struct]. 736 For each signed object, the EE certificate used to verify the 737 object's signature is either a single-use certificate, or a multi-use 738 certificate. In the case of a single-use EE certificate, the signed 739 object is published in the repository publication point of the CA 740 that issued the single use EE certificate, and is listed in the 741 manifest associated with that CA certificate. In the case where an 742 EE certificate is used to verify multiple objects, each signed object 743 is published in the EE certificate's repository publication point and 744 listed in the manifest associated with the EE certificate. 746 8. Security Considerations 748 Manifests provide an additional level of protection for RPKI RPs. 750 Manifests can assist a RP to determine if a repository object has 751 been deleted, occluded or otherwise removed from view, or if a 752 publication of a newer version of an object has been suppressed (and 753 an older version of the object has been substituted). 755 Manifests cannot repair the effects of such forms of corruption of 756 repository retrieval operations. However, a manifest enables an RP 757 to determine if a locally maintained copy of a repository is a 758 complete and up to date copy, even when the repository retrieval 759 operation is conducted over an insecure channel. In cases where the 760 manifest and the retrieved repository contents differ, the manifest 761 can assist in determining which repository objects form the 762 difference set in terms of missing, extraneous or superseded objects. 764 The signing structure of a manifest and the use of the nextUpdate 765 value allows an RP to determine if the manifest itself is the subject 766 of attempted alteration. The requirement for every repository 767 publication point to contain at least one manifest allows a RP to 768 determine is the manifest itself has been occluded from view. Such 769 attacks against the manifest are detectable within the time frame of 770 the regular schedule of manifest updates. Forms of replay attack 771 within finer-grained time frames are not necessarily detectable by 772 the manifest structure . 774 9. IANA Considerations 776 [Note to IANA, to be removed prior to publication: there are no IANA 777 considerations stated in this version of the document.] 779 10. Acknowledgements 781 The authors would like to acknowledge the contributions from George 782 Michelson and Randy Bush in the preparation of the manifest 783 specification. Additionally, the authors would like to thank Mark 784 Reynolds and Christopher Small for assistance in clarifying manifest 785 validation and RP behaviour. The authors also wish to thank Sean 786 Turner for his helpful of this document. 788 11. References 790 11.1. Normative References 792 [I-D.sidr-res-certs] 793 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 794 X.509 PKIX Resource Certificates", 795 draft-ietf-sidr-res-certs-16.txt (work in progress), 796 February 2009. 798 [ID.ietf-sidr-repos-struct] 799 Huston, G., Loomans, R., and G. Michaleson, "A Profile for 800 Resource Certificate Repository Structure", 801 draft-ietf-sidr-repos-struct-04.txt (work in progress), 802 May 2010. 804 [ID.ietf-sidr-rpki-algs] 805 Huston, G., "A Profile for Algorithms and Key Sizes for 806 use in the Resource Public Key Infrastructure", 807 draft-huston-sidr-rpki-algs-00.txt (work in progress), 808 July 2009. 810 [ID.sidr-signed-object] 811 Lepinski, M., Chi, A., and S. Kent, "Signed Object 812 Template for the Resource Public Key Infrastructure", 813 draft-ietf-sidr-signed-object-01.txt (work in progress), 814 October 2010. 816 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 817 Housley, R., and W. Polk, "Internet X.509 Public Key 818 Infrastructure Certificate and Certificate Revocation List 819 (CRL) Profile", RFC 5280, May 2008. 821 11.2. Informative References 823 [ID.ietf-sidr-arch] 824 Lepinski, M. and S. Kent, "An Infrastructure to Support 825 Secure Internet Routing", draft-ietf-sidr-arch-11.txt 826 (work in progress), September 2010. 828 [ID.sidr-keyroll] 829 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 830 in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in 831 progress), October 2010. 833 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 834 Addresses and AS Identifiers", RFC 3779, June 2004. 836 Appendix A. ASN.1 Module 838 RPKIManifest { iso(1) identified-organization(3) 839 dod(6) internet(1) security(5) mechanisms(5) smime(7) 840 mod(0) TBD } 842 DEFINITIONS EXPLICIT TAGS ::= 844 BEGIN 846 -- EXPORTS ALL -- 848 -- IMPORTS NOTHING -- 850 -- Manifest Content Type: OID 852 yid-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 853 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 855 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 857 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 859 -- Manifest Content Type: eContent 861 Manifest ::= SEQUENCE { 862 version [0] INTEGER DEFAULT 0, 863 manifestNumber INTEGER (0..MAX), 864 thisUpdate GeneralizedTime, 865 nextUpdate GeneralizedTime, 866 fileHashAlg OBJECT IDENTIFIER, 867 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 868 } 870 FileAndHash ::= SEQUENCE { 871 file IA5String, 872 hash BIT STRING 873 } 875 END 877 Authors' Addresses 879 Rob Austein 880 Internet Systems Consortium 881 950 Charter St. 882 Redwood City, CA 94063 883 USA 885 Email: sra@isc.org 887 Geoff Huston 888 Asia Pacific Network Information Centre 889 33 Park Rd. 890 Milton, QLD 4064 891 Australia 893 Email: gih@apnic.net 894 URI: http://www.apnic.net 896 Stephen Kent 897 BBN Technologies 898 10 Moulton St. 899 Cambridge, MA 02138 900 USA 902 Email: kent@bbn.com 904 Matt Lepinski 905 BBN Technologies 906 10 Moulton St. 907 Cambridge, MA 02138 908 USA 910 Email: mlepinski@bbn.com