idnits 2.17.1 draft-ietf-sidrops-6486bis-07.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 (14 October 2021) is 917 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 204 == Unused Reference: 'RFC6482' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC6493' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RFC8209' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'RFC8488' is defined on line 673, but no explicit reference was found in the text -- 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 (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDROPS R. Austein 3 Internet-Draft Arrcus, Inc. 4 Updates: 6486 (if approved) G. Huston 5 Intended status: Standards Track APNIC 6 Expires: 17 April 2022 S. Kent 7 Independent 8 M. Lepinski 9 New College Florida 10 14 October 2021 12 Manifests for the Resource Public Key Infrastructure (RPKI) 13 draft-ietf-sidrops-6486bis-07 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 17 April 2022. 49 Copyright Notice 51 Copyright (c) 2021 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 (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Manifest Definition . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. eContentType . . . . . . . . . . . . . . . . . . . . . . 4 71 4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2.2. Names in FileAndHash objects . . . . . . . . . . . . 7 74 4.3. Content-Type Attribute . . . . . . . . . . . . . . . . . 7 75 4.4. Manifest Validation . . . . . . . . . . . . . . . . . . . 7 76 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 7 77 5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8 78 5.2. Considerations for Manifest Generation . . . . . . . . . 9 79 6. Relying Party Processing of Manifests . . . . . . . . . . . . 10 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. Failed Fetches . . . . . . . . . . . . . . . . . . . . . 12 86 7. Publication Repositories . . . . . . . . . . . . . . . . . . 12 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 11.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of 99 a distributed repository system [RFC6481] to make available a variety 100 of objects needed by relying parties (RPs). Because all of the 101 objects stored in the repository system are digitally signed by the 102 entities that created them, attacks that modify these published 103 objects are detectable by RPs. However, digital signatures provide 104 no protection against attacks that substitute "stale" versions of 105 signed objects (i.e., objects that were valid and have not expired, 106 but have since been superseded) or attacks that remove an object that 107 should be present in the repository. To assist in the detection of 108 such attacks, the RPKI repository system can make use of a signed 109 object called a "manifest". 111 A manifest is a signed object that enumerates all the signed objects 112 (files) in the repository publication point (directory) that are 113 associated with an authority responsible for publishing at that 114 publication point. Each manifest contains both the name of the file 115 containing the object and a hash of the file content, for every 116 signed object issued by an authority that is published at the 117 authority's repository publication point. A manifest is intended to 118 allow an RP to detect unauthorized object removal or the substitution 119 of stale versions of objects at a publication point. A manifest also 120 is intended to allow an RP to detect similar outcomes that may result 121 from a man-in-the-middle attack on the retrieval of objects from the 122 repository. Manifests are intended to be used in Certification 123 Authority (CA) publication points in repositories (directories 124 containing files that are subordinate certificates and Certificate 125 Revocation Lists (CRLs) issued by this CA and other signed objects 126 that are verified by end-entity (EE) certificates issued by this CA). 128 Manifests are modeled on CRLs, as the issues involved in detecting 129 stale manifests and potential attacks using manifest replays, etc., 130 are similar to those for CRLs. The syntax of the manifest payload 131 differs from CRLs, since RPKI repositories contain objects not 132 covered by CRLs, e.g., digitally signed objects, such as Route 133 Origination Authorizations (ROAs). 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2. Manifest Scope 145 A manifest associated with a CA's repository publication point 146 contains a list of: 148 * the set of (non-expired, non-revoked) certificates issued and 149 published by this CA, 151 * the most recent CRL issued by this CA, and 153 * all published signed objects that are verifiable using EE 154 certificates [RFC6487] issued by this CA (other than the manifest 155 itself). 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 a CA 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 MUST sign only one manifest with each generated private key, 175 and MUST 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.[RFC6487] 179 4. Manifest Definition 181 A manifest is an RPKI signed object, as specified in [RFC6488]. The 182 RPKI signed object template requires specification of the following 183 data elements in the context of the manifest structure. 185 4.1. eContentType 187 The eContentType for a manifest is defined as id-ct-rpkiManifest and 188 has the numerical value of 1.2.840.113549.1.9.16.1.26. 190 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 191 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 193 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 195 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 197 4.2. eContent 199 The content of a manifest is ASN.1 encoded using the Distinguished 200 Encoding Rules (DER) [X.690]. The content of a manifest is defined 201 as follows: 203 Manifest ::= SEQUENCE { 204 version [0] INTEGER DEFAULT 0, 205 manifestNumber INTEGER (0..MAX), 206 thisUpdate GeneralizedTime, 207 nextUpdate GeneralizedTime, 208 fileHashAlg OBJECT IDENTIFIER, 209 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 210 } 212 FileAndHash ::= SEQUENCE { 213 file IA5String, 214 hash BIT STRING 215 } 217 4.2.1. Manifest 219 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 220 after the corresponding fields in X.509 CRLs (see [RFC5280]). 221 Analogous to CRLs, a manifest is nominally current until the time 222 specified in nextUpdate or until a manifest is issued with a greater 223 manifest number, whichever comes first. 225 Because a "one-time-use" EE certificate is employed to verify a 226 manifest, it is RECOMMENDED that the EE certificate have a validity 227 period that coincides with the interval from thisUpdate to nextUpdate 228 in the manifest, to prevent needless growth of the CA's CRL. 230 The data elements of the manifest structure are defined as follows: 232 version: 233 The version number of this version of the manifest specification 234 MUST be 0. 236 manifestNumber: 238 This field is an integer that is incremented (by 1) each time a 239 new manifest is issued for a given publication point. This field 240 allows an RP to detect gaps in a sequence of published manifests. 242 As the manifest is modeled on the CRL specification, the 243 ManifestNumber is analogous to the CRLNumber, and the guidance in 244 [RFC5280] for CRLNumber values is appropriate as to the range of 245 number values that can be used for the manifestNumber. Manifest 246 numbers can be expected to contain long integers. Manifest 247 verifiers MUST be able to process number values up to 20 octets. 248 Conforming manifest issuers MUST NOT use number values longer than 249 20 octets. The issuer MUST increase the value of this field 250 monotonically for each newly-generated Manifest. Each RP MUST 251 verify that a purported "new" Manifest contains a higher 252 manifestNumber than previously-validated Manifests. 254 thisUpdate: 255 This field contains the time when the manifest was created. This 256 field has the same format constraints as specified in [RFC5280] 257 for the CRL field of the same name. The issuer MUST ensure that 258 the value of this field is more recent any previously-generated 259 Manifest. Each RP MUST verify that this field value is greater 260 (more recent) than the most recent Manifest it has validated. 262 nextUpdate: 263 This field contains the time at which the next scheduled manifest 264 will be issued. The value of nextUpdate MUST be later than the 265 value of thisUpdate. The specification of the GeneralizedTime 266 value is the same as required for the thisUpdate field. 268 If the authority alters any of the items that it has published in 269 the repository publication point, then the authority MUST issue a 270 new manifest. Even if no changes are made to objects at a 271 publication point, a new manifest MUST be issued before the 272 nextUpdate time. Each manifest encompasses a CRL, and the 273 nextUpdate field of the manifest SHOULD match that of the CRL's 274 nextUpdate field, as the manifest will be re-issued when a new CRL 275 is published. When a new manifest is issued before the time 276 specified in nextUpdate of the current manifest, the CA MUST also 277 issue a new CRL that revokes the EE certificate corresponding to 278 the old manifest. 280 fileHashAlg: 281 This field contains the OID of the hash algorithm used to hash the 282 files that the authority has placed into the repository. The hash 283 algorithm used MUST conform to the RPKI Algorithms and Key Size 284 Profile specification [RFC6485]. 286 fileList: 287 This field is a sequence of FileAndHash objects. There is one 288 FileAndHash entry for each currently valid signed object that has 289 been published by the authority (at this publication point). Each 290 FileAndHash is an ordered pair consisting of the name of the file 291 in the repository publication point (directory) that contains the 292 object in question and a hash of the file's contents. 294 4.2.2. Names in FileAndHash objects 296 Names that appear in the fileList MUST consist of one or more 297 characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ 298 (UNDERSCORE), followed by a single . (DOT), followed by a three- 299 letter extension. The extension MUST be one of those enumerated in 300 the "RPKI Repository Naming Scheme" registry maintained by IANA 301 [IANA-NAMING]. 303 As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. 305 4.3. Content-Type Attribute 307 The mandatory content-type attribute MUST have its attrValues field 308 set to the same OID as eContentType. This OID is id-ct-rpkiManifest 309 and has the numerical value of 1.2.840.113549.1.9.16.1.26. 311 4.4. Manifest Validation 313 To determine whether a manifest is valid, the RP MUST perform the 314 following checks in addition to those specified in [RFC6488]: 316 1. The eContentType in the EncapsulatedContentInfo is id-ad- 317 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 319 2. The version of the rpkiManifest is 0. 321 3. In the rpkiManifest, thisUpdate precedes nextUpdate. 323 Note: Although it is RECOMMENDED that the thisUpdate and nextUpdate 324 fields in the manifest match the corresponding fields in the CRL 325 associated with the manifest, RPs SHOULD NOT reject a manifest if 326 these fields do not match. 328 If the above procedure indicates that the manifest is invalid, then 329 the manifest MUST be discarded and treated as though no manifest were 330 present. 332 5. Manifest Generation 333 5.1. Manifest Generation Procedure 335 For a CA publication point in the RPKI repository system, a CA MUST 336 perform the following steps to generate a manifest: 338 1. Generate a new key pair for use in a "one-time-use" EE 339 certificate. 341 2. Issue an EE certificate for this key pair. The CA MUST revoke 342 the EE certificate used for the manifest being replaced. 344 This EE certificate MUST have an SIA extension access description 345 field with an accessMethod OID value of id-ad-signedobject, where 346 the associated accessLocation references the publication point of 347 the manifest as an object URL.(RPs are required to verify this.) 349 This EE certificate MUST describe its Internet Number Resources 350 (INRs) using the "inherit" attribute, rather than explicit 351 description of a resource set (see [RFC3779]).(RPs are required 352 to verify this.) 354 It is RECOMMENDED that the validity interval of the EE 355 certificate exactly match the thisUpdate and nextUpdate times of 356 the manifest. 358 Note: An RP MUST verify all mandated syntactic constraints, i.e., 359 constraints imposed on a CA via a "MUST". 361 3. The EE certificate MUST NOT be published in the authority's 362 repository publication point. 364 4. Construct the manifest content. 366 The manifest content is described in Section 4.2.1. The 367 manifest's fileList includes the file name and hash pair for each 368 object issued by this CA that has been published at this 369 repository publication point (directory). The collection of 370 objects to be included in the manifest includes all certificates 371 issued by this CA that are published at the CA's repository 372 publication point, the most recent CRL issued by the CA, and all 373 objects verified by EE certificates that were issued by this CA 374 that are published at this repository publication point. 375 (Sections 6.1-5 describes the checks that an RP MUST perform in 376 support of the manifest content noted here.) 378 Note that the manifest does not include a self reference (i.e., 379 its own file name and hash), since it would be impossible to 380 compute the hash of the manifest itself prior to it being signed. 382 5. Encapsulate the manifest content using the CMS SignedData content 383 type (as specified Section 4), sign the manifest using the 384 private key corresponding to the subject key contained in the EE 385 certificate, and publish the manifest in the repository system 386 publication point that is described by the manifest. (RPs are 387 required to verify the CMS signature.) 389 6. Because the key pair is to be used only once, the private key 390 associated with this key pair MUST now be destroyed. 392 5.2. Considerations for Manifest Generation 394 A new manifest MUST be issued and published before the nextUpdate 395 time. 397 An authority MUST issue a new manifest in conjunction with the 398 finalization of changes made to objects in the publication point. If 399 any named objects in the publication point are replaced, the 400 authority MUST ensure that the file hash for each replaced object is 401 updated accordingly in the new manifest. Additionally, the authority 402 MUST revoke the certificate associated with each replaced object 403 (other than a CRL), if it is not expired. An authority MAY perform a 404 number of object operations on a publication repository within the 405 scope of a repository change before issuing a single manifest that 406 covers all the operations within the scope of this change. 407 Repository operators MUST implement some form of repository update 408 procedure that mitigates, to the extent possible, the risk that RPs 409 that are performing retrieval operations on the repository are 410 exposed to inconsistent, transient, intermediate states during 411 updates to the repository publication point (directory) and the 412 associated manifest. 414 Since the manifest object URL is included in the SIA of issued 415 certificates, a new manifest MUST NOT invalidate the manifest object 416 URL of previously issued certificates. This implies that the 417 manifest's publication name in the repository, in the form of an 418 object URL, is unchanged across manifest generation cycles. 420 When a CA entity is performing a key rollover, the entity MAY choose 421 to have two CA instances simultaneously publishing into the same 422 repository publication point. In this case, there will be one 423 manifest associated with each active CA instance that is publishing 424 into the common repository publication point (directory). 426 6. Relying Party Processing of Manifests 428 Each RP MUST use the current manifest of a CA to control addition of 429 listed files to the set of signed objects the RP employs for 430 validating basic RPKI objects: certificates, ROAs, and CRLs. Any 431 files not listed on the manifest MUST NOT be used for validation of 432 these objects. However, files not listed on a manifest MAY be 433 employed to validate other signed objects, if the profile of the 434 object type explicitly states that such behavior is allowed (or 435 required). Note that relying on files not listed in a manifest may 436 allow an attacker to effect substitution attacks against such 437 objects. 439 As noted earlier, manifests are designed to allow an RP to detect 440 manipulation of repository data, errors by a CA or repository 441 manager, and/or active attacks on the communication channel between 442 an RP and a repository. Unless all of the files enumerated in a 443 manifest can be obtained by an RP during a fetch operation, the fetch 444 is considered to have failed and the RP MUST retry the fetch later. 446 [RFC6480] suggests (but does not mandate) that the RPKI model employ 447 fetches that are incremental, e.g., an RP transfers files from a 448 publication point only if they are new/changed since the previous, 449 successful, fetch represented in the RP's local cache. This document 450 avoids language that relies on details of the underlying file 451 transfer mechanism employed by an RP and a publication point to 452 effect this operation. Thus the term "fetch" refers to an operation 453 that attempts to acquire the full set of files at a publication 454 point, consistent with the id-ad-rpkiManifest URI extracted from a CA 455 certificate's SIA (see below). 457 If a fetch fails, it is assumed that a subsequent fetch will resolve 458 problems encountered during the fetch. Until such time as a 459 successful fetch is executed, an RP SHOULD use cached data from a 460 previous, successful fetch. This response is intended to prevent an 461 RP from misinterpreting data associated with a publication point, and 462 thus possibly treating invalid routes as valid, or vice versa. 464 The processing described below is designed to cause all RPs with 465 access to the same local cache and RPKI repository data to acquire 466 the same set of validated repository files. It does not ensure that 467 the RPs will achieve the same results with regard to validation of 468 RPKI data, since that depends on how each RP resolves any conflicts 469 that may arise in processing the retrieved files. Moreover, in 470 operation, different RPs will access repositories at different times, 471 and some RPs may experience local cache failures, so there is no 472 guarantee that all RPs will achieve the same results with regard to 473 acquisition or validation of RPKI data. 475 Note also that there is a "chicken and egg" relationship between the 476 manifest and the CRL for a given CA instance. If the EE certificate 477 for the current manifest is revoked, i.e., it appears in the current 478 CRL, then the CA or publication point manager has made a serious 479 error. In this case the fetch has failed; proceed to Section 6.6. 480 Similarly, if the CRL is not listed on a valid, current manifest, 481 acquired during a fetch, the fetch has failed; proceed to 482 Section 6.6, because the CRL is considered missing. 484 6.1. Manifest Processing Overview 486 For a given publication point, an RP MUST perform a series of tests 487 to determine which signed object files at the publication point are 488 acceptable. The tests described below (Section 6.2 to Section 6.5) 489 are to be performed using the manifest identified by the id-ad- 490 rpkiManifest URI extracted from a CA certificate's SIA. All of the 491 files referenced by the manifest MUST be located at the publication 492 point specified by the id-ad-caRepository URI from the (same) CA 493 certificate's SIA. The manifest and the files it references MUST 494 reside at the same publication point. If an RP encounters any files 495 that appear on a manifest but do not reside at the same publication 496 point as the manifest the RP MUST treat the fetch as failed, and a 497 warning MUST be issued (see Section 6.6 below). 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.6; 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.6. 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.6; 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, the 529 fetch has failed and the RP MUST proceed to Section 6.6; otherwise, 530 proceed to Section 6.5. 532 6.5. Matching File Names and Hashes 534 The RP MUST verify that the hash value of each file listed in the 535 manifest matches the value obtained by hashing the file acquired from 536 the publication point. If the computed hash value of a file listed 537 on the manifest does not match the hash value contained in the 538 manifest, then the fetch has failed and the RP MUST proceed to 539 Section 6.6; otherwise proceed to Section 6.6. 541 6.6. Failed Fetches 543 If a fetch fails for any of the reasons cited in 6.2-6.5, the RP MUST 544 issue a warning indicating the reason(s)for termination of processing 545 with regard to this CA instance. It is RECOMMENDED that a human 546 operator be notified of this warning. 548 Termination of processing means that the RP SHOULD continue to use 549 cached versions of the objects associated with this CA instance, 550 until such time as they become stale or they can be replaced by 551 objects from a successful fetch. This implies that the RP MUST not 552 try to acquire and validate subordinate signed objects, e.g., 553 subordinate CA certificates, until the next interval when the RP is 554 scheduled to fetch and process data for this CA instance. 556 7. Publication Repositories 558 The RPKI publication system model requires that every publication 559 point be associated with one or more CAs, and be non-empty. Upon 560 creation of the publication point associated with a CA, the CA MUST 561 create and publish a manifest as well as a CRL. A CA's manifest will 562 always contain at least one entry, i.e., a CRL issued by the CA 563 [RFC6481],corresponding to the scope of this manifest. 565 Every published signed object in the RPKI [RFC6488] is published in 566 the repository publication point of the CA that issued the EE 567 certificate, and is listed in the manifest associated with that CA 568 certificate. 570 8. Security Considerations 572 Manifests provide an additional level of protection for RPKI RPs. 573 Manifests can assist an RP to determine if a repository object has 574 been deleted, occluded, or otherwise removed from view, or if a 575 publication of a newer version of an object has been suppressed (and 576 an older version of the object has been substituted). 578 Manifests cannot repair the effects of such forms of corruption of 579 repository retrieval operations. However, a manifest enables an RP 580 to determine if a locally maintained copy of a repository is a 581 complete and up-to-date copy, even when the repository retrieval 582 operation is conducted over an insecure channel. In cases where the 583 manifest and the retrieved repository contents differ, the manifest 584 can assist in determining which repository objects form the 585 difference set in terms of missing, extraneous, or superseded 586 objects. 588 The signing structure of a manifest and the use of the nextUpdate 589 value allows an RP to determine if the manifest itself is the subject 590 of attempted alteration. The requirement for every repository 591 publication point to contain at least one manifest allows an RP to 592 determine if the manifest itself has been occluded from view. Such 593 attacks against the manifest are detectable within the time frame of 594 the regular schedule of manifest updates. Forms of replay attack 595 within finer-grained time frames are not necessarily detectable by 596 the manifest structure. 598 9. IANA Considerations 600 As [RFC6488] created and populated the registries "RPKI Signed 601 Object" and three-letter filename extensions for "RPKI Repository 602 Name Schemes," no new action is requested of the IANA. 604 10. Acknowledgements 606 The authors would like to acknowledge the contributions from George 607 Michelson and Randy Bush in the preparation of the manifest 608 specification. Additionally, the authors would like to thank Mark 609 Reynolds and Christopher Small for assistance in clarifying manifest 610 validation and RP behavior. The authors also wish to thank Tim 611 Bruijnzeels, Job Snijders, Oleg Muravskiy, and Sean Turner for their 612 helpful review of this document. 614 11. References 616 11.1. Normative References 618 [IANA-NAMING] 619 "RPKI Repository Name Schemes", 620 . 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997, 626 . 628 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 629 Housley, R., and W. Polk, "Internet X.509 Public Key 630 Infrastructure Certificate and Certificate Revocation List 631 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 632 . 634 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 635 Resource Certificate Repository Structure", RFC 6481, 636 DOI 10.17487/RFC6481, February 2012, 637 . 639 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 640 Origin Authorizations (ROAs)", RFC 6482, 641 DOI 10.17487/RFC6482, February 2012, 642 . 644 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 645 Use in the Resource Public Key Infrastructure (RPKI)", 646 RFC 6485, DOI 10.17487/RFC6485, February 2012, 647 . 649 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 650 X.509 PKIX Resource Certificates", RFC 6487, 651 DOI 10.17487/RFC6487, February 2012, 652 . 654 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 655 Template for the Resource Public Key Infrastructure 656 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 657 . 659 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 660 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 661 February 2012, . 663 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 664 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 665 May 2017, . 667 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 668 BGPsec Router Certificates, Certificate Revocation Lists, 669 and Certification Requests", RFC 8209, 670 DOI 10.17487/RFC8209, September 2017, 671 . 673 [RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's 674 Implementation of Resource Public Key Infrastructure 675 (RPKI) Certificate Tree Validation", RFC 8488, 676 DOI 10.17487/RFC8488, December 2018, 677 . 679 [X.690] "X.690", 680 . 682 11.2. Informative References 684 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 685 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 686 . 688 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 689 Addresses and AS Identifiers", RFC 3779, 690 DOI 10.17487/RFC3779, June 2004, 691 . 693 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 694 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 695 February 2012, . 697 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 698 Authority (CA) Key Rollover in the Resource Public Key 699 Infrastructure (RPKI)", BCP 174, RFC 6489, 700 DOI 10.17487/RFC6489, February 2012, 701 . 703 Appendix A. ASN.1 Module 705 Authors' Addresses 707 Rob Austein 708 Arrcus, Inc. 710 Email: sra@hactrn.net 711 Geoff Huston 712 APNIC 713 6 Cordelia St 714 South Brisbane QLD 4101 715 Australia 717 Email: gih@apnic.net 719 Stephen Kent 720 Independent 722 Email: kent@alum.mit.edu 724 Matt Lepinski 725 New College Florida 726 5800 Bay Shore Rd. 727 Sarasota, FL 34243 728 USA 730 Email: mlepinski@ncf.edu