idnits 2.17.1 draft-ietf-sidrops-6486bis-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6486, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Termination of processing means that the RP SHOULD continue to use cached versions of the objects associated with this CA instance, until such time as they become stale or they can be replaced by objects from a successful fetch. This implies that the RP MUST not try to acquire and validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when the RP is scheduled to fetch and process data for this CA instance. (Using the creation date from RFC6486, updated by this document, for RFC5378 checks: 2008-01-02) -- 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 (August 11, 2020) is 1326 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 705 ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Austein 3 Internet-Draft Arrcus, Inc. 4 Updates: 6486 (if approved) G. Huston 5 Intended status: Standards Track APNIC 6 Expires: February 12, 2021 S. Kent 7 Independent 8 M. Lepinski 9 New College Florida 10 August 11, 2020 12 Manifests for the Resource Public Key Infrastructure (RPKI) 13 draft-ietf-sidrops-6486bis-00 15 Abstract 17 This document defines a "manifest" for use in the Resource Public Key 18 Infrastructure (RPKI). A manifest is a signed object (file) that 19 contains a listing of all the signed objects (files) in the 20 repository publication point (directory) associated with an authority 21 responsible for publishing in the repository. For each certificate, 22 Certificate Revocation List (CRL), or other type of signed objects 23 issued by the authority that are published at this repository 24 publication point, the manifest contains both the name of the file 25 containing the object and a hash of the file content. Manifests are 26 intended to enable a relying party (RP) to detect certain forms of 27 attacks against a repository. Specifically, if an RP checks a 28 manifest's contents against the signed objects retrieved from a 29 repository publication point, then the RP can detect "stale" (valid) 30 data and deletion of signed objects. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 12, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Manifest Definition . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. eContentType . . . . . . . . . . . . . . . . . . . . . . 5 72 4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 5 74 4.3. Content-Type Attribute . . . . . . . . . . . . . . . . . 7 75 4.4. Manifest Validation . . . . . . . . . . . . . . . . . . . 7 76 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8 78 5.2. Considerations for Manifest Generation . . . . . . . . . 9 79 6. Relying Party Processing of Manifests . . . . . . . . . . . . 9 80 6.1. Manifest Processing Overview . . . . . . . . . . . . . . 11 81 6.2. Acquiring a Manifest for a CA . . . . . . . . . . . . . . 11 82 6.3. Detecting Stale and or Prematurely-issued Manifests . . . 11 83 6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 12 84 6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12 85 6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12 86 6.7. Failed Fetches . . . . . . . . . . . . . . . . . . . . . 12 87 7. Publication Repositories . . . . . . . . . . . . . . . . . . 13 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 11.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of 100 a distributed repository system [RFC6481] to make available a variety 101 of objects needed by relying parties (RPs). Because all of the 102 objects stored in the repository system are digitally signed by the 103 entities that created them, attacks that modify these published 104 objects are detectable by RPs. However, digital signatures provide 105 no protection against attacks that substitute "stale" versions of 106 signed objects (i.e., objects that were valid and have not expired, 107 but have since been superseded) or attacks that remove an object that 108 should be present in the repository. To assist in the detection of 109 such attacks, the RPKI repository system can make use of a signed 110 object called a "manifest". 112 A manifest is a signed object that enumerates all the signed objects 113 (files) in the repository publication point (directory) that are 114 associated with an authority responsible for publishing at that 115 publication point. Each manifest contains both the name of the file 116 containing the object and a hash of the file content, for every 117 signed object issued by an authority that is published at the 118 authority's repository publication point. A manifest is intended to 119 allow an RP to detect unauthorized object removal or the substitution 120 of stale versions of objects at a publication point. A manifest also 121 is intended to allow an RP to detect similar outcomes that may result 122 from a man-in-the-middle attack on the retrieval of objects from the 123 repository. Manifests are intended to be used in Certification 124 Authority (CA) publication points in repositories (directories 125 containing files that are subordinate certificates and Certificate 126 Revocation Lists (CRLs) issued by this CA and other signed objects 127 that are verified by end-entity (EE) certificates issued by this CA). 129 Manifests are modeled on CRLs, as the issues involved in detecting 130 stale manifests and potential attacks using manifest replays, etc., 131 are similar to those for CRLs. The syntax of the manifest payload 132 differs from CRLs, since RPKI repositories contain objects not 133 covered by CRLs, e.g., digitally signed objects, such as Route 134 Origination Authorizations (ROAs). 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2. Manifest Scope 146 A manifest associated with a CA's repository publication point 147 contains a list of: 149 o the set of (non-expired, non-revoked) certificates issued and 150 published by this CA, 152 o the most recent CRL issued by this CA, and 154 o all published signed objects that are verifiable using EE 155 certificates [RFC6487] issued by this CA. 157 Every RPKI signed object includes, in the Cryptographic Message 158 Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used 159 to verify it [RFC6488]. Thus, there is no requirement to separately 160 publish that EE certificate at the CA's repository publication point. 162 Where multiple CA instances share a common publication point, as can 163 occur when an entity performs a key-rollover operation [RFC6489], the 164 repository publication point will contain multiple manifests. In 165 this case, each manifest describes only the collection of published 166 products of its associated CA instance. 168 3. Manifest Signing 170 A CA's manifest is verified using an EE certificate. The 171 SubjectInfoAccess (SIA) field of this EE certificate contains the 172 access method OID of id-ad-signedObject. 174 The CA MAY choose to sign only one manifest with each generated 175 private key, and generate a new key pair for each new version of the 176 manifest. This form of use of the associated EE certificate is 177 termed a "one-time-use" EE certificate. 179 Alternatively, the CA MAY elect to use the same private key to sign a 180 sequence of manifests. Because only a single manifest (issued under 181 a single CA instance) is current at any point in time, the associated 182 EE certificate is used to verify only a single object at a time. As 183 long as the sequence of objects verified by this EE certificate are 184 published using the same file name, then this sequential, multiple 185 use of the EE certificate is also valid. This form of use of an EE 186 certificate is termed a "sequential-use" EE certificate. 188 4. Manifest Definition 190 A manifest is an RPKI signed object, as specified in [RFC6488]. The 191 RPKI signed object template requires specification of the following 192 data elements in the context of the manifest structure. 194 4.1. eContentType 196 The eContentType for a manifest is defined as id-ct-rpkiManifest and 197 has the numerical value of 1.2.840.113549.1.9.16.1.26. 199 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 200 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 202 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 204 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 206 4.2. eContent 208 The content of a manifest is ASN.1 encoded using the Distinguished 209 Encoding Rules (DER) [X.690]. The content of a manifest is defined 210 as follows: 212 Manifest ::= SEQUENCE { 213 version [0] INTEGER DEFAULT 0, 214 manifestNumber INTEGER (0..MAX), 215 thisUpdate GeneralizedTime, 216 nextUpdate GeneralizedTime, 217 fileHashAlg OBJECT IDENTIFIER, 218 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 219 } 221 FileAndHash ::= SEQUENCE { 222 file IA5String, 223 hash BIT STRING 224 } 226 4.2.1. Manifest 228 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 229 after the corresponding fields in X.509 CRLs (see [RFC5280]). 230 Analogous to CRLs, a manifest is nominally current until the time 231 specified in nextUpdate or until a manifest is issued with a greater 232 manifest number, whichever comes first. 234 If a "one-time-use" EE certificate is employed to verify a manifest, 235 the EE certificate MUST have a validity period that coincides with 236 the interval from thisUpdate to nextUpdate, to prevent needless 237 growth of the CA's CRL. 239 If a "sequential-use" EE certificate is employed to verify a 240 manifest, the EE certificate's validity period needs to be no shorter 241 than the nextUpdate time of the current manifest. The extended 242 validity time raises the possibility of a substitution attack using a 243 stale manifest, as described in Section 6.4. 245 The data elements of the manifest structure are defined as follows: 247 version: 248 The version number of this version of the manifest specification 249 MUST be 0. 251 manifestNumber: 252 This field is an integer that is incremented each time a new 253 manifest is issued for a given publication point. This field 254 allows an RP to detect gaps in a sequence of published manifests. 256 As the manifest is modeled on the CRL specification, the 257 ManifestNumber is analogous to the CRLNumber, and the guidance in 258 [RFC5280] for CRLNumber values is appropriate as to the range of 259 number values that can be used for the manifestNumber. Manifest 260 numbers can be expected to contain long integers. Manifest 261 verifiers MUST be able to handle number values up to 20 octets. 262 Conforming manifest issuers MUST NOT use number values longer than 263 20 octets. 265 thisUpdate: 266 This field contains the time when the manifest was created. This 267 field has the same format constraints as specified in [RFC5280] 268 for the CRL field of the same name. 270 nextUpdate: 271 This field contains the time at which the next scheduled manifest 272 will be issued. The value of nextUpdate MUST be later than the 273 value of thisUpdate. The specification of the GeneralizedTime 274 value is the same as required for the thisUpdate field. 276 If the authority alters any of the items that it has published in 277 the repository publication point, then the authority MUST issue a 278 new manifest before the nextUpdate time. If a manifest 279 encompasses a CRL, the nextUpdate field of the manifest MUST match 280 that of the CRL's nextUpdate field, as the manifest will be re- 281 issued when a new CRL is published. If a "one-time-use" EE 282 certificate is used to verify the manifest, then when a new 283 manifest is issued before the time specified in nextUpdate of the 284 current manifest, the CA MUST also issue a new CRL that includes 285 the EE certificate corresponding to the old manifest. 287 fileHashAlg: 288 This field contains the OID of the hash algorithm used to hash the 289 files that the authority has placed into the repository. The hash 290 algorithm used MUST conform to the RPKI Algorithms and Key Size 291 Profile specification [RFC6485]. 293 fileList: 294 This field is a sequence of FileAndHash objects. There is one 295 FileAndHash entry for each currently valid signed object that has 296 been published by the authority (at this publication point). Each 297 FileAndHash is an ordered pair consisting of the name of the file 298 in the repository publication point (directory) that contains the 299 object in question and a hash of the file's contents. 301 4.3. Content-Type Attribute 303 The mandatory content-type attribute MUST have its attrValues field 304 set to the same OID as eContentType. This OID is id-ct-rpkiManifest 305 and has the numerical value of 1.2.840.113549.1.9.16.1.26. 307 4.4. Manifest Validation 309 To determine whether a manifest is valid, the RP MUST perform the 310 following checks in addition to those specified in [RFC6488]: 312 1. The eContentType in the EncapsulatedContentInfo is id-ad- 313 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 315 2. The version of the rpkiManifest is 0. 317 3. In the rpkiManifest, thisUpdate precedes nextUpdate. 319 If the above procedure indicates that the manifest is invalid, then 320 the manifest MUST be discarded and treated as though no manifest were 321 present. 323 5. Manifest Generation 325 5.1. Manifest Generation Procedure 327 For a CA publication point in the RPKI repository system, a CA MUST 328 perform the following steps to generate a manifest: 330 1. If no key pair exists, or if using a "one-time-use" EE 331 certificate with a new key pair, generate a key pair. 333 2. If using a "one-time-use" EE certificate, or if a key pair was 334 generated in step 1, or if using a "sequential-use" EE 335 certificate that will expire before the intended nextUpdate time 336 of this manifest, issue an EE certificate for this key pair. 338 This EE certificate MUST have an SIA extension access description 339 field with an accessMethod OID value of id-ad-signedobject, where 340 the associated accessLocation references the publication point of 341 the manifest as an object URL. 343 This EE certificate MUST describe its Internet Number Resources 344 (INRs) using the "inherit" attribute, rather than explicit 345 description of a resource set (see [RFC3779]). 347 In the case of a "one-time-use" EE certificate, the validity 348 times of the EE certificate MUST exactly match the thisUpdate and 349 nextUpdate times of the manifest. 351 In the case of a "sequential-use" EE certificate, the validity 352 times of the EE certificate MUST encompass the time interval from 353 thisUpdate to nextUpdate. 355 3. The EE certificate MUST NOT be published in the authority's 356 repository publication point. 358 4. Construct the manifest content. 360 The manifest content is described in Section 4.2.1. The 361 manifest's fileList includes the file name and hash pair for each 362 object issued by this CA that has been published at this 363 repository publication point (directory). The collection of 364 objects to be included in the manifest includes all certificates 365 issued by this CA that are published at the CA's repository 366 publication point, the most recent CRL issued by the CA, and all 367 objects verified by EE certificates that were issued by this CA 368 that are published at this repository publication point. 370 Note that the manifest does not include a self reference (i.e., 371 its own file name and hash), since it would be impossible to 372 compute the hash of the manifest itself prior to it being signed. 374 5. Encapsulate the manifest content using the CMS SignedData content 375 type (as specified Section 4), sign the manifest using the 376 private key corresponding to the subject key contained in the EE 377 certificate, and publish the manifest in the repository system 378 publication point that is described by the manifest. 380 6. In the case of a key pair that is to be used only once, in 381 conjunction with a "one-time-use" EE certificate, the private key 382 associated with this key pair MUST now be destroyed. 384 5.2. Considerations for Manifest Generation 386 A new manifest MUST be issued and published on or before the 387 nextUpdate time. 389 An authority MUST issue a new manifest in conjunction with the 390 finalization of changes made to objects in the publication point. An 391 authority MAY perform a number of object operations on a publication 392 repository within the scope of a repository change before issuing a 393 single manifest that covers all the operations within the scope of 394 this change. Repository operators SHOULD implement some form of 395 repository update procedure that mitigates, to the extent possible, 396 the risk that RPs that are performing retrieval operations on the 397 repository are exposed to inconsistent, transient, intermediate 398 states during updates to the repository publication point (directory) 399 and the associated manifest. 401 Since the manifest object URL is included in the SIA of issued 402 certificates, a new manifest MUST NOT invalidate the manifest object 403 URL of previously issued certificates. This implies that the 404 manifest's publication name in the repository, in the form of an 405 object URL, is unchanged across manifest generation cycles. 407 When a CA entity is performing a key rollover, the entity MAY choose 408 to have two CA instances simultaneously publishing into the same 409 repository publication point. In this case, there will be one 410 manifest associated with each active CA instance that is publishing 411 into the common repository publication point (directory). 413 6. Relying Party Processing of Manifests 415 Each RP must determine which signed objects it will use for 416 validating assertions about INRs and their use (e.g., which ROAs to 417 use in the construction of route filters). As noted earlier, 418 manifests are designed to allow an RP to detect manipulation of 419 repository data, errors by a CA or repository manager, and/or active 420 attacks on the communication channel between an RP and a repository. 421 Unless all of the files enumerated in a manifest can be obtained by 422 an RP during a fetch operation, the fetch is considered to have 423 failed and the RP MUST retry the fetch later. 425 [RFC6480] suggests (but does not mandate) that the RPKI model employ 426 fetches that are incremental, e.g., an RP transfers files from a 427 publication point only if they are new/changed since the previous, 428 successful, fetch represented in the RP's local cache. This document 429 avoids language that relies on details of the underlying file 430 transfer mechanism employed by an RP and a publication point to 431 effect this operation. Thus the term "fetch" refers to an operation 432 that attempts to acquire the full set of files at a publication 433 point, consistent with the id-ad-rpkiManifest URI extracted from a CA 434 certificate's SIA (see below). 436 If a fetch fails, it is assumed that a subsequent fetch will resolve 437 problems encountered during the fetch. Until such time as a 438 successful fetch is executed, an RP SHOULD use cached data from a 439 previous, successful fetch. This response is intended to prevent an 440 RP from misinterpreting data associated with a publication point, and 441 thus possibly treating invalid routes as valid, or vice versa. 443 The processing described below is designed to cause all RPs with 444 access to the same local cache and RPKI repository data to achieve 445 the same results with regard to validation of RPKI data. However, in 446 operation, different RPs will access repositories at different times, 447 and some RPs may experience local cache failures, so there is no 448 guarantee that all RPs will achieve the same results with regard to 449 validation of RPKI data. 451 Note that there is a "chicken and egg" relationship between the 452 manifest and the CRL for a given CA instance. If the EE certificate 453 for the current manifest is revoked, i.e., it appears in the current 454 CRL, then the CA or publication point manager has made a serious 455 error. In this case the fetch has failed; proceed to Section 6.7. 456 Similarly, if the CRL is not listed on a valid, current manifest, 457 acquired during a fetch, the fetch has failed; proceed to 458 Section 6.7, because the CRL is considered missing. 460 Note that if a CA and its associated publication point are operating 461 properly, there will always be exactly one manifest and one 462 associated CRL at the publication point identified in the CA's SIA 463 (see below). 465 6.1. Manifest Processing Overview 467 For a given publication point, an RP MUST perform a series of tests 468 to determine which signed object files at the publication point are 469 acceptable. The tests described below (Section 6.2 to Section 6.6) 470 are to be performed using the manifest identified by the id-ad- 471 rpkiManifest URI extracted from a CA certificate's SIA. All of the 472 files referenced by the manifest MUST be be located at the 473 publication point specified by the id-ad-caRepository URI from the 474 (same) CA certificate's SIA. The manifest and the files it 475 references MUST reside at the same publication point. If an RP 476 encounters any files that appear on a manifest but do not reside at 477 the same publication point as the manifest the RP MUST treat the 478 fetch as failed, and a warning MUST be issued (see Section 6.7 479 below). 481 A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be 482 at the location specified in the CRLDP in the manifest's EE 483 certificate. If more than one .crl file appears in the manifest, the 484 fetch has failed and the RP MUST proceed to Section 6.7; otherwise 485 proceed to Section 6.2. 487 Note that, during CA key rollover [RFC6489], signed objects for two 488 or more different CA instances will appear at the same publication 489 point. Manifest processing is to be performed separately for each CA 490 instance, guided by the SIA id-ad-rpkiManifest URI in each CA 491 certificate. 493 6.2. Acquiring a Manifest for a CA 495 The RP MUST fetch the manifest identified by the SIA id-ad- 496 rpkiManifest URI in the CA certificate. If an RP cannot retrieve a 497 manifest using this URI, or if the manifest is not valid 498 (Section 4.4), an RP MUST treat this as a failed fetch and, proceed 499 to Section 6.7; otherwise proceed to Section 6.3. 501 6.3. Detecting Stale and or Prematurely-issued Manifests 503 The RP MUST check that the current time (translated to UTC) is 504 between thisUpdate and nextUpdate. If the current time lies within 505 this interval, proceed to Section 6.4. If the current time is 506 earlier than thisUpdate, the CA has made an error; this is a failed 507 fetch and the RP MUST proceed to Section 6.7. If the current time is 508 later than nextUpdate, then the manifest is stale; this is a failed 509 fetch and RP MUST proceed to Section 6.7; otherwise proceed to 510 Section 6.4. 512 6.4. Acquiring Files Referenced by a Manifest 514 The RP MUST acquire all of the files enumerated in the manifest 515 (fileList) from the publication point. This includes the CRL, each 516 object containing an EE certificate issued by the CA, and any 517 subordinate CA and EE certificates. If there are files listed in the 518 manifest that cannot be retrieved from the publication point, or if 519 they fail the validity tests specified in [RFC6488], the fetch has 520 failed and the RP MUST proceed to Section 6.7; otherwise, proceed to 521 Section 6.5. 523 6.5. Matching File Names and Hashes 525 The RP MUST verify that the hash value of each file listed in the 526 manifest matches the value obtained by hashing the file acquired from 527 the publication point. If the computed hash value of a file listed 528 on the manifest does not match the hash value contained in the 529 manifest, then the fetch has failed and the RP MUST proceed to 530 Section 6.7; otherwise proceed to Section 6.6. 532 6.6. Out of Scope Manifest Entries 534 If a current manifest contains entries for objects that are not 535 within the scope of the manifest (Section 6.2), the fetch has failed 536 and the RP SHOULD proceed to Section 6.7; otherwise the fetch is 537 deemed successful and the RP will process the fetched objects. 539 6.7. Failed Fetches 541 If an RP does not acquire a current valid manifest, or does not 542 acquire current valid instances of all of the objects enumerated in a 543 current valid manifest as a result of a fetch, then processing of the 544 signed objects associated with the CA instance has failed for this 545 fetch cycle. The RP MUST issue a warning indicating the reason(s) 546 for termination of processing with regard to this CA instance. It is 547 RECOMMENDED that a human operator be notified of this warning. 549 Termination of processing means that the RP SHOULD continue to use 550 cached versions of the objects associated with this CA instance, 551 until such time as they become stale or they can be replaced by 552 objects from a successful fetch. This implies that the RP MUST not 553 try to acquire and validate subordinate signed objects, e.g., 554 subordinate CA certificates, until the next interval when the RP is 555 scheduled to fetch and process data for this CA instance. 557 7. Publication Repositories 559 The RPKI publication system model requires that every publication 560 point be associated with one or more CAs, and be non-empty. Upon 561 creation of the publication point associated with a CA, the CA MUST 562 create and publish a manifest as well as a CRL. A CA's manifest will 563 always contain at least one entry, namely, the CRL issued by the CA 564 upon repository creation [RFC6481]. 566 Every published signed object in the RPKI [RFC6488] is published in 567 the repository publication point of the CA that issued the EE 568 certificate, and is listed in the manifest associated with that CA 569 certificate. 571 8. Security Considerations 573 Manifests provide an additional level of protection for RPKI RPs. 574 Manifests can assist an RP to determine if a repository object has 575 been deleted, occluded, or otherwise removed from view, or if a 576 publication of a newer version of an object has been suppressed (and 577 an older version of the object has been substituted). 579 Manifests cannot repair the effects of such forms of corruption of 580 repository retrieval operations. However, a manifest enables an RP 581 to determine if a locally maintained copy of a repository is a 582 complete and up-to-date copy, even when the repository retrieval 583 operation is conducted over an insecure channel. In cases where the 584 manifest and the retrieved repository contents differ, the manifest 585 can assist in determining which repository objects form the 586 difference set in terms of missing, extraneous, or superseded 587 objects. 589 The signing structure of a manifest and the use of the nextUpdate 590 value allows an RP to determine if the manifest itself is the subject 591 of attempted alteration. The requirement for every repository 592 publication point to contain at least one manifest allows an RP to 593 determine if the manifest itself has been occluded from view. Such 594 attacks against the manifest are detectable within the time frame of 595 the regular schedule of manifest updates. Forms of replay attack 596 within finer-grained time frames are not necessarily detectable by 597 the manifest structure. 599 9. IANA Considerations 601 As [RFC6488] created and populated the registries "RPKI Signed 602 Object" and three-letter filename extensions for "RPKI Repository 603 Name Schemes," no new action is requested of the IANA. 605 10. Acknowledgements 607 The authors would like to acknowledge the contributions from George 608 Michelson and Randy Bush in the preparation of the manifest 609 specification. Additionally, the authors would like to thank Mark 610 Reynolds and Christopher Small for assistance in clarifying manifest 611 validation and RP behavior. The authors also wish to thank Job 612 Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of 613 this document. 615 11. References 617 11.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, 621 DOI 10.17487/RFC2119, March 1997, 622 . 624 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 625 Housley, R., and W. Polk, "Internet X.509 Public Key 626 Infrastructure Certificate and Certificate Revocation List 627 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 628 . 630 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 631 Resource Certificate Repository Structure", RFC 6481, 632 DOI 10.17487/RFC6481, February 2012, 633 . 635 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 636 Use in the Resource Public Key Infrastructure (RPKI)", 637 RFC 6485, DOI 10.17487/RFC6485, February 2012, 638 . 640 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 641 X.509 PKIX Resource Certificates", RFC 6487, 642 DOI 10.17487/RFC6487, February 2012, 643 . 645 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 646 Template for the Resource Public Key Infrastructure 647 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 648 . 650 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 651 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 652 May 2017, . 654 [X.690] International International Telephone and Telegraph 655 Consultative Committee, "ASN.1 encoding rules: 656 Specification of basic encoding Rules (BER), Canonical 657 encoding rules (CER) and Distinguished encoding rules 658 (DER)", CCITT Recommendation X.690, July 2002. 660 11.2. Informative References 662 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 663 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 664 . 666 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 667 Addresses and AS Identifiers", RFC 3779, 668 DOI 10.17487/RFC3779, June 2004, 669 . 671 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 672 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 673 February 2012, . 675 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 676 Authority (CA) Key Rollover in the Resource Public Key 677 Infrastructure (RPKI)", BCP 174, RFC 6489, 678 DOI 10.17487/RFC6489, February 2012, 679 . 681 Appendix A. ASN.1 Module 682 RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) 683 pkcs(1) pkcs9(9) smime(16) mod(0) 60 } 685 DEFINITIONS EXPLICIT TAGS ::= 687 BEGIN 689 -- EXPORTS ALL -- 691 -- IMPORTS NOTHING -- 693 -- Manifest Content Type: OID 695 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 696 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 698 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 700 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 702 -- Manifest Content Type: eContent 704 Manifest ::= SEQUENCE { 705 version [0] INTEGER DEFAULT 0, 706 manifestNumber INTEGER (0..MAX), 707 thisUpdate GeneralizedTime, 708 nextUpdate GeneralizedTime, 709 fileHashAlg OBJECT IDENTIFIER, 710 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 711 } 713 FileAndHash ::= SEQUENCE { 714 file IA5String, 715 hash BIT STRING 716 } 718 END 720 Authors' Addresses 722 Rob Austein 723 Arrcus, Inc. 725 Email: sra@hactrn.net 726 Geoff Huston 727 APNIC 728 6 Cordelia St 729 South Brisbane QLD 4101 730 Australia 732 Email: gih@apnic.net 734 Stephen Kent 735 Independent 737 Email: kkent@alum.mit.edu 739 Matt Lepinski 740 New College Florida 741 5800 Bay Shore Rd. 742 Sarasota, FL 34243 743 USA 745 Email: mlepinski@ncf.edu