idnits 2.17.1 draft-ietf-sidr-rpki-manifests-16.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 (July 8, 2011) is 4669 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 820 == Missing Reference: 'RFCxxxx' is mentioned on line 733, but not defined == 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 == 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: 0 errors (**), 0 flaws (~~), 7 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: January 9, 2012 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 July 8, 2011 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-16.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 (file) that 18 contains a listing of all the signed objects (files) in the 19 repository publication point (directory) associated with an authority 20 responsible for publishing in the repository. For each certificate, 21 Certificate Revocation List (CRL), or other type of signed objects 22 issued by the authority, that are published at this repository 23 publication point, the manifest contains both the name of the file 24 containing the object, and a hash of the file content. Manifests are 25 intended to enable a relying party (RP) to detect certain forms of 26 attacks against a repository. Specifically, if an RP checks a 27 manifest's contents against the signed objects retrieved from a 28 repository publication point, then the RP can detect "stale" (valid) 29 data and deletion of signed objects. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 9, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Manifest Definition . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. eContentType . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.3. ContentType Attribute . . . . . . . . . . . . . . . . . . 7 73 4.4. Manifest Validation . . . . . . . . . . . . . . . . . . . 7 74 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 7 76 5.2. Considerations for Manifest Generation . . . . . . . . . . 9 77 6. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 9 78 6.1. Tests for Determining Manifest State . . . . . . . . . . . 10 79 6.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 11 80 6.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 12 81 6.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 12 82 6.5. Mismatch between Manifest and Publication Point . . . . . 13 83 6.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 14 84 7. Publication Repositories . . . . . . . . . . . . . . . . . . . 15 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 91 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 (files) in the repository publication point (directory) that are 112 associated with an authority responsible for publishing at that 113 publication point. Each manifest contains both the name of the file 114 containing the object, and a hash of the file content, for every 115 signed object issued by an authority that is published at the 116 authority's repository publication point. A manifest is intended to 117 allow an RP to detect unauthorized object removal, or the 118 substitution of "stale" versions of objects at a publication point. 119 A manifest also intended to allow an RP to detect similar outcomes 120 that may result from a man-in-the-middle attack on the retrieval of 121 objects from the repository. Manifests are intended to be used in 122 Certification Authority (CA) publication points in repositories 123 (directories containing files that are subordinate certificates and 124 Certificate Revocation Lists (CRLs) issued by this CA and other 125 signed objects that are verified by End Entity (EE) certificates 126 issued by this CA). 128 Manifests are modeled on CRLs, as the issues involved in detecting 129 stale manifests, and detection of potential attacks using manifest 130 replays, etc are similar to those for CRLs. The syntax of the 131 manifest payload differs from CRLs, since RPKI repositories contain 132 objects not covered by CRLs,e.g., digitally signed objects, such as 133 Route Origination Authorizations (ROAs). 135 1.1. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119. 141 2. Manifest Scope 143 A manifest associated with a CA's repository publication point 144 contains a list of: 146 * the set of (non-expired, non-revoked) certificates issued and 147 published by this CA, 149 * the most recent CRL issued by this CA, and 151 * all published signed objects that are verifiable using EE 152 certificates [I-D.sidr-res-certs], issued by this CA. 154 Every RPKI signed object includes, in the Cryptographic Message 155 Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used 156 to verify it [ID.sidr-signed-object]. Thus there is no requirement 157 to separately publish that EE certificate at the CA's repository 158 publication point. 160 Where multiple CA instances share a common publication point, as can 161 occur when an entity performs a key-rollover operation 162 [ID.sidr-keyroll], the repository publication point will contain 163 multiple manifests. In this case, each manifest describes only the 164 collection of published products of its associated CA instance. 166 3. Manifest Signing 168 A CA's manifest is verified using an EE certificate. The 169 SubjectInfoAccess (SIA) field of this EE certificate contains the 170 access method OID of id-ad-signedObject. 172 The CA MAY choose to sign only one manifest with each generated 173 private key, and generate a new key pair for each new version of the 174 manifest. This form of use of the associated EE certificate is 175 termed a "one-time-use" EE certificate. 177 Alternatively, the CA MAY elect to use the same private key to sign a 178 sequence of manifests. Because only a single manifest (issued under 179 a single CA instance) is current at any point in time, the associated 180 EE certificate is used to verify only a single object at a time. As 181 long as the sequence of objects verified by this EE certificate are 182 published using the same file name, then this sequential, multiple 183 use of this EE certificate is also valid. This form of use of a EE 184 certificate is termed a "sequential-use" EE certificate. 186 4. Manifest Definition 188 A manifest is an RPKI signed object, as specified in 189 [ID.sidr-signed-object]. The RPKI signed object template requires 190 specification of the following data elements in the context of the 191 manifest structure. 193 4.1. eContentType 195 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 196 has the numerical value of 1.2.840.113549.1.9.16.1.26. 198 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 199 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 201 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 203 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 205 4.2. eContent 207 The content of a Manifest is defined as follows: 209 Manifest ::= SEQUENCE { 210 version [0] INTEGER DEFAULT 0, 211 manifestNumber INTEGER (0..MAX), 212 thisUpdate GeneralizedTime, 213 nextUpdate GeneralizedTime, 214 fileHashAlg OBJECT IDENTIFIER, 215 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 216 } 218 FileAndHash ::= SEQUENCE { 219 file IA5String, 220 hash BIT STRING 221 } 223 4.2.1. Manifest 225 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 226 after the corresponding fields in X.509 CRLs (see [RFC5280]). 227 Analogous to CRLs, a manifest is nominally current until the time 228 specified in nextUpdate or until a manifest is issued with a greater 229 manifest number, whichever comes first. 231 If a "one-time-use" EE certificate is employed to verify a manifest, 232 the EE certificate MUST have an validity period that coincides with 233 the interval from thisUpdate to nextUpdate, to prevent needless 234 growth of the CA's CRL. 236 If a "sequential-use" EE certificate is employed to verify a 237 manifest, the EE certificate's validity period needs to be no shorter 238 than the nextUpdate time of the current manifest. The extended 239 validity time raises the possibility of a substitution attack using a 240 stale manifest, as described in Section 6.4. 242 The data elements of the Manifest structure are defined as follows: 244 version: 245 The version number of this version of the manifest specification 246 MUST be 0. 248 manifestNumber: 249 This field is an integer that is incremented each time a new 250 manifest is issued for a given publication point. This field 251 allows an RP to detect gaps in a sequence of published manifests. 253 As the manifest is modeled on the CRL specification, the 254 ManifestNumber is analogous to the CRLNumber, and the guidance in 255 [RFC5280] for CRLNumber values is appropriate as to the range of 256 number values that can be used for the manifestNumber. Manifest 257 numbers can be expected to contain long integers. Manifest 258 verifiers MUST be able to handle number values up to 20 octets. 259 Conforming Manifest issuers MUST NOT use number values longer than 260 20 octets 262 thisUpdate: 263 This field contains the time when the manifest was created. This 264 field has the same format constraints as specified in [RFC5280] 265 for the CRL field of the same name. 267 nextUpdate: 268 This field contains the time at which the next scheduled manifest 269 will be issued. The value of nextUpdate MUST be later than the 270 value of thisUpdate. The specification of the GeneralizedTime 271 value is the same as required for the thisUpdate field. 273 If the authority alters any of the items that it has published in 274 the repository publication point, then the authority MUST issue a 275 new manifest before the nextUpdate time. If a manifest 276 encompasses a CRL, the nextUpdate field of the manifest MUST match 277 that of the CRL's nextUpdate field, as the manifest will be re- 278 issued when a new CRL is published. If a "one-time-use" EE 279 certificate is used to verify the manifest, then when a new 280 manifest is issued before the time specified in nextUpdate of the 281 current manifest, the CA MUST also issue a new CRL that includes 282 the EE certificate corresponding to the old manifest. 284 fileHashAlg: 285 This field contains the OID of the hash algorithm used to hash the 286 files that the authority has placed into the repository. The hash 287 algorithm used MUST conform to the RPKI Algorithms and Key Size 288 Profile specification [ID.ietf-sidr-rpki-algs]. 290 fileList: 291 This field is a sequence of FileAndHash objects. There is one 292 FileAndHash entry for each currently valid signed object that has 293 been published by the authority (at this publication point). Each 294 FileAndHash is an ordered pair consisting of the name of the file 295 in the repository publication point (directory) that contains the 296 object in question, and a hash of the file's contents. 298 4.3. ContentType Attribute 300 The mandatory Content-Type Attribute MUST have its attrValues field 301 set to the same OID as eContentType. This OID is id-ct-rpkiManifest, 302 and has the numerical value of 1.2.840.113549.1.9.16.1.26. 304 4.4. Manifest Validation 306 To determine whether a manifest is valid, the RP MUST perform the 307 following checks in addition to those specified in 308 [ID.sidr-signed-object]: 310 1. The eContentType in the EncapsulatedContentInfo is id-ad- 311 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 313 2. The version of the rpkiManifest is 0. 315 3. In the rpkiManifest, thisUpdate precedes nextUpdate. 317 If the above procedure indicates that the manifest is invalid, then 318 the manifest MUST be discarded and treated as though no manifest were 319 present. 321 5. Manifest Generation 323 5.1. Manifest Generation Procedure 325 For a CA publication point in the RPKI repository system, a CA MUST 326 perform the following steps to generate a manifest: 328 1. If no key pair exists, or if using a "one-time-use" EE 329 certificate with a new key pair, generate a key pair. 331 2. If using a "one-time-use" EE certificate, or if a key pair was 332 generated in step 1, or if using a "sequential-use" EE 333 certificate which will expire before the intended nextUpdate time 334 of this manifest, issue a EE certificate for this key pair. 336 This EE certificate MUST have an SIA extension access 337 description field with an accessMethod OID value of id-ad- 338 signedobject where the associated accessLocation references 339 the publication point of the manifest as an object URL. 341 This EE certificate MUST describe its Internet Number 342 Resources (INRs) using the "inherit" attribute, rather than 343 explicit description of a resource set (see [RFC3779]). 345 In the case of a "one-time-use" EE certificate, the validity 346 times of the EE certificate MUST exactly match the thisUpdate 347 and nextUpdate times of the manifest. 349 In the case of a "sequential-use" EE certificate the validity 350 times of the EE certificate MUST encompass the time interval 351 from thisUpdate to nextUpdate. 353 3. The EE certificate MUST NOT be published in the authority's 354 repository publication point. 356 4. Construct the manifest content. 358 The manifest content is described in Section 4.2.1. The 359 manifest's fileList includes the file name and hash pair for each 360 object issued by this CA that has been published at this 361 repository publication point (directory). The collection of 362 objects to be included in the manifest includes all certificates 363 issued by this CA that are published at the CA's repository 364 publication point, the most recent CRL issued by the CA, and all 365 objects verified by EE certificates that were issued by this CA 366 that are published at this repository publication point. 368 Note that the manifest does not include a self reference (i.e., 369 its own file name and hash), since it would be impossible to 370 compute the hash of the manifest itself prior to it being signed. 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 MUST now be destroyed. 382 5.2. Considerations for Manifest Generation 384 A new manifest MUST be issued and published on or before the 385 nextUpdate time. 387 An authority MUST issue a new manifest in conjunction with the 388 finalization of changes made to objects in the publication point. An 389 authority MAY perform a number of object operations on a publication 390 repository within the scope of a repository change before issuing a 391 single manifest that covers all the operations within the scope of 392 this change. Repository operators SHOULD implement some form of 393 repository update procedure that mitigates, to the extent possible, 394 the risk that RPs that are performing retrieval operations on the 395 repository are exposed to inconsistent transient intermediate states 396 during updates to the repository publication point (directory) and 397 the associated manifest. 399 Since the manifest object URL is included in the SIA of issued 400 Certificates, a new manifest MUST NOT invalidate the manifest object 401 URL of previously issued certificates. This implies that the 402 manifest's publication name in the repository, in the form of an 403 object URL, is unchanged across manifest generation cycles. 405 When a CA entity is performing a key rollover, the entity MAY choose 406 to have two CA instances simultaneously publishing into the same 407 repository publication point. In this case there will be one 408 manifest associated with each active CA instance that is publishing 409 into the common repository publication point (directory). 411 6. Relying Party Use of Manifests 413 The goal of an RP is to determine which signed objects to use for 414 validating assertions about INRs and their use (e.g., which ROAs to 415 use in the construction of route filters). Ultimately, this 416 selection is a matter of local policy. However, in the following 417 sections, we describe a sequence of tests that the RP SHOULD perform 418 to determine the manifest state of the given publication point. We 419 then discuss the risks associated with using signed objects in the 420 publication point, given the manifest state; we also provide suitable 421 warning text that SHOULD be placed in a user-accessible log file. It 422 is the responsibility of the RP to weigh these risks against the risk 423 of routing failure that could occur if valid data is rejected, and to 424 implement a suitable local policy. Note that if a certificate is 425 deemed unfit for use due to local policy, then any signed object that 426 is validated using this certificate also SHOULD be deemed unfit for 427 use (regardless of the status of the manifest at its own publication 428 point). 430 6.1. Tests for Determining Manifest State 432 For a given publication point, the RP SHOULD perform the following 433 tests to determine the manifest state of the publication point: 435 1. For each CA using this publication point, select the CA's current 436 manifest (The "current" manifest is the manifest issued by this 437 CA having highest manifestNumber among all valid manifests, and 438 where manifest validity is defined in Section 4.4). 440 If the publication point does not contain a valid manifest, see 441 Section 6.2. Lacking a valid manifest, the following tests 442 cannot be performed. 444 2. To verify completeness, an RP MAY check that every file at each 445 publication point appears in one and only one current manifest, 446 and that every file listed in a current manifest that is 447 published at the same publication point as the manifest. 449 If there exist files at the publication point that do not appear 450 on any manifest, or files listed in a manifest that do not appear 451 at the publication point then see Section 6.5, but still continue 452 with the following test. 454 3. Check that the current time (translated to UTC) is between 455 thisUpdate and nextUpdate. 457 If the current time does not lie within this interval then see 458 Section 6.4, but still continue with the following tests. 460 4. Verify that listed hash value of every file listed in each 461 manifest matches the value obtained by hashing the file at the 462 publication point. 464 If the computed hash value of a file listed on the manifest does 465 not match the hash value contained in the manifest, then see 466 Section 6.6. 468 5. An RP MAY check that the contents of each current manifest 469 conforms to the manifest's scope constraints, as specified in 470 Section 2. 472 6. If a current manifest contains entries for objects that are not 473 within the scope of the manifest, then the out-of-scope entries 474 SHOULD be disregarded in the context of this manifest. If there 475 is no other current manifest that describes these objects within 476 that other manifest's scope, then see Section 6.2. 478 For each signed object, if all of the following conditions hold: 480 * the manifest for its publication, and the associated 481 publication point, pass all of the above checks; 483 * the signed object is valid; and 485 * the manifests for every certificate on the certification path 486 used to validate the signed object, and the associated 487 publication points, pass all of the above checks; 489 then the RP can conclude that no attack against the repository system 490 has compromised the given signed object, and the signed object MUST 491 be treated as valid (relative to manifest checking). 493 6.2. Missing Manifests 495 The absence of a current manifest at a publication point could occur 496 due to an error by the publisher or due to (malicious or accidental) 497 deletion or corruption of all valid manifests. 499 When no valid manifest is available, there is no protection against 500 attacks that delete signed objects or replay old versions of signed 501 objects. All signed objects at the publication point, and all 502 descendant objects that are validated using a certificate at this 503 publication point SHOULD be viewed as suspect, but MAY be used by the 504 RP, as per local policy. 506 The primary risk in using signed objects at this publication point is 507 that a superseded (but not stale) CRL would cause an RP to improperly 508 accept a revoked certificate as valid (and thus rely upon signed 509 objects that are validated using that certificate). This risk is 510 somewhat mitigated if the CRL for this publication point has a short 511 time between thisUpdate and nextUpdate (and the current time is 512 within this interval). The risk in discarding signed objects at this 513 publication point is that an RP may incorrectly discard a large 514 number of valid objects. This gives significant power to an 515 adversary that is able to delete a manifest at the publication point. 517 Regardless of whether signed objects from this publication are deemed 518 fit for use by an RP, this situation SHOULD result in a warning to 519 the effect that: "No manifest is available for , and 520 thus there may have been undetected deletions or replay substitutions 521 from the publication point." 523 In the case where an RP has access to a local cache of previously 524 issued manifests that are valid, the RP MAY use the most recently 525 previously issued valid manifests for this RPKI repository 526 publication collection in this case for each entity that publishes at 527 this publication point. 529 6.3. Invalid Manifests 531 The presence of an invalid manifest at a publication point could 532 occur due to an error by the publisher or due to (malicious or 533 accidental) corruption of a valid manifest. An invalid manifest MUST 534 never be used, even if th manifestNumber of the invalid manifest is 535 greater that that of other (valid) manifests. 537 There are no risks associated with using signed objects at a 538 publication point containing an invalid manifest, provided that valid 539 manifests that collectively cover all the signed objects are also 540 present. 542 If an invalid manifest is present at a publication point that also 543 contains one or more valid manifests, this situation SHOULD result in 544 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 546 or an error by the publisher. Processing for this publication point 547 will continue using the most recent valid manifest(s)." 549 In the case where the RP has access to a local cache of previously 550 issued (valid) manifests, an RP MAY make use of that locally cached 551 data. Specifically, the RP MAY use the locally cached, most recent, 552 previously issued. valid manifest issued by the entity that (appears 553 to have) issued the invalid manifest. 555 6.4. Stale Manifests 557 A manifest is considered stale if the current time is after the 558 nextUpdate time for the manifest. This could be due to publisher 559 failure to promptly publish a new manifest, or due to (malicious or 560 accidental) corruption or suppression of a more recent manifest. 562 All signed objects at the publication point issued by the entity that 563 has published the stale manifest, and all descendant signed objects 564 that are validated using a certificate issued by the entity that has 565 published the stale manifest at this publication point SHOULD be 566 viewed as somewhat suspect, but MAY be used by the RP as per local 567 policy. 569 The primary risk in using such signed objects is that a newer 570 manifest exists that, if present, would indicate that certain objects 571 are have been removed or replaced. (For example, the new manifest 572 might show the existence of a newer CRL and the removal of one or 573 more revoked certificates). Thus, the use of objects from a stale 574 manifest may cause an RP to incorrectly treat invalid objects as 575 valid. The risk is that the CRL covered by the stale manifest has 576 been superseded, and thus an RP will to improperly treat improperly 577 treat a revoked certificate as valid. This risk is somewhat 578 mitigated if the time between the nextUpdate field of the manifest 579 and the current time is short. The risk in discarding signed objects 580 at this publication point is that the RP may incorrectly discard a 581 large number of valid objects. This gives significant power to an 582 adversary that is able to prevent the publication of a new manifest 583 at a given publication point. 585 Regardless of whether signed objects from this publication are deemed 586 fit for use by an RP, this situation SHOULD result in a warning to 587 the effect that: "A manifest found at is no longer 588 current. It is possible that undetected deletions have occurred at 589 this publication point." 591 Note that there is also the potential for the current time to be 592 before the thisUpdate time for the manifest. This case could be due 593 to publisher error, or a local clock error, and in such a case this 594 situation SHOULD result in a warning to the effect that: "A manifest 595 found at has an incorrect thisUpdate field. This 596 could be due to publisher error, or a local clock error, and 597 processing for this publication point will continue using this 598 otherwise valid manifest." 600 6.5. Mismatch between Manifest and Publication Point 602 If there exist valid signed objects that do not appear in any 603 manifest, then, provided the manifest is not stale (see Section 6.4) 604 it is likely that their omission is an error by the publisher. It is 605 also possible that this state could be the result of a (malicious or 606 accidental) replacement of a current manifest with an older, but 607 still valid manifest. However, regarding the appropriate 608 interpretation such objects, it remains the case that if the objects 609 were intended to be invalid, then they should have been revoked using 610 whatever revocation mechanism is appropriate for the signed object in 611 question.) Therefore, there is little risk in using such signed 612 objects. If the publication point contains a stale manifest, then 613 there is a greater risk that the objects in question were revoked, 614 along with a missing Certificate Revocation List (CRL), the absence 615 of which is undetectable since the manifest is stale. In any case, 616 the use of signed objects not present on a manifest, or descendant 617 objects that are validated using such signed objects, is a matter of 618 local policy. 620 Regardless of whether objects not appearing on a manifest are deemed 621 fit for use by the RP, this situation SHOULD result in a warning to 622 the effect that: "The following files are present in the repository 623 at , but are not listed on any manifest 624 for ." 626 If there exists files listed on the manifest that do not appear in 627 the repository, then these objects are likely to have been improperly 628 (via malice or accident) deleted from the repository. A primary 629 purpose of manifests is to detect such deletions. Therefore, in such 630 a case this situation SHOULD result in a warning to the effect that: 631 "The following files that should have been present in the repository 632 at , are missing . This indicates an 633 attack against this publication point, or the repository, or an error 634 by the publisher." 636 6.6. Hash Values Not Matching Manifests 638 A file appearing on a manifest with an incorrect hash value could 639 occur because of publisher error, but it also may indicate that an 640 attack has occurred. 642 If an object appeared on a previous valid manifest with a correct 643 hash value, and it now appears with an invalid hash value, then it is 644 likely that the object has been superseded by a new (unavailable) 645 version of the object. If the object is used, there is a risk that 646 the RP will be treating a stale object as valid. This risk is more 647 significant if the object in question is a CRL. If the object can be 648 validated using the RPKI, the use of these objects is a matter of 649 local policy. 651 If an object appears on a manifest with an invalid hash and has never 652 previously appeared on a manifest, then it is unclear whether the 653 available version of the object is more or less recent than the 654 version indicated by the manifest. If the manifest is stale (see 655 Section 6.4), then it becomes more likely that the available version 656 is more recent that the version indicated on the manifest, but this 657 is never certain. Whether to use such objects is a matter of local 658 policy. However, in general, it is better to use a possibly outdated 659 version of the object than to discard the object completely. 661 While it is a matter of local policy, in the case of CRLs, an RP 662 SHOULD endeavor to use the most recently issued valid CRL, even where 663 the hash value in the manifest matches an older CRL, or does not 664 match any available CRL for a CA instance. The thisUpdate field of 665 the CRL can be used to establish the most recent CRL in the case 666 where an RP has more than one valid CRL for a CA instance. 668 Regardless of whether objects with incorrect hashes are deemed fit 669 for use by the RP, this situation SHOULD result in a warning to the 670 effect that: "The following files at the repository 671 appear on a manifest with incorrect hash values . It is 672 possible that these objects have been superseded by a more recent 673 version. It is very likely that this problem is due to an attack on 674 the publication point, although it also could be due to a publisher 675 error." 677 7. Publication Repositories 679 The RPKI publication system model requires that every publication 680 point be associated with one or more CAs, and be non-empty. Upon 681 creation of the publication point associated with a CA, the CA MUST 682 create and publish a manifest as well as a CRL. A CA's manifest will 683 always contain at least one entry, namely the CRL issued by the CA 684 upon repository creation. [ID.ietf-sidr-repos-struct]. 686 Every published signed object in the RPKI [ID.sidr-signed-object] is 687 published in the repository publication point of the CA that issued 688 the EE certificate, and is listed in the manifest associated with 689 that CA certificate. 691 8. Security Considerations 693 Manifests provide an additional level of protection for RPKI RPs. 694 Manifests can assist an RP to determine if a repository object has 695 been deleted, occluded or otherwise removed from view, or if a 696 publication of a newer version of an object has been suppressed (and 697 an older version of the object has been substituted). 699 Manifests cannot repair the effects of such forms of corruption of 700 repository retrieval operations. However, a manifest enables an RP 701 to determine if a locally maintained copy of a repository is a 702 complete and up to date copy, even when the repository retrieval 703 operation is conducted over an insecure channel. In cases where the 704 manifest and the retrieved repository contents differ, the manifest 705 can assist in determining which repository objects form the 706 difference set in terms of missing, extraneous or superseded objects. 708 The signing structure of a manifest and the use of the nextUpdate 709 value allows an RP to determine if the manifest itself is the subject 710 of attempted alteration. The requirement for every repository 711 publication point to contain at least one manifest allows an RP to 712 determine is the manifest itself has been occluded from view. Such 713 attacks against the manifest are detectable within the time frame of 714 the regular schedule of manifest updates. Forms of replay attack 715 within finer-grained time frames are not necessarily detectable by 716 the manifest structure . 718 9. IANA Considerations 720 This document registers the following RPKI Signed Object in the 721 registry created by [ID.sidr-signed-object]: 723 Name: Manifest 724 OID: 1.2.840.113549.1.9.16.1.26 725 Reference: [RFCxxxx] (this document) 727 This document registers the following three-letter filename extension 728 for RPKI repository objects in the registry created by 729 [ID.ietf-sidr-repos-struct]: 731 Filename extensionL mft 732 RPKI Object : Manifest 733 Reference: [RFCxxxx] (this document) 735 10. Acknowledgements 737 The authors would like to acknowledge the contributions from George 738 Michelson and Randy Bush in the preparation of the manifest 739 specification. Additionally, the authors would like to thank Mark 740 Reynolds and Christopher Small for assistance in clarifying manifest 741 validation and RP behavior. The authors also wish to thank Sean 742 Turner for his helpful review of this document. 744 11. References 746 11.1. Normative References 748 [I-D.sidr-res-certs] 749 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 750 X.509 PKIX Resource Certificates", 751 draft-ietf-sidr-res-certs-16.txt (work in progress), 752 February 2009. 754 [ID.ietf-sidr-repos-struct] 755 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 756 Resource Certificate Repository Structure", 757 draft-ietf-sidr-repos-struct-04.txt (work in progress), 758 May 2010. 760 [ID.ietf-sidr-rpki-algs] 761 Huston, G., "A Profile for Algorithms and Key Sizes for 762 use in the Resource Public Key Infrastructure", 763 draft-ietf-sidr-rpki-algs-05.txt (work in progress), 764 April 2011. 766 [ID.sidr-signed-object] 767 Lepinski, M., Chi, A., and S. Kent, "Signed Object 768 Template for the Resource Public Key Infrastructure", 769 draft-ietf-sidr-signed-object-01.txt (work in progress), 770 October 2010. 772 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 773 Housley, R., and W. Polk, "Internet X.509 Public Key 774 Infrastructure Certificate and Certificate Revocation List 775 (CRL) Profile", RFC 5280, May 2008. 777 11.2. Informative References 779 [ID.ietf-sidr-arch] 780 Lepinski, M. and S. Kent, "An Infrastructure to Support 781 Secure Internet Routing", draft-ietf-sidr-arch-11.txt 782 (work in progress), September 2010. 784 [ID.sidr-keyroll] 785 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 786 in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in 787 progress), October 2010. 789 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 790 Algorithms", RFC 3370, August 2002. 792 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 793 Addresses and AS Identifiers", RFC 3779, June 2004. 795 Appendix A. ASN.1 Module 797 RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) 798 pkcs(1) pkcs9(9) smime(16) mod(0) 60 } 800 DEFINITIONS EXPLICIT TAGS ::= 802 BEGIN 804 -- EXPORTS ALL -- 806 -- IMPORTS NOTHING -- 808 -- Manifest Content Type: OID 810 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 811 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 813 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 815 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 817 -- Manifest Content Type: eContent 819 Manifest ::= SEQUENCE { 820 version [0] INTEGER DEFAULT 0, 821 manifestNumber INTEGER (0..MAX), 822 thisUpdate GeneralizedTime, 823 nextUpdate GeneralizedTime, 824 fileHashAlg OBJECT IDENTIFIER, 825 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 826 } 828 FileAndHash ::= SEQUENCE { 829 file IA5String, 830 hash BIT STRING 831 } 833 END 835 Authors' Addresses 837 Rob Austein 838 Internet Systems Consortium 839 950 Charter St. 840 Redwood City, CA 94063 841 USA 843 Email: sra@isc.org 845 Geoff Huston 846 Asia Pacific Network Information Centre 847 6 Cordelia St 848 South Brisbane, QLD 4101 849 Australia 851 Email: gih@apnic.net 852 URI: http://www.apnic.net 854 Stephen Kent 855 BBN Technologies 856 10 Moulton St. 857 Cambridge, MA 02138 858 USA 860 Email: kent@bbn.com 862 Matt Lepinski 863 BBN Technologies 864 10 Moulton St. 865 Cambridge, MA 02138 866 USA 868 Email: mlepinski@bbn.com