idnits 2.17.1 draft-ietf-sidrops-6486bis-03.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 (November 30, 2020) is 1241 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 746 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-NAMING' ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Downref: Normative reference to an Informational RFC: RFC 8488 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 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: June 3, 2021 S. Kent 7 Independent 8 M. Lepinski 9 New College Florida 10 November 30, 2020 12 Manifests for the Resource Public Key Infrastructure (RPKI) 13 draft-ietf-sidrops-6486bis-03 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 June 3, 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.2.2. Names in FileAndHash objects . . . . . . . . . . . . 7 75 4.3. Content-Type Attribute . . . . . . . . . . . . . . . . . 7 76 4.4. Manifest Validation . . . . . . . . . . . . . . . . . . . 7 77 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 8 78 5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8 79 5.2. Considerations for Manifest Generation . . . . . . . . . 9 80 6. Relying Party Processing of Manifests . . . . . . . . . . . . 10 81 6.1. Manifest Processing Overview . . . . . . . . . . . . . . 11 82 6.2. Acquiring a Manifest for a CA . . . . . . . . . . . . . . 11 83 6.3. Detecting Stale and or Prematurely-issued Manifests . . . 11 84 6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 12 85 6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12 86 6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12 87 6.7. Failed Fetches . . . . . . . . . . . . . . . . . . . . . 12 88 7. Publication Repositories . . . . . . . . . . . . . . . . . . 13 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 11.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of 101 a distributed repository system [RFC6481] to make available a variety 102 of objects needed by relying parties (RPs). Because all of the 103 objects stored in the repository system are digitally signed by the 104 entities that created them, attacks that modify these published 105 objects are detectable by RPs. However, digital signatures provide 106 no protection against attacks that substitute "stale" versions of 107 signed objects (i.e., objects that were valid and have not expired, 108 but have since been superseded) or attacks that remove an object that 109 should be present in the repository. To assist in the detection of 110 such attacks, the RPKI repository system can make use of a signed 111 object called a "manifest". 113 A manifest is a signed object that enumerates all the signed objects 114 (files) in the repository publication point (directory) that are 115 associated with an authority responsible for publishing at that 116 publication point. Each manifest contains both the name of the file 117 containing the object and a hash of the file content, for every 118 signed object issued by an authority that is published at the 119 authority's repository publication point. A manifest is intended to 120 allow an RP to detect unauthorized object removal or the substitution 121 of stale versions of objects at a publication point. A manifest also 122 is intended to allow an RP to detect similar outcomes that may result 123 from a man-in-the-middle attack on the retrieval of objects from the 124 repository. Manifests are intended to be used in Certification 125 Authority (CA) publication points in repositories (directories 126 containing files that are subordinate certificates and Certificate 127 Revocation Lists (CRLs) issued by this CA and other signed objects 128 that are verified by end-entity (EE) certificates issued by this CA). 130 Manifests are modeled on CRLs, as the issues involved in detecting 131 stale manifests and potential attacks using manifest replays, etc., 132 are similar to those for CRLs. The syntax of the manifest payload 133 differs from CRLs, since RPKI repositories contain objects not 134 covered by CRLs, e.g., digitally signed objects, such as Route 135 Origination Authorizations (ROAs). 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 2. Manifest Scope 147 A manifest associated with a CA's repository publication point 148 contains a list of: 150 o the set of (non-expired, non-revoked) certificates issued and 151 published by this CA, 153 o the most recent CRL issued by this CA, and 155 o all published signed objects that are verifiable using EE 156 certificates [RFC6487] issued by this CA. 158 Every RPKI signed object includes, in the Cryptographic Message 159 Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used 160 to verify it [RFC6488]. Thus, there is no requirement to separately 161 publish that EE certificate at the CA's repository publication point. 163 Where multiple CA instances share a common publication point, as can 164 occur when an entity performs a key-rollover operation [RFC6489], the 165 repository publication point will contain multiple manifests. In 166 this case, each manifest describes only the collection of published 167 products of its associated CA instance. 169 3. Manifest Signing 171 A CA's manifest is verified using an EE certificate. The 172 SubjectInfoAccess (SIA) field of this EE certificate contains the 173 access method OID of id-ad-signedObject. 175 The CA MAY choose to sign only one manifest with each generated 176 private key, and generate a new key pair for each new version of the 177 manifest. This form of use of the associated EE certificate is 178 termed a "one-time-use" EE certificate. 180 Alternatively, the CA MAY elect to use the same private key to sign a 181 sequence of manifests. Because only a single manifest (issued under 182 a single CA instance) is current at any point in time, the associated 183 EE certificate is used to verify only a single object at a time. As 184 long as the sequence of objects verified by this EE certificate are 185 published using the same file name, then this sequential, multiple 186 use of the EE certificate is also valid. This form of use of an EE 187 certificate is termed a "sequential-use" EE certificate. 189 4. Manifest Definition 191 A manifest is an RPKI signed object, as specified in [RFC6488]. The 192 RPKI signed object template requires specification of the following 193 data elements in the context of the manifest structure. 195 4.1. eContentType 197 The eContentType for a manifest is defined as id-ct-rpkiManifest and 198 has the numerical value of 1.2.840.113549.1.9.16.1.26. 200 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 201 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 203 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 205 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 207 4.2. eContent 209 The content of a manifest is ASN.1 encoded using the Distinguished 210 Encoding Rules (DER) [X.690]. The content of a manifest is defined 211 as follows: 213 Manifest ::= SEQUENCE { 214 version [0] INTEGER DEFAULT 0, 215 manifestNumber INTEGER (0..MAX), 216 thisUpdate GeneralizedTime, 217 nextUpdate GeneralizedTime, 218 fileHashAlg OBJECT IDENTIFIER, 219 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 220 } 222 FileAndHash ::= SEQUENCE { 223 file IA5String, 224 hash BIT STRING 225 } 227 4.2.1. Manifest 229 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 230 after the corresponding fields in X.509 CRLs (see [RFC5280]). 231 Analogous to CRLs, a manifest is nominally current until the time 232 specified in nextUpdate or until a manifest is issued with a greater 233 manifest number, whichever comes first. 235 If a "one-time-use" EE certificate is employed to verify a manifest, 236 the EE certificate MUST have a validity period that coincides with 237 the interval from thisUpdate to nextUpdate, to prevent needless 238 growth of the CA's CRL. 240 If a "sequential-use" EE certificate is employed to verify a 241 manifest, the EE certificate's validity period needs to be no shorter 242 than the nextUpdate time of the current manifest. The extended 243 validity time raises the possibility of a substitution attack using a 244 stale manifest, as described in Section 6.4. 246 The data elements of the manifest structure are defined as follows: 248 version: 249 The version number of this version of the manifest specification 250 MUST be 0. 252 manifestNumber: 253 This field is an integer that is incremented each time a new 254 manifest is issued for a given publication point. This field 255 allows an RP to detect gaps in a sequence of published manifests. 257 As the manifest is modeled on the CRL specification, the 258 ManifestNumber is analogous to the CRLNumber, and the guidance in 259 [RFC5280] for CRLNumber values is appropriate as to the range of 260 number values that can be used for the manifestNumber. Manifest 261 numbers can be expected to contain long integers. Manifest 262 verifiers MUST be able to handle number values up to 20 octets. 263 Conforming manifest issuers MUST NOT use number values longer than 264 20 octets. 266 thisUpdate: 267 This field contains the time when the manifest was created. This 268 field has the same format constraints as specified in [RFC5280] 269 for the CRL field of the same name. 271 nextUpdate: 272 This field contains the time at which the next scheduled manifest 273 will be issued. The value of nextUpdate MUST be later than the 274 value of thisUpdate. The specification of the GeneralizedTime 275 value is the same as required for the thisUpdate field. 277 If the authority alters any of the items that it has published in 278 the repository publication point, then the authority MUST issue a 279 new manifest before the nextUpdate time. If a manifest 280 encompasses a CRL, the nextUpdate field of the manifest MUST match 281 that of the CRL's nextUpdate field, as the manifest will be re- 282 issued when a new CRL is published. If a "one-time-use" EE 283 certificate is used to verify the manifest, then when a new 284 manifest is issued before the time specified in nextUpdate of the 285 current manifest, the CA MUST also issue a new CRL that includes 286 the EE certificate corresponding to the old manifest. 288 fileHashAlg: 289 This field contains the OID of the hash algorithm used to hash the 290 files that the authority has placed into the repository. The hash 291 algorithm used MUST conform to the RPKI Algorithms and Key Size 292 Profile specification [RFC6485]. 294 fileList: 295 This field is a sequence of FileAndHash objects. There is one 296 FileAndHash entry for each currently valid signed object that has 297 been published by the authority (at this publication point). Each 298 FileAndHash is an ordered pair consisting of the name of the file 299 in the repository publication point (directory) that contains the 300 object in question and a hash of the file's contents. 302 4.2.2. Names in FileAndHash objects 304 Names that appear in the fileList MUST consist of one or more 305 characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ 306 (UNDERSCORE), followed by a single . (DOT), followed by a three- 307 letter extension. The extension MUST be one of those enumerated in 308 the "RPKI Repository Naming Scheme" registry maintained by IANA 309 [IANA-NAMING]. 311 As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. 313 4.3. Content-Type Attribute 315 The mandatory content-type attribute MUST have its attrValues field 316 set to the same OID as eContentType. This OID is id-ct-rpkiManifest 317 and has the numerical value of 1.2.840.113549.1.9.16.1.26. 319 4.4. Manifest Validation 321 To determine whether a manifest is valid, the RP MUST perform the 322 following checks in addition to those specified in [RFC6488]: 324 1. The eContentType in the EncapsulatedContentInfo is id-ad- 325 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 327 2. The version of the rpkiManifest is 0. 329 3. In the rpkiManifest, thisUpdate precedes nextUpdate. 331 If the above procedure indicates that the manifest is invalid, then 332 the manifest MUST be discarded and treated as though no manifest were 333 present. 335 5. Manifest Generation 337 5.1. Manifest Generation Procedure 339 For a CA publication point in the RPKI repository system, a CA MUST 340 perform the following steps to generate a manifest: 342 1. If no key pair exists, or if using a "one-time-use" EE 343 certificate with a new key pair, generate a key pair. 345 2. If using a "one-time-use" EE certificate, or if a key pair was 346 generated in step 1, or if using a "sequential-use" EE 347 certificate that will expire before the intended nextUpdate time 348 of this manifest, issue an EE certificate for this key pair. 350 This EE certificate MUST have an SIA extension access description 351 field with an accessMethod OID value of id-ad-signedobject, where 352 the associated accessLocation references the publication point of 353 the manifest as an object URL. 355 This EE certificate MUST describe its Internet Number Resources 356 (INRs) using the "inherit" attribute, rather than explicit 357 description of a resource set (see [RFC3779]). 359 In the case of a "one-time-use" EE certificate, the validity 360 times of the EE certificate MUST exactly match the thisUpdate and 361 nextUpdate times of the manifest. 363 In the case of a "sequential-use" EE certificate, the validity 364 times of the EE certificate MUST encompass the time interval from 365 thisUpdate to nextUpdate. 367 3. The EE certificate MUST NOT be published in the authority's 368 repository publication point. 370 4. Construct the manifest content. 372 The manifest content is described in Section 4.2.1. The 373 manifest's fileList includes the file name and hash pair for each 374 object issued by this CA that has been published at this 375 repository publication point (directory). The collection of 376 objects to be included in the manifest includes all certificates 377 issued by this CA that are published at the CA's repository 378 publication point, the most recent CRL issued by the CA, and all 379 objects verified by EE certificates that were issued by this CA 380 that are published at this repository publication point. 382 Note that the manifest does not include a self reference (i.e., 383 its own file name and hash), since it would be impossible to 384 compute the hash of the manifest itself prior to it being signed. 386 5. Encapsulate the manifest content using the CMS SignedData content 387 type (as specified Section 4), sign the manifest using the 388 private key corresponding to the subject key contained in the EE 389 certificate, and publish the manifest in the repository system 390 publication point that is described by the manifest. 392 6. In the case of a key pair that is to be used only once, in 393 conjunction with a "one-time-use" EE certificate, the private key 394 associated with this key pair MUST now be destroyed. 396 5.2. Considerations for Manifest Generation 398 A new manifest MUST be issued and published on or before the 399 nextUpdate time. 401 An authority MUST issue a new manifest in conjunction with the 402 finalization of changes made to objects in the publication point. An 403 authority MAY perform a number of object operations on a publication 404 repository within the scope of a repository change before issuing a 405 single manifest that covers all the operations within the scope of 406 this change. Repository operators SHOULD implement some form of 407 repository update procedure that mitigates, to the extent possible, 408 the risk that RPs that are performing retrieval operations on the 409 repository are exposed to inconsistent, transient, intermediate 410 states during updates to the repository publication point (directory) 411 and the associated manifest. 413 Since the manifest object URL is included in the SIA of issued 414 certificates, a new manifest MUST NOT invalidate the manifest object 415 URL of previously issued certificates. This implies that the 416 manifest's publication name in the repository, in the form of an 417 object URL, is unchanged across manifest generation cycles. 419 When a CA entity is performing a key rollover, the entity MAY choose 420 to have two CA instances simultaneously publishing into the same 421 repository publication point. In this case, there will be one 422 manifest associated with each active CA instance that is publishing 423 into the common repository publication point (directory). 425 6. Relying Party Processing of Manifests 427 Each RP must determine which signed objects it will use for 428 validating assertions about INRs and their use (e.g., which ROAs to 429 use in the construction of route filters). As noted earlier, 430 manifests are designed to allow an RP to detect manipulation of 431 repository data, errors by a CA or repository manager, and/or active 432 attacks on the communication channel between an RP and a repository. 433 Unless all of the files enumerated in a manifest can be obtained by 434 an RP during a fetch operation, the fetch is considered to have 435 failed and the RP MUST retry the fetch later. 437 [RFC6480] suggests (but does not mandate) that the RPKI model employ 438 fetches that are incremental, e.g., an RP transfers files from a 439 publication point only if they are new/changed since the previous, 440 successful, fetch represented in the RP's local cache. This document 441 avoids language that relies on details of the underlying file 442 transfer mechanism employed by an RP and a publication point to 443 effect this operation. Thus the term "fetch" refers to an operation 444 that attempts to acquire the full set of files at a publication 445 point, consistent with the id-ad-rpkiManifest URI extracted from a CA 446 certificate's SIA (see below). 448 If a fetch fails, it is assumed that a subsequent fetch will resolve 449 problems encountered during the fetch. Until such time as a 450 successful fetch is executed, an RP SHOULD use cached data from a 451 previous, successful fetch. This response is intended to prevent an 452 RP from misinterpreting data associated with a publication point, and 453 thus possibly treating invalid routes as valid, or vice versa. 455 The processing described below is designed to cause all RPs with 456 access to the same local cache and RPKI repository data to achieve 457 the same results with regard to validation of RPKI data. However, in 458 operation, different RPs will access repositories at different times, 459 and some RPs may experience local cache failures, so there is no 460 guarantee that all RPs will achieve the same results with regard to 461 validation of RPKI data. 463 Note that there is a "chicken and egg" relationship between the 464 manifest and the CRL for a given CA instance. If the EE certificate 465 for the current manifest is revoked, i.e., it appears in the current 466 CRL, then the CA or publication point manager has made a serious 467 error. In this case the fetch has failed; proceed to Section 6.7. 468 Similarly, if the CRL is not listed on a valid, current manifest, 469 acquired during a fetch, the fetch has failed; proceed to 470 Section 6.7, because the CRL is considered missing. 472 Note that if a CA and its associated publication point are operating 473 properly, there will always be exactly one manifest and one 474 associated CRL at the publication point identified in the CA's SIA 475 (see below). 477 6.1. Manifest Processing Overview 479 For a given publication point, an RP MUST perform a series of tests 480 to determine which signed object files at the publication point are 481 acceptable. The tests described below (Section 6.2 to Section 6.6) 482 are to be performed using the manifest identified by the id-ad- 483 rpkiManifest URI extracted from a CA certificate's SIA. All of the 484 files referenced by the manifest MUST be be located at the 485 publication point specified by the id-ad-caRepository URI from the 486 (same) CA certificate's SIA. The manifest and the files it 487 references MUST reside at the same publication point. If an RP 488 encounters any files that appear on a manifest but do not reside at 489 the same publication point as the manifest the RP MUST treat the 490 fetch as failed, and a warning MUST be issued (see Section 6.7 491 below). 493 A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be 494 at the location specified in the CRLDP in the manifest's EE 495 certificate. If more than one .crl file appears in the manifest, the 496 fetch has failed and the RP MUST proceed to Section 6.7; otherwise 497 proceed to Section 6.2. 499 Note that, during CA key rollover [RFC6489], signed objects for two 500 or more different CA instances will appear at the same publication 501 point. Manifest processing is to be performed separately for each CA 502 instance, guided by the SIA id-ad-rpkiManifest URI in each CA 503 certificate. 505 6.2. Acquiring a Manifest for a CA 507 The RP MUST fetch the manifest identified by the SIA id-ad- 508 rpkiManifest URI in the CA certificate. If an RP cannot retrieve a 509 manifest using this URI, or if the manifest is not valid 510 (Section 4.4), an RP MUST treat this as a failed fetch and, proceed 511 to Section 6.7; otherwise proceed to Section 6.3. 513 6.3. Detecting Stale and or Prematurely-issued Manifests 515 The RP MUST check that the current time (translated to UTC) is 516 between thisUpdate and nextUpdate. If the current time lies within 517 this interval, proceed to Section 6.4. If the current time is 518 earlier than thisUpdate, the CA has made an error; this is a failed 519 fetch and the RP MUST proceed to Section 6.7. If the current time is 520 later than nextUpdate, then the manifest is stale; this is a failed 521 fetch and RP MUST proceed to Section 6.7; otherwise proceed to 522 Section 6.4. 524 6.4. Acquiring Files Referenced by a Manifest 526 The RP MUST acquire all of the files enumerated in the manifest 527 (fileList) from the publication point. If there are files listed in 528 the manifest that cannot be retrieved from the publication point, or 529 if they fail the validity tests specified in [RFC6488], the fetch has 530 failed and the RP MUST proceed to Section 6.7; otherwise, proceed to 531 Section 6.5. Note that all RPs MUST be able to process Manifests, 532 CRLs and Resource Certificates [RFC6487], BGPsec Router Certificates 533 [RFC8209], Ghostbuster Records [RFC6493], and ROAs [RFC6482]. The 534 set of retrieved objects may include other RPKI object types that the 535 RP is not prepared to process. When such objects are encountered by 536 an RP, the RP MUST NOT attempt to validate the eContent (as described 537 in Section 2.1.3.2 of [RFC8488]) of such objects; encountering such 538 objects does not, per se, result in a failed fetch. 540 6.5. Matching File Names and Hashes 542 The RP MUST verify that the hash value of each file listed in the 543 manifest matches the value obtained by hashing the file acquired from 544 the publication point. If the computed hash value of a file listed 545 on the manifest does not match the hash value contained in the 546 manifest, then the fetch has failed and the RP MUST proceed to 547 Section 6.7; otherwise proceed to Section 6.6. 549 6.6. Out of Scope Manifest Entries 551 If a current manifest contains entries for objects that are not 552 within the scope of the manifest (Section 6.2), the fetch has failed 553 and the RP SHOULD proceed to Section 6.7; otherwise the fetch is 554 deemed successful and the RP will process the fetched objects. 556 6.7. Failed Fetches 558 If a fetch fails for any of the reasons cited in 559 Section 6.2-Section 6.6, the RP MUST issue a warning indicating the 560 reason(s) for termination of processing with regard to this CA 561 instance. It is RECOMMENDED that a human operator be notified of 562 this warning. 564 Termination of processing means that the RP SHOULD continue to use 565 cached versions of the objects associated with this CA instance, 566 until such time as they become stale or they can be replaced by 567 objects from a successful fetch.This implies that the RP MUST not try 568 to acquire and validate subordinate signed objects, e.g., subordinate 569 CA certificates, until the next interval when the RP is scheduled to 570 fetch and process data for this CA instance. 572 7. Publication Repositories 574 The RPKI publication system model requires that every publication 575 point be associated with one or more CAs, and be non-empty. Upon 576 creation of the publication point associated with a CA, the CA MUST 577 create and publish a manifest as well as a CRL. A CA's manifest will 578 always contain at least one entry, namely, the CRL issued by the CA 579 upon repository creation [RFC6481]. 581 Every published signed object in the RPKI [RFC6488] is published in 582 the repository publication point of the CA that issued the EE 583 certificate, and is listed in the manifest associated with that CA 584 certificate. 586 8. Security Considerations 588 Manifests provide an additional level of protection for RPKI RPs. 589 Manifests can assist an RP to determine if a repository object has 590 been deleted, occluded, or otherwise removed from view, or if a 591 publication of a newer version of an object has been suppressed (and 592 an older version of the object has been substituted). 594 Manifests cannot repair the effects of such forms of corruption of 595 repository retrieval operations. However, a manifest enables an RP 596 to determine if a locally maintained copy of a repository is a 597 complete and up-to-date copy, even when the repository retrieval 598 operation is conducted over an insecure channel. In cases where the 599 manifest and the retrieved repository contents differ, the manifest 600 can assist in determining which repository objects form the 601 difference set in terms of missing, extraneous, or superseded 602 objects. 604 The signing structure of a manifest and the use of the nextUpdate 605 value allows an RP to determine if the manifest itself is the subject 606 of attempted alteration. The requirement for every repository 607 publication point to contain at least one manifest allows an RP to 608 determine if the manifest itself has been occluded from view. Such 609 attacks against the manifest are detectable within the time frame of 610 the regular schedule of manifest updates. Forms of replay attack 611 within finer-grained time frames are not necessarily detectable by 612 the manifest structure. 614 9. IANA Considerations 616 As [RFC6488] created and populated the registries "RPKI Signed 617 Object" and three-letter filename extensions for "RPKI Repository 618 Name Schemes," no new action is requested of the IANA. 620 10. Acknowledgements 622 The authors would like to acknowledge the contributions from George 623 Michelson and Randy Bush in the preparation of the manifest 624 specification. Additionally, the authors would like to thank Mark 625 Reynolds and Christopher Small for assistance in clarifying manifest 626 validation and RP behavior. The authors also wish to thank Job 627 Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of 628 this document. 630 11. References 632 11.1. Normative References 634 [IANA-NAMING] 635 "RPKI Repository Name Schemes", 636 . 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 645 Housley, R., and W. Polk, "Internet X.509 Public Key 646 Infrastructure Certificate and Certificate Revocation List 647 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 648 . 650 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 651 Resource Certificate Repository Structure", RFC 6481, 652 DOI 10.17487/RFC6481, February 2012, 653 . 655 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 656 Origin Authorizations (ROAs)", RFC 6482, 657 DOI 10.17487/RFC6482, February 2012, 658 . 660 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 661 Use in the Resource Public Key Infrastructure (RPKI)", 662 RFC 6485, DOI 10.17487/RFC6485, February 2012, 663 . 665 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 666 X.509 PKIX Resource Certificates", RFC 6487, 667 DOI 10.17487/RFC6487, February 2012, 668 . 670 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 671 Template for the Resource Public Key Infrastructure 672 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 673 . 675 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 676 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 677 February 2012, . 679 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 680 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 681 May 2017, . 683 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 684 BGPsec Router Certificates, Certificate Revocation Lists, 685 and Certification Requests", RFC 8209, 686 DOI 10.17487/RFC8209, September 2017, 687 . 689 [RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's 690 Implementation of Resource Public Key Infrastructure 691 (RPKI) Certificate Tree Validation", RFC 8488, 692 DOI 10.17487/RFC8488, December 2018, 693 . 695 [X.690] International International Telephone and Telegraph 696 Consultative Committee, "ASN.1 encoding rules: 697 Specification of basic encoding Rules (BER), Canonical 698 encoding rules (CER) and Distinguished encoding rules 699 (DER)", CCITT Recommendation X.690, July 2002. 701 11.2. Informative References 703 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 704 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 705 . 707 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 708 Addresses and AS Identifiers", RFC 3779, 709 DOI 10.17487/RFC3779, June 2004, 710 . 712 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 713 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 714 February 2012, . 716 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 717 Authority (CA) Key Rollover in the Resource Public Key 718 Infrastructure (RPKI)", BCP 174, RFC 6489, 719 DOI 10.17487/RFC6489, February 2012, 720 . 722 Appendix A. ASN.1 Module 723 RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) 724 pkcs(1) pkcs9(9) smime(16) mod(0) 60 } 726 DEFINITIONS EXPLICIT TAGS ::= 728 BEGIN 730 -- EXPORTS ALL -- 732 -- IMPORTS NOTHING -- 734 -- Manifest Content Type: OID 736 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 737 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 739 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 741 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 743 -- Manifest Content Type: eContent 745 Manifest ::= SEQUENCE { 746 version [0] INTEGER DEFAULT 0, 747 manifestNumber INTEGER (0..MAX), 748 thisUpdate GeneralizedTime, 749 nextUpdate GeneralizedTime, 750 fileHashAlg OBJECT IDENTIFIER, 751 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 752 } 754 FileAndHash ::= SEQUENCE { 755 file IA5String, 756 hash BIT STRING 757 } 759 END 761 Authors' Addresses 763 Rob Austein 764 Arrcus, Inc. 766 Email: sra@hactrn.net 767 Geoff Huston 768 APNIC 769 6 Cordelia St 770 South Brisbane QLD 4101 771 Australia 773 Email: gih@apnic.net 775 Stephen Kent 776 Independent 778 Email: kent@alum.mit.edu 780 Matt Lepinski 781 New College Florida 782 5800 Bay Shore Rd. 783 Sarasota, FL 34243 784 USA 786 Email: mlepinski@ncf.edu