idnits 2.17.1 draft-ietf-sidr-rpki-manifests-09.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 (November 9, 2010) is 4909 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 802 == 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: May 13, 2011 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 November 9, 2010 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-09.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 May 13, 2011. 48 Copyright Notice 49 Copyright (c) 2010 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 EE certificates issued by this 126 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 Where an EE certificate is placed in the Cryptographic Message Syntax 155 (CMS) wrapper of a published RPKI signed object 156 [ID.sidr-signed-object] there is no requirement to separately publish 157 the EE certificate in the CA's repository publication point. 159 Where multiple CA instances share a common publication point, as can 160 occur when an entity performs a key-rollover operation 161 [ID.sidr-keyroll], the repository publication point will contain 162 multiple manifests. In this case, each manifest describes only the 163 collection of published products of its associated CA instance. 165 3. Manifest Signing 167 A CA's manifest is verified using an EE certificate The SIA field of 168 this EE certificate contains the access method OID of id-ad- 169 signedObject. 171 The CA MAY chose to sign only one manifest with each generated 172 private key, and generate a new key pair for each new version of the 173 manifest. This form of use of the associated EE certificate is 174 termed a "one-time-use" EE certificate. 176 Alternatively, the CA MAY elect to use the same private key to sign a 177 sequence of manifests. Because only a single manifest (issued under 178 a single CA instance) is current at any point in time, the associated 179 EE certificate is used to verify only a single object at a time. As 180 long as the sequence of objects verified by this EE certificate are 181 published using the same file name, then this sequential, multiple 182 use of this EE certificate is also valid. This form of use of a EE 183 certificate is termed a "sequential-use" EE certificate. 185 4. Manifest Definition 187 A manifest is an RPKI signed object, as specified in 188 [ID.sidr-signed-object]. The RPKI signed object template requires 189 specification of the following data elements in the context of the 190 manifest structure. 192 4.1. eContentType 194 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 195 has the numerical value of 1.2.840.113549.1.9.16.1.26. 197 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 198 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 200 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 202 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 204 4.2. eContent 206 The content of a Manifest is defined as follows: 208 Manifest ::= SEQUENCE { 209 version [0] INTEGER DEFAULT 0, 210 manifestNumber INTEGER (0..MAX), 211 thisUpdate GeneralizedTime, 212 nextUpdate GeneralizedTime, 213 fileHashAlg OBJECT IDENTIFIER, 214 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 215 } 217 FileAndHash ::= SEQUENCE { 218 file IA5String, 219 hash BIT STRING 220 } 222 4.2.1. Manifest 224 The manifestNumber, thisUpdate, and nextUpdate fields are modelled 225 after the corresponding fields in X.509 CRLs (see [RFC5280]). 226 Analogous to CRLs, a manifest is nominally current until the time 227 specified in nextUpdate or until a manifest is issued with a greater 228 manifest number, whichever comes first. 230 If a "one-time-use" EE certificate is employed to verify a manifest, 231 the EE certificate MUST have an validity period that coincides with 232 the interval from thisUpdate to nextUpdate, to prevent needless 233 growth of the CA's CRL. 235 If a "sequential-use" EE certificate is employed to verify a 236 manifest, the EE certificate's validity period needs to be no shorter 237 than the nextUpdate time of the current manifest. The extended 238 validity time raises the possibility of a substitution attack using a 239 stale manifest, as described in Section 6.4. 241 The data elements of the Manifest structure are defined as follows: 243 version: 244 The version number of this version of the manifest specification 245 MUST be 0. 247 manifestNumber: 248 This field is an integer that is incremented each time a new 249 manifest is issued for a given publication point. This field 250 allows an RP to detect gaps in a sequence of published manifest. 252 As the manifest is modelled on the CRL specification, the 253 ManifestNumber is analogous to the CRLNumber, and the guidance in 254 [RFC5280] for CRLNumber values is appropriate as to the range of 255 number values that can be used for the manifestNumber. Manifest 256 numbers can be expected to contain long integers. Manifest 257 verifiers MUST be able to handle number values up to 20 octets. 258 Conforming Manifest issuers MUST NOT use number values longer than 259 20 octets 261 thisUpdate: 262 This field contains the time when the manifest was created. This 263 field has the same format constraints as specified in [RFC5280] 264 for the CRL field of the same name. 266 nextUpdate: 267 This field contains the time at which the next scheduled manifest 268 will be issued. The value of nextUpdate MUST be later than the 269 value of thisUpdate. The specification of the GeneralizedTime 270 value is the same as required for the thisUpdate field. 272 If the authority alters any of the items that it has published in 273 the repository publication point, then the authority MUST issue a 274 new manifest before the nextUpdate time. If a manifest 275 encompasses a CRL, the nextUpdate field of the manifest MUST match 276 that of the CRL's nextUpdate field, as the manifest will be re- 277 issued when a new CRL is published. If a "one-time-use" EE 278 certificate is used to verify the manifest, then when a new 279 manifest is issued before the time specified in nextUpdate of the 280 current manifest, the CA MUST also issue a new CRL that includes 281 the EE certificate corresponding to the old manifest. 283 fileHashAlg: 284 This field contains the OID of the hash algorithm used to hash the 285 files that the authority has placed into the repository. The hash 286 algorithm used MUST conform to the RPKI Algorithms and Key Size 287 Profile specification [ID.ietf-sidr-rpki-algs]. 289 fileList: 290 This field is a sequence of FileAndHash objects. There is one 291 FileAndHash entry for each currently valid signed object that has 292 been published by the authority (at this publication point). Each 293 FileAndHash is an ordered pair consisting of the name of the file 294 in the repository publication point (directory) that contains the 295 object in question, and a hash of the file's contents. 297 4.3. ContentType Attribute 299 The mandatory Content-Type Attribute MUST have its attrValues field 300 set to the same OID as eContentType. This OID is id-ct-rpkiManifest, 301 and has the numerical value of 1.2.840.113549.1.9.16.1.26. 303 4.4. Manifest Validation 305 To determine whether a manifest is valid, the RP MUST perform the 306 following checks in addition to those specified in 307 [ID.sidr-signed-object]: 309 1. The eContentType in the EncapsulatedContentInfo is id-ad- 310 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 312 2. The version of the rpkiManifest is 0. 314 3. In the rpkiManifest, thisUpdate precedes nextUpdate. 316 If the above procedure indicates that the manifest is invalid, then 317 the manifest MUST be discarded and treated as though no manifest were 318 present. 320 5. Manifest Generation 322 5.1. Manifest Generation Procedure 324 For a CA publication point in the RPKI repository system, a CA MUST 325 perform the following steps to generate a manifest: 327 1. If no key pair exists, or if using a "one-time-use" EE 328 certificate with a new key pair, generate a key pair. 330 2. If using a "one-time-use" EE certificate, or if a key pair was 331 generated in step 1, issue a EE certificate for this key pair. 333 This EE certificate MUST have an SIA extension access 334 description field with an accessMethod OID value of id-ad- 335 signedobject where the associated accessLocation references 336 the publication point of the manifest as an object URL. 338 This EE certificate MUST describe its Internet Number 339 Resources (INRs) using the "inherit" attribute, rather than 340 explicit description of a resource set (see [RFC3779]). 342 In the case of a "one-time-use" EE certificate, the validity 343 times of the EE certificate MUST exactly match the thisUpdate 344 and nextUpdate times of the manifest. 346 In the case of a "sequential-use" EE certificate the validity 347 times of the EE certificate MUST encompass the time interval 348 from thisUpdate to nextUpdate. 350 3. The EE certificate MUST NOT be published in the authority's 351 repository publication point. 353 4. Construct the manifest content. 355 The manifest content is described in Section 4.2.1. The 356 manifest's fileList includes the file name and hash pair for each 357 object issued by this CA that has been published at this 358 repository publication point (directory). The collection of 359 objects to be included in the manifest includes all certificates 360 issued by this CA that are published at the CA's repository 361 publication point, the most recent CRL issued by the CA, and all 362 objects verified by EE certificates that were issued by this CA 363 that are published at this repository publication point. 365 Note that the manifest does not include a self reference (i.e., 366 its own file name and hash), since it would be impossible to 367 compute the hash of the manifest itself prior to it being signed. 369 5. Encapsulate the manifest content using the CMS SignedData content 370 type (as specified Section 4), sign the manifest using the 371 private key corresponding to the subject key contained in the EE 372 certificate, and publish the manifest in repository system 373 publication point that is described by the manifest. 375 6. In the case of a key pair that is to be used only once, in 376 conjunction with a "one-time-use" EE certificate, the private key 377 associated with this key pair SHOULD now be destroyed. 379 5.2. Considerations for Manifest Generation 381 A new manifest MUST be issued on or before the nextUpdate time. 383 An authority MUST issue a new manifest in conjunction with the 384 finalization of changes made to objects in the publication point. An 385 authority MAY perform a number of object operations on a publication 386 repository within the scope of a repository change before issuing a 387 single manifest that covers all the operations within the scope of 388 this change. Repository operators SHOULD implement some form of 389 repository update procedure that mitigates, to the extent possible, 390 the risk that RPs who are performing retrieval operations on the 391 repository are exposed to inconsistent transient intermediate states 392 during updates to the repository publication point (directory) and 393 the associated manifest. 395 Since the manifest object URL is included in the SIA of issued 396 Certificates, a new manifest MUST NOT invalidate the manifest object 397 URL of previously issued certificates. This implies that the 398 manifest's publication name in the repository, in the form of an 399 object URL, is unchanged across manifest generation cycles. 401 When a CA entity is performing a key rollover, the entity MAY chose 402 to have two CAs instances simultaneously publishing intot he same 403 repository publication point. In this case there will be one 404 manifest associated with each active CA instance that is publishing 405 into the common repository publication point (directory). 407 6. Relying Party Use of Manifests 409 The goal of an RP is to determine which signed objects to use for 410 validating assertions about INRs and their use (e.g., which ROAs to 411 use in the construction of route filters). Ultimately, this 412 selection is a matter of local policy. However, in the following 413 sections, we describe a sequence of tests that the RP SHOULD perform 414 to determine the manifest state of the given publication point. We 415 then discuss the risks associated with using signed objects in the 416 publication point, given the manifest state; we also provide suitable 417 warning text that SHOULD be placed in a user-accessible log file. It 418 is the responsibility of the RP to weigh these risks against the risk 419 of routing failure that could occur if valid data is rejected, and to 420 implement a suitable local policy. Note that if a certificate is 421 deemed unfit for use due to local policy, then any signed object that 422 is validated using this certificate also SHOULD be deemed unfit for 423 use (regardless of the status of the manifest at its own publication 424 point). 426 6.1. Tests for Determining Manifest State 428 For a given publication point, the RP SHOULD perform the following 429 tests to determine the manifest state of the publication point: 431 1. For each CA using this publication point, select the CA's current 432 manifest (The "current" manifest is the manifest issued by this 433 CA having highest manifestNumber among all valid manifests, and 434 where manifest validity is defined in Section 4.4). 436 If the publication point does not contain a valid manifest, see 437 Section 6.2. Lacking a valid manifest, the following tests 438 cannot be performed. 440 2. To verify completness, an RP MAY check that every file at each 441 publication point appears in one and only one current manifest, 442 and that every file listed in a current manifest that is 443 published at the same publication point as the manifest. 445 If there exist files at the publication point that do not appear 446 on any manifest, or files listed in a manifest that do not appear 447 at the publication point then see Section 6.5, but still continue 448 with the following test. 450 3. Check that the current time (translated to UTC) is between 451 thisUpdate and nextUpdate. 453 If the current time does not lie within this interval then see 454 Section 6.4, but still continue with the following tests. 456 4. Verify that listed hash value of every file listed in each 457 manifest matches the value obtained by hashing the file at the 458 publication point. 460 If the computed hash value of a file listed on the manifest does 461 not match the hash value contained in the manifest, then see 462 Section 6.6. 464 5. An RP MAY check that the contents of each current manifest 465 conforms to the manifest's scope constraints, as specified in 466 Section 2. 468 If a current manifest contains entries for objects that are not 469 within the scope of the manifest, then the out-of-scope entries 470 SHOULD be disregarded in the context of this manifest. If there 471 is no other current manifest that describes these objects within 472 that other manifest's scope, then see Section 6.2. 474 For each signed object, if all of the following conditions hold: 476 * the manifest for its publication, and the associated 477 publication point, pass all of the above checks; 479 * the signed object is valid; and 481 * the manifests for every certificate on the certification path 482 used to validate the signed object, and the associated 483 publication points, pass all of the above checks; 485 then the RP can conclude that no attack against the repository system 486 has compromised the given signed object, and the signed object MUST 487 be treated as valid. 489 6.2. Missing Manifests 491 The absence of a current manifest at a publication point could occur 492 due to an error by the publisher or due to (malicious or accidental) 493 deletion or corruption of all valid manifests. 495 When no valid manifest is available, there is no protection against 496 attacks that delete signed objects or replay old versions of signed 497 objects. All signed objects at the publication point, and all 498 descendant objects that are validated using a certificate at this 499 publication point SHOULD be viewed as suspect, but MAY be used by the 500 RP, as per local policy. 502 The primary risk in using signed objects at this publication point is 503 that a superseded (but not stale) CRL would cause an RP to improperly 504 accept a revoked certificate as valid (and thus rely upon signed 505 objects that are validated using that certificate). This risk is 506 somewhat mitigated if the CRL for this publication point has a short 507 time between thisUpdate and nextUpdate (and the current time is 508 within this interval). The risk in discarding signed objects at this 509 publication point is that an RP may incorrectly discard a large 510 number of valid objects. This gives significant power to an 511 adversary that is able to delete a manifest at the publication point. 513 Regardless of whether signed objects from this publication are deemed 514 fit for use by an RP, this situation SHOULD result in a warning to 515 the effect that: "No manifest is available for , and 516 thus there may have been undetected deletions or replay substitutions 517 from the publication point." 519 In the case where an RP has access to a local cache of previously 520 issued manifests that are valid, the RP MAY use the most recently 521 previously issued valid manifests for this RPKI repository 522 publication collection in this case for each entity that publishes at 523 his publication point. 525 6.3. Invalid Manifests 527 The presence of an invalid manifest at a publication point could 528 occur due to an error by the publisher or due to (malicious or 529 accidental) corruption of a valid manifest. An invalid manifest MUST 530 never be used even if the manifestNumber is greater than that of 531 other valid manifests. 533 There are no risks associated with using signed objects at a 534 publication point containing an invalid manifest, provided that valid 535 manifests that collectively cover all the signed objects are also 536 present. 538 If an invalid manifest is present at a publication point that also 539 contains one or more valid manifests, this situation SHOULD result in 540 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 542 or an error by the publisher. Processing for this publication point 543 will continue using the most recent valid manifest(s)." 545 In the case where the RP has access to a local cache of previously 546 issued (valid) manifests, an RP MAY make use of that locally cached 547 data. Specifically, the RP MAY use the locally cached, most recent, 548 previously issued. valid manifest issued by the entity that (appears 549 to have) issued the invalid manifest. 551 6.4. Stale Manifests 553 A manifest is considered stale if the current time is after the 554 nextUpdate time for the manifest. This could be due to publisher 555 failure to promptly publish a new manifest, or due to (malicious or 556 accidental) corruption or suppression of a more recent manifest. 558 All signed objects at the publication point issued by the entity that 559 has published the stale manifest, and all descendant signed objects 560 that are validated using a certificate issued by the entity that has 561 published the stale manifest at this publication point SHOULD be 562 viewed as somewhat suspect, but MAY be used by the RP as per local 563 policy. 565 The primary risk in using such signed objects is that a newer 566 manifest exists that, if present, would indicate that certain objects 567 are have been removed or replaced. (For example, the new manifest 568 might show the existence of a newer CRL and the removal of one or 569 more revoked certificates). Thus, the use of objects from a stale 570 manifest may cause an RP to incorrectly treat invalid objects as 571 valid. The risk is that the CRL covered by the stale manifest has 572 been superseded, and thus an RP will to improperly treat improperly 573 treat a revoked certificate as valid. This risk is somewhat 574 mitigated if the time between the nextUpdate field of the manifest 575 and the current time is short. The risk in discarding signed objects 576 at this publication point is that the RP may incorrectly discard a 577 large number of valid objects. This gives significant power to an 578 adversary that is able to prevent the publication of a new manifest 579 at a given publication point. 581 Regardless of whether signed objects from this publication are deemed 582 fit for use by an RP, this situation SHOULD result in a warning to 583 the effect that: "A manifest found at is no longer 584 current. It is possible that undetected deletions have occurred at 585 this publication point." 587 Note that there is also the potential for the current time to be 588 before the thisUpdate time for the manifest. This case could be due 589 to publisher error, or a local clock error, and in such a case this 590 situation SHOULD result in a warning to the effect that: "A manifest 591 found at has an incorrect thisUpdate field. This 592 could be due to publisher error, or a local clock error, and 593 processing for this publication point will continue using this 594 otherwise valid manifest." 596 6.5. Mismatch between Manifest and Publication Point 598 If there exist valid signed objects that do not appear in any 599 manifest, then, provided the manifest is not stale (see Section 6.4) 600 it is likely that their omission is an error by the publisher. It is 601 also possible that this state could be the result of a (malicious or 602 accidental) replacement of a current manifest with an older, but 603 still valid manifest. However, regarding the appropriate 604 interpretation such objects, it remains the case that if the objects 605 were intended to be invalid, then they should have been revoked using 606 whatever revocation mechanism is appropriate for the signed object in 607 question.) Therefore, there is little risk in using such signed 608 objects. If the publication point contains a stale manifest, then 609 there is a greater risk that the objects in question were revoked, 610 along with a missing Certificate Revocation List (CRL), the absence 611 of which is undetectable since the manifest is stale. In any case, 612 the use of signed objects not present on a manifest, or descendant 613 objects that are validated using such signed objects, is a matter of 614 local policy. 616 Regardless of whether objects not appearing on a manifest are deemed 617 fit for use by the RP, this situation SHOULD result in a warning to 618 the effect that: "The following files are present in the repository 619 at , but are not listed on any manifest 620 for ." 622 If there exists files listed on the manifest that do not appear in 623 the repository, then these objects are likely to have been improperly 624 (via malice or accident) deleted from the repository. A primary 625 purpose of manifests is to detect such deletions. Therefore, in such 626 a case this situation SHOULD result in a warning to the effect that: 627 "The following files that should have been present in the repository 628 at , are missing . This indicates an 629 attack against this publication point, or the repository, or an error 630 by the publisher." 632 6.6. Hash Values Not Matching Manifests 634 A file appearing on a manifest with an incorrect hash value could 635 occur because of publisher error, but it also may indicate that an 636 attack has occurred. 638 If an object appeared on a previous valid manifest with a correct 639 hash value, and it now appears with an invalid hash value, then it is 640 likely that the object has been superseded by a new (unavailable) 641 version of the object. If the object is used, there is a risk that 642 the RP will be treating a stale object as valid. This risk is more 643 significant if the object in question is a CRL. If the object can be 644 validated using the RPKI, the use of these objects is a matter of 645 local policy. 647 If an object appears on a manifest with an invalid hash and has never 648 previously appeared on a manifest, then it is unclear whether the 649 available version of the object is more or less recent than the 650 version indicated by the manifest. If the manifest is stale (see 651 Section 6.4), then it becomes more likely that the available version 652 is more recent that the version indicated on the manifest, but this 653 is never certain. Whether to use such objects is a matter of local 654 policy. However, in general, it is better to use a possibly outdated 655 version of the object than to discard the object completely. 657 While it is a matter of local policy, in the case of CRLs, an RP 658 SHOULD endeavour to use the most recently issued valid CRL, even 659 where the hash value in the manifest matches an older CRL, or does 660 not match any available CRL for a CA instance. The thisUpdate field 661 of the CRL can be used to establish the most recent CRL in the case 662 where an RP has more than one valid CRL for a CA instance. 664 Regardless of whether objects with incorrect hashes are deemed fit 665 for use by the RP, this situation SHOULD result in a warning to the 666 effect that: "The following files at the repository 667 appear on a manifest with incorrect hash values . It is 668 possible that these objects have been superseded by a more recent 669 version. It is very likely that this problem is due to an attack on 670 the publication point, although it also could be due to a publisher 671 error." 673 7. Publication Repositories 675 The RPKI publication system model requires that every publication 676 point be associated with one or more CAs, and be non-empty. Upon 677 creation of the publication point associated with a CA, the CA MUST 678 create and publish a manifest as well as a CRL. A CA's manifest will 679 always contain at least one entry, namely the CRL issued by the CA 680 upon repository creation. [ID.ietf-sidr-repos-struct]. 682 Every published signed object in the RPKI [ID.sidr-signed-object] is 683 published in the repository publication point of the CA that issued 684 the EE certificate, and is listed in the manifest associated with 685 that CA certificate. 687 8. Security Considerations 689 Manifests provide an additional level of protection for RPKI RPs. 690 Manifests can assist an RP to determine if a repository object has 691 been deleted, occluded or otherwise removed from view, or if a 692 publication of a newer version of an object has been suppressed (and 693 an older version of the object has been substituted). 695 Manifests cannot repair the effects of such forms of corruption of 696 repository retrieval operations. However, a manifest enables an RP 697 to determine if a locally maintained copy of a repository is a 698 complete and up to date copy, even when the repository retrieval 699 operation is conducted over an insecure channel. In cases where the 700 manifest and the retrieved repository contents differ, the manifest 701 can assist in determining which repository objects form the 702 difference set in terms of missing, extraneous or superseded objects. 704 The signing structure of a manifest and the use of the nextUpdate 705 value allows an RP to determine if the manifest itself is the subject 706 of attempted alteration. The requirement for every repository 707 publication point to contain at least one manifest allows an RP to 708 determine is the manifest itself has been occluded from view. Such 709 attacks against the manifest are detectable within the time frame of 710 the regular schedule of manifest updates. Forms of replay attack 711 within finer-grained time frames are not necessarily detectable by 712 the manifest structure . 714 9. IANA Considerations 716 [Note to IANA, to be removed prior to publication: there are no IANA 717 considerations stated in this version of the document.] 719 10. Acknowledgements 721 The authors would like to acknowledge the contributions from George 722 Michelson and Randy Bush in the preparation of the manifest 723 specification. Additionally, the authors would like to thank Mark 724 Reynolds and Christopher Small for assistance in clarifying manifest 725 validation and RP behaviour. The authors also wish to thank Sean 726 Turner for his helpful review of this document. 728 11. References 730 11.1. Normative References 732 [I-D.sidr-res-certs] 733 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 734 X.509 PKIX Resource Certificates", 735 draft-ietf-sidr-res-certs-16.txt (work in progress), 736 February 2009. 738 [ID.ietf-sidr-repos-struct] 739 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 740 Resource Certificate Repository Structure", 741 draft-ietf-sidr-repos-struct-04.txt (work in progress), 742 May 2010. 744 [ID.ietf-sidr-rpki-algs] 745 Huston, G., "A Profile for Algorithms and Key Sizes for 746 use in the Resource Public Key Infrastructure", 747 draft-huston-sidr-rpki-algs-00.txt (work in progress), 748 July 2009. 750 [ID.sidr-signed-object] 751 Lepinski, M., Chi, A., and S. Kent, "Signed Object 752 Template for the Resource Public Key Infrastructure", 753 draft-ietf-sidr-signed-object-01.txt (work in progress), 754 October 2010. 756 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 757 Housley, R., and W. Polk, "Internet X.509 Public Key 758 Infrastructure Certificate and Certificate Revocation List 759 (CRL) Profile", RFC 5280, May 2008. 761 11.2. Informative References 763 [ID.ietf-sidr-arch] 764 Lepinski, M. and S. Kent, "An Infrastructure to Support 765 Secure Internet Routing", draft-ietf-sidr-arch-11.txt 766 (work in progress), September 2010. 768 [ID.sidr-keyroll] 769 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 770 in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in 771 progress), October 2010. 773 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 774 Addresses and AS Identifiers", RFC 3779, June 2004. 776 Appendix A. ASN.1 Module 778 RPKIManifest { iso(1) identified-organization(3) 779 dod(6) internet(1) security(5) mechanisms(5) smime(7) 780 mod(0) TBD } 782 DEFINITIONS EXPLICIT TAGS ::= 784 BEGIN 786 -- EXPORTS ALL -- 788 -- IMPORTS NOTHING -- 790 -- Manifest Content Type: OID 792 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 793 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 795 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 797 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 799 -- Manifest Content Type: eContent 801 Manifest ::= SEQUENCE { 802 version [0] INTEGER DEFAULT 0, 803 manifestNumber INTEGER (0..MAX), 804 thisUpdate GeneralizedTime, 805 nextUpdate GeneralizedTime, 806 fileHashAlg OBJECT IDENTIFIER, 807 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 808 } 810 FileAndHash ::= SEQUENCE { 811 file IA5String, 812 hash BIT STRING 813 } 815 END 817 Authors' Addresses 819 Rob Austein 820 Internet Systems Consortium 821 950 Charter St. 822 Redwood City, CA 94063 823 USA 825 Email: sra@isc.org 827 Geoff Huston 828 Asia Pacific Network Information Centre 829 33 Park Rd. 830 Milton, QLD 4064 831 Australia 833 Email: gih@apnic.net 834 URI: http://www.apnic.net 836 Stephen Kent 837 BBN Technologies 838 10 Moulton St. 839 Cambridge, MA 02138 840 USA 842 Email: kent@bbn.com 844 Matt Lepinski 845 BBN Technologies 846 10 Moulton St. 847 Cambridge, MA 02138 848 USA 850 Email: mlepinski@bbn.com