idnits 2.17.1 draft-ietf-sidr-rpki-manifests-10.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 (April 13, 2011) is 4755 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: October 15, 2011 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 April 13, 2011 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-10.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 October 15, 2011. 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 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 allows an RP to 117 detect unauthorized object removal, or the substitution of "stale" 118 versions of objects at a publication point. A manifest also intended 119 to allow an RP to detect similar outcomes that may result from a man- 120 in-the middle attack on the retrieval of objects from the repository. 121 Manifests are intended to be used in Certification Authority (CA) 122 publication points in repositories (directories containing files that 123 are subordinate certificates and Certificate Revocation Lists (CRLs) 124 issued by this CA and other signed objects that are verified by End 125 Entity (EE) certificates issued by this CA). 127 Manifests are modeled 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 a list of: 145 * the set of (non-expired, non-revoked) certificates issued and 146 published by this CA, 148 * the most recent CRL issued by this CA, and 150 * all published signed objects that are verifiable using EE 151 certificates [I-D.sidr-res-certs], issued by this CA. 153 Where an EE certificate is placed in the Cryptographic Message Syntax 154 (CMS) wrapper of a published RPKI signed object 155 [ID.sidr-signed-object] there is no requirement to separately publish 156 the EE certificate in the CA's repository publication point. 158 Where multiple CA instances share a common publication point, as can 159 occur when an entity performs a key-rollover operation 160 [ID.sidr-keyroll], the repository publication point will contain 161 multiple manifests. In this case, each manifest describes only the 162 collection of published products of its associated CA instance. 164 3. Manifest Signing 166 A CA's manifest is verified using an EE certificate The 167 SubjectInfoAccess (SIA) field of this EE certificate contains the 168 access method OID of id-ad-signedObject. 170 The CA MAY chose to sign only one manifest with each generated 171 private key, and generate a new key pair for each new version of the 172 manifest. This form of use of the associated EE certificate is 173 termed a "one-time-use" EE certificate. 175 Alternatively, the CA MAY elect to use the same private key to sign a 176 sequence of manifests. Because only a single manifest (issued under 177 a single CA instance) is current at any point in time, the associated 178 EE certificate is used to verify only a single object at a time. As 179 long as the sequence of objects verified by this EE certificate are 180 published using the same file name, then this sequential, multiple 181 use of this EE certificate is also valid. This form of use of a EE 182 certificate is termed a "sequential-use" EE certificate. 184 4. Manifest Definition 186 A manifest is an RPKI signed object, as specified in 187 [ID.sidr-signed-object]. The RPKI signed object template requires 188 specification of the following data elements in the context of the 189 manifest structure. 191 4.1. eContentType 193 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 194 has the numerical value of 1.2.840.113549.1.9.16.1.26. 196 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 197 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 199 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 201 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 203 4.2. eContent 205 The content of a Manifest is defined as follows: 207 Manifest ::= SEQUENCE { 208 version [0] INTEGER DEFAULT 0, 209 manifestNumber INTEGER (0..MAX), 210 thisUpdate GeneralizedTime, 211 nextUpdate GeneralizedTime, 212 fileHashAlg OBJECT IDENTIFIER, 213 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 214 } 216 FileAndHash ::= SEQUENCE { 217 file IA5String, 218 hash BIT STRING 219 } 221 4.2.1. Manifest 223 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 224 after the corresponding fields in X.509 CRLs (see [RFC5280]). 225 Analogous to CRLs, a manifest is nominally current until the time 226 specified in nextUpdate or until a manifest is issued with a greater 227 manifest number, whichever comes first. 229 If a "one-time-use" EE certificate is employed to verify a manifest, 230 the EE certificate MUST have an validity period that coincides with 231 the interval from thisUpdate to nextUpdate, to prevent needless 232 growth of the CA's CRL. 234 If a "sequential-use" EE certificate is employed to verify a 235 manifest, the EE certificate's validity period needs to be no shorter 236 than the nextUpdate time of the current manifest. The extended 237 validity time raises the possibility of a substitution attack using a 238 stale manifest, as described in Section 6.4. 240 The data elements of the Manifest structure are defined as follows: 242 version: 243 The version number of this version of the manifest specification 244 MUST be 0. 246 manifestNumber: 247 This field is an integer that is incremented each time a new 248 manifest is issued for a given publication point. This field 249 allows an RP to detect gaps in a sequence of published manifests. 251 As the manifest is modeled on the CRL specification, the 252 ManifestNumber is analogous to the CRLNumber, and the guidance in 253 [RFC5280] for CRLNumber values is appropriate as to the range of 254 number values that can be used for the manifestNumber. Manifest 255 numbers can be expected to contain long integers. Manifest 256 verifiers MUST be able to handle number values up to 20 octets. 257 Conforming Manifest issuers MUST NOT use number values longer than 258 20 octets 260 thisUpdate: 261 This field contains the time when the manifest was created. This 262 field has the same format constraints as specified in [RFC5280] 263 for the CRL field of the same name. 265 nextUpdate: 266 This field contains the time at which the next scheduled manifest 267 will be issued. The value of nextUpdate MUST be later than the 268 value of thisUpdate. The specification of the GeneralizedTime 269 value is the same as required for the thisUpdate field. 271 If the authority alters any of the items that it has published in 272 the repository publication point, then the authority MUST issue a 273 new manifest before the nextUpdate time. If a manifest 274 encompasses a CRL, the nextUpdate field of the manifest MUST match 275 that of the CRL's nextUpdate field, as the manifest will be re- 276 issued when a new CRL is published. If a "one-time-use" EE 277 certificate is used to verify the manifest, then when a new 278 manifest is issued before the time specified in nextUpdate of the 279 current manifest, the CA MUST also issue a new CRL that includes 280 the EE certificate corresponding to the old manifest. 282 fileHashAlg: 283 This field contains the OID of the hash algorithm used to hash the 284 files that the authority has placed into the repository. The hash 285 algorithm used MUST conform to the RPKI Algorithms and Key Size 286 Profile specification [ID.ietf-sidr-rpki-algs]. 288 fileList: 289 This field is a sequence of FileAndHash objects. There is one 290 FileAndHash entry for each currently valid signed object that has 291 been published by the authority (at this publication point). Each 292 FileAndHash is an ordered pair consisting of the name of the file 293 in the repository publication point (directory) that contains the 294 object in question, and a hash of the file's contents. 296 4.3. ContentType Attribute 298 The mandatory Content-Type Attribute MUST have its attrValues field 299 set to the same OID as eContentType. This OID is id-ct-rpkiManifest, 300 and has the numerical value of 1.2.840.113549.1.9.16.1.26. 302 4.4. Manifest Validation 304 To determine whether a manifest is valid, the RP MUST perform the 305 following checks in addition to those specified in 306 [ID.sidr-signed-object]: 308 1. The eContentType in the EncapsulatedContentInfo is id-ad- 309 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 311 2. The version of the rpkiManifest is 0. 313 3. In the rpkiManifest, thisUpdate precedes nextUpdate. 315 If the above procedure indicates that the manifest is invalid, then 316 the manifest MUST be discarded and treated as though no manifest were 317 present. 319 5. Manifest Generation 321 5.1. Manifest Generation Procedure 323 For a CA publication point in the RPKI repository system, a CA MUST 324 perform the following steps to generate a manifest: 326 1. If no key pair exists, or if using a "one-time-use" EE 327 certificate with a new key pair, generate a key pair. 329 2. If using a "one-time-use" EE certificate, or if a key pair was 330 generated in step 1, or if using a "sequential-use" EE 331 certificate which will expire before the intended nextUpdate time 332 of this manifest, issue a EE certificate for this key pair. 334 This EE certificate MUST have an SIA extension access 335 description field with an accessMethod OID value of id-ad- 336 signedobject where the associated accessLocation references 337 the publication point of the manifest as an object URL. 339 This EE certificate MUST describe its Internet Number 340 Resources (INRs) using the "inherit" attribute, rather than 341 explicit description of a resource set (see [RFC3779]). 343 In the case of a "one-time-use" EE certificate, the validity 344 times of the EE certificate MUST exactly match the thisUpdate 345 and nextUpdate times of the manifest. 347 In the case of a "sequential-use" EE certificate the validity 348 times of the EE certificate MUST encompass the time interval 349 from thisUpdate to nextUpdate. 351 3. The EE certificate MUST NOT be published in the authority's 352 repository publication point. 354 4. Construct the manifest content. 356 The manifest content is described in Section 4.2.1. The 357 manifest's fileList includes the file name and hash pair for each 358 object issued by this CA that has been published at this 359 repository publication point (directory). The collection of 360 objects to be included in the manifest includes all certificates 361 issued by this CA that are published at the CA's repository 362 publication point, the most recent CRL issued by the CA, and all 363 objects verified by EE certificates that were issued by this CA 364 that are published at this repository publication point. 366 Note that the manifest does not include a self reference (i.e., 367 its own file name and hash), since it would be impossible to 368 compute the hash of the manifest itself prior to it being signed. 370 5. Encapsulate the manifest content using the CMS SignedData content 371 type (as specified Section 4), sign the manifest using the 372 private key corresponding to the subject key contained in the EE 373 certificate, and publish the manifest in repository system 374 publication point that is described by the manifest. 376 6. In the case of a key pair that is to be used only once, in 377 conjunction with a "one-time-use" EE certificate, the private key 378 associated with this key pair SHOULD now be destroyed. 380 5.2. Considerations for Manifest Generation 382 A new manifest MUST be issued on or before the nextUpdate time. 384 An authority MUST issue a new manifest in conjunction with the 385 finalization of changes made to objects in the publication point. An 386 authority MAY perform a number of object operations on a publication 387 repository within the scope of a repository change before issuing a 388 single manifest that covers all the operations within the scope of 389 this change. Repository operators SHOULD implement some form of 390 repository update procedure that mitigates, to the extent possible, 391 the risk that RPs performing retrieval operations on the repository 392 are exposed to inconsistent transient intermediate states during 393 updates to the repository publication point (directory) and the 394 associated manifest. 396 Since the manifest object URL is included in the SIA of issued 397 Certificates, a new manifest MUST NOT invalidate the manifest object 398 URL of previously issued certificates. This implies that the 399 manifest's publication name in the repository, in the form of an 400 object URL, is unchanged across manifest generation cycles. 402 When a CA entity is performing a key rollover, the entity MAY chose 403 to have two CAs instances simultaneously publishing into the same 404 repository publication point. In this case there will be one 405 manifest associated with each active CA instance that is publishing 406 into the common repository publication point (directory). 408 6. Relying Party Use of Manifests 410 The goal of an RP is to determine which signed objects to use for 411 validating assertions about INRs and their use (e.g., which ROAs to 412 use in the construction of route filters). Ultimately, this 413 selection is a matter of local policy. However, in the following 414 sections, we describe a sequence of tests that the RP SHOULD perform 415 to determine the manifest state of the given publication point. We 416 then discuss the risks associated with using signed objects in the 417 publication point, given the manifest state; we also provide suitable 418 warning text that SHOULD be placed in a user-accessible log file. It 419 is the responsibility of the RP to weigh these risks against the risk 420 of routing failure that could occur if valid data is rejected, and to 421 implement a suitable local policy. Note that if a certificate is 422 deemed unfit for use due to local policy, then any signed object that 423 is validated using this certificate also SHOULD be deemed unfit for 424 use (regardless of the status of the manifest at its own publication 425 point). 427 6.1. Tests for Determining Manifest State 429 For a given publication point, the RP SHOULD perform the following 430 tests to determine the manifest state of the publication point: 432 1. For each CA using this publication point, select the CA's current 433 manifest (The "current" manifest is the manifest issued by this 434 CA having highest manifestNumber among all valid manifests, and 435 where manifest validity is defined in Section 4.4). 437 If the publication point does not contain a valid manifest, see 438 Section 6.2. Lacking a valid manifest, the following tests 439 cannot be performed. 441 2. To verify completeness, an RP MAY check that every file at each 442 publication point appears in one and only one current manifest, 443 and that every file listed in a current manifest that is 444 published at the same publication point as the manifest. 446 If there exist files at the publication point that do not appear 447 on any manifest, or files listed in a manifest that do not appear 448 at the publication point then see Section 6.5, but still continue 449 with the following test. 451 3. Check that the current time (translated to UTC) is between 452 thisUpdate and nextUpdate. 454 If the current time does not lie within this interval then see 455 Section 6.4, but still continue with the following tests. 457 4. Verify that listed hash value of every file listed in each 458 manifest matches the value obtained by hashing the file at the 459 publication point. 461 If the computed hash value of a file listed on the manifest does 462 not match the hash value contained in the manifest, then see 463 Section 6.6. 465 5. An RP MAY check that the contents of each current manifest 466 conforms to the manifest's scope constraints, as specified in 467 Section 2. 469 If a current manifest contains entries for objects that are not 470 within the scope of the manifest, then the out-of-scope entries 471 SHOULD be disregarded in the context of this manifest. If there 472 is no other current manifest that describes these objects within 473 that other manifest's scope, then see Section 6.2. 475 For each signed object, if all of the following conditions hold: 477 * the manifest for its publication, and the associated 478 publication point, pass all of the above checks; 480 * the signed object is valid; and 482 * the manifests for every certificate on the certification path 483 used to validate the signed object, and the associated 484 publication points, pass all of the above checks; 486 then the RP can conclude that no attack against the repository system 487 has compromised the given signed object, and the signed object MUST 488 be treated as valid. 490 6.2. Missing Manifests 492 The absence of a current manifest at a publication point could occur 493 due to an error by the publisher or due to (malicious or accidental) 494 deletion or corruption of all valid manifests. 496 When no valid manifest is available, there is no protection against 497 attacks that delete signed objects or replay old versions of signed 498 objects. All signed objects at the publication point, and all 499 descendant objects that are validated using a certificate at this 500 publication point SHOULD be viewed as suspect, but MAY be used by the 501 RP, as per local policy. 503 The primary risk in using signed objects at this publication point is 504 that a superseded (but not stale) CRL would cause an RP to improperly 505 accept a revoked certificate as valid (and thus rely upon signed 506 objects that are validated using that certificate). This risk is 507 somewhat mitigated if the CRL for this publication point has a short 508 time between thisUpdate and nextUpdate (and the current time is 509 within this interval). The risk in discarding signed objects at this 510 publication point is that an RP may incorrectly discard a large 511 number of valid objects. This gives significant power to an 512 adversary that is able to delete a manifest at the publication point. 514 Regardless of whether signed objects from this publication are deemed 515 fit for use by an RP, this situation SHOULD result in a warning to 516 the effect that: "No manifest is available for , and 517 thus there may have been undetected deletions or replay substitutions 518 from the publication point." 520 In the case where an RP has access to a local cache of previously 521 issued manifests that are valid, the RP MAY use the most recently 522 previously issued valid manifests for this RPKI repository 523 publication collection in this case for each entity that publishes at 524 his publication point. 526 6.3. Invalid Manifests 528 The presence of an invalid manifest at a publication point could 529 occur due to an error by the publisher or due to (malicious or 530 accidental) corruption of a valid manifest. An invalid manifest MUST 531 never be used. 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 endeavor to use the most recently issued valid CRL, even where 659 the hash value in the manifest matches an older CRL, or does not 660 match any available CRL for a CA instance. The thisUpdate field of 661 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. Acknowledgments 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 behavior. 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