idnits 2.17.1 draft-ietf-sidrops-6486bis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 March 2022) is 735 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 740 == Missing Reference: 'RFC6268' is mentioned on line 723, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-NAMING' -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Obsoletes: 6486 (if approved) G. Huston 5 Intended status: Standards Track APNIC 6 Expires: 25 September 2022 S. Kent 7 Independent 8 M. Lepinski 9 New College Florida 10 24 March 2022 12 Manifests for the Resource Public Key Infrastructure (RPKI) 13 draft-ietf-sidrops-6486bis-11 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 replay attacks, 30 and unauthorized in-flight modification or deletion of signed 31 objects. This document obsoletes RFC 6486. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 25 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. eContentType . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . 12 84 6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 12 85 6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12 86 6.6. 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 Appendix B. Changes since RFC 6486 . . . . . . . . . . . . . . . 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 alone 106 provide no protection against attacks that substitute "stale" 107 versions of signed objects (i.e., objects that were valid and have 108 not yet expired, but have since been superseded), or in-flight 109 attacks that remove an object that should be present in the 110 repository. To assist in the detection of such attacks, RPKI 111 repository systems make use of a signed 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 an on-path attack during 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) [RFC6482]. 137 This document obsoletes [RFC6486]. 139 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 2. Manifest Scope 149 A manifest associated with a CA's repository publication point 150 contains a list of: 152 * the set of (non-expired, non-revoked) certificates issued and 153 published by this CA, 155 * the most recent CRL issued by this CA, and 157 * all published signed objects that are verifiable using EE 158 certificates [RFC6487] issued by this CA (other than the manifest 159 itself). 161 Every RPKI signed object includes, in the Cryptographic Message 162 Syntax (CMS) [RFC5652] wrapper of the object, the EE certificate used 163 to verify it [RFC6488]. Thus, there is no requirement to separately 164 publish that EE certificate at the CA's repository publication point. 166 Where multiple CA instances share a common publication point, as can 167 occur when a CA performs a key-rollover operation [RFC6489], the 168 repository publication point will contain multiple manifests. In 169 this case, each manifest describes only the collection of published 170 products of its associated CA instance. 172 3. Manifest Signing 174 A CA's manifest is verified using an EE certificate. The 175 SubjectInfoAccess (SIA) field of this EE certificate contains the 176 access method Object Identifier (OID) of id-ad-signedObject. 178 The CA MUST sign only one manifest with each generated private key, 179 and MUST generate a new key pair for each new version of the 180 manifest. This form of use of the associated EE certificate is 181 termed a "one-time-use" EE certificate [RFC6487]. 183 4. Manifest Definition 185 A manifest is an RPKI signed object, as specified in [RFC6488]. The 186 RPKI signed object template requires specification of the following 187 data elements in the context of the manifest structure. 189 4.1. eContentType 191 The eContentType for a manifest is defined as id-ct-rpkiManifest and 192 has the numerical object identifier of 1.2.840.113549.1.9.16.1.26. 194 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 195 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 197 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 199 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 201 4.2. eContent 203 The content of a manifest is ASN.1 encoded using the Distinguished 204 Encoding Rules (DER) [X.690]. The content of a manifest is defined 205 as follows: 207 Manifest ::= SEQUENCE { 208 version [0] INTEGER DEFAULT 0, 209 manifestNumber INTEGER (0..MAX), 210 thisUpdate GeneralizedTime, 211 nextUpdate GeneralizedTime, 212 fileHashAlg OBJECT IDENTIFIER, 213 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 214 } 216 FileAndHash ::= SEQUENCE { 217 file IA5String, 218 hash BIT STRING 219 } 221 4.2.1. Manifest 223 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 224 after the corresponding fields in X.509 CRLs (see [RFC5280]). 225 Analogous to CRLs, a manifest is nominally current until the time 226 specified in nextUpdate or until a manifest is issued with a greater 227 manifest number, whichever comes first. 229 Because a "one-time-use" EE certificate is employed to verify a 230 manifest, the EE certificate MUST be issued with a validity period 231 that coincides with the interval from thisUpdate to nextUpdate in the 232 manifest, to prevent needless growth of the CA's CRL. 234 The data elements of the manifest structure are defined as follows: 236 version: 237 The version number of this version of the manifest specification 238 MUST be 0. 240 manifestNumber: 242 This field is an integer that is incremented (by 1) each time a 243 new manifest is issued for a given publication point. This field 244 allows an RP to detect gaps in a sequence of published manifests. 246 As the manifest is modeled on the CRL specification, the 247 ManifestNumber is analogous to the CRLNumber, and the guidance in 248 [RFC5280] for CRLNumber values is appropriate as to the range of 249 number values that can be used for the manifestNumber. Manifest 250 numbers can be expected to contain long integers. Manifest 251 verifiers MUST be able to process number values up to 20 octets. 252 Conforming manifest issuers MUST NOT use number values longer than 253 20 octets. The issuer MUST increase the value of this field 254 monotonically for each newly-generated Manifest. Each RP MUST 255 verify that a purported "new" Manifest contains a higher 256 manifestNumber than previously-validated Manifests. If the 257 purported "new" Manifest contains an equal or lower manifestNumber 258 than previously-validated Manifests, the RP SHOULD use locally 259 cached versions of objects, as described in Section 6.6. 261 thisUpdate: 262 This field contains the time when the manifest was created. This 263 field has the same format constraints as specified in [RFC5280] 264 for the CRL field of the same name. The issuer MUST ensure that 265 the value of this field is more recent than any previously- 266 generated Manifest. Each RP MUST verify that this field value is 267 greater (more recent) than the most recent Manifest it has 268 validated. If this field in a purported "new" Manifest is smaller 269 (less recent) than previously-validated Manifests, the RP SHOULD 270 use locally cached versions of objects, as described in 271 Section 6.6. 273 nextUpdate: 274 This field contains the time at which the next scheduled manifest 275 will be issued. The value of nextUpdate MUST be later than the 276 value of thisUpdate. The specification of the GeneralizedTime 277 value is the same as required for the thisUpdate field. 279 If the authority alters any of the items that it has published in 280 the repository publication point, then the authority MUST issue a 281 new manifest. Even if no changes are made to objects at a 282 publication point, a new manifest MUST be issued before the 283 nextUpdate time. Each manifest encompasses a CRL, and the 284 nextUpdate field of the manifest SHOULD match that of the CRL's 285 nextUpdate field, as the manifest will be re-issued when a new CRL 286 is published. When a new manifest is issued before the time 287 specified in nextUpdate of the current manifest, the CA MUST also 288 issue a new CRL that revokes the EE certificate corresponding to 289 the old manifest. 291 fileHashAlg: 292 This field contains the OID of the hash algorithm used to hash the 293 files that the authority has placed into the repository. The hash 294 algorithm used MUST conform to the RPKI Algorithms and Key Size 295 Profile specification [RFC7935]. 297 fileList: 298 This field is a sequence of FileAndHash objects. There is one 299 FileAndHash entry for each currently valid signed object that has 300 been published by the authority (at this publication point). Each 301 FileAndHash is an ordered pair consisting of the name of the file 302 in the repository publication point (directory) that contains the 303 object in question and a hash of the file's contents. 305 4.2.2. Names in FileAndHash objects 307 Names that appear in the fileList MUST consist of one or more 308 characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ 309 (UNDERSCORE), followed by a single . (DOT), followed by a three- 310 letter extension. The extension MUST be one of those enumerated in 311 the "RPKI Repository Naming Scheme" registry maintained by IANA 312 [IANA-NAMING]. 314 As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. 316 The example above contains a mix of uppercase and lowercase 317 characters in the filename. CAs and RPs MUST be able to perform 318 filesystem operations in a case-sensitive, case-preserving manner. 320 4.3. Content-Type Attribute 322 The mandatory content-type attribute MUST have its attrValues field 323 set to the same OID as eContentType. This OID is id-ct-rpkiManifest 324 and has the numerical value of 1.2.840.113549.1.9.16.1.26. 326 4.4. Manifest Validation 328 To determine whether a manifest is valid, the RP MUST perform the 329 following checks in addition to those specified in [RFC6488]: 331 1. The eContentType in the EncapsulatedContentInfo is id-ad- 332 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 334 2. The version of the rpkiManifest is 0. 336 3. In the rpkiManifest, thisUpdate precedes nextUpdate. 338 Note: Although the thisUpdate and nextUpdate fields in the Manifest 339 eContent MUST match the corresponding fields in the CRL associated 340 with the Manifest, RPs MUST NOT reject a manifest solely because 341 these fields are not identical. 343 If the above procedure indicates that the manifest is invalid, then 344 the manifest MUST be discarded and treated as though no manifest were 345 present. 347 5. Manifest Generation 349 5.1. Manifest Generation Procedure 351 For a CA publication point in the RPKI repository system, a CA MUST 352 perform the following steps to generate a manifest: 354 1. Generate a new key pair for use in a "one-time-use" EE 355 certificate. 357 2. Issue an EE certificate for this key pair. The CA MUST revoke 358 the EE certificate used for the manifest being replaced. 360 This EE certificate MUST have an SIA extension access description 361 field with an accessMethod OID value of id-ad-signedobject, where 362 the associated accessLocation references the publication point of 363 the manifest as an object URL. (RPs are required to verify both 364 of these syntactic constraints.) 366 This EE certificate MUST describe its Internet Number Resources 367 (INRs) using the "inherit" attribute, rather than explicit 368 description of a resource set (see [RFC3779]). (RPs are required 369 to verify this.) 371 The validity interval of the EE certificate MUST exactly match 372 the thisUpdate and nextUpdate times specified in the manifest's 373 eContent. (An RP MUST NOT consider misalignment of the validity 374 interval misalignment in and of itself to be an error.) 376 3. The EE certificate MUST NOT be published in the authority's 377 repository publication point. 379 4. Construct the manifest content. 381 The manifest content is described in Section 4.2.1. The 382 manifest's fileList includes the file name and hash pair for each 383 object issued by this CA that has been published at this 384 repository publication point (directory). The collection of 385 objects to be included in the manifest includes all certificates 386 issued by this CA that are published at the CA's repository 387 publication point, the most recent CRL issued by the CA, and all 388 objects verified by EE certificates that were issued by this CA 389 that are published at this repository publication point. 390 (Sections 6.1-5 describes the checks that an RP MUST perform in 391 support of the manifest content noted here.) 393 Note that the manifest does not include a self reference (i.e., 394 its own file name and hash), since it would be impossible to 395 compute the hash of the manifest itself prior to it being signed. 397 5. Encapsulate the manifest content using the CMS SignedData content 398 type (as specified Section 4), sign the manifest using the 399 private key corresponding to the subject key contained in the EE 400 certificate, and publish the manifest in the repository system 401 publication point that is described by the manifest. (RPs are 402 required to verify the CMS signature.) 404 6. Because the key pair is to be used only once, the private key 405 associated with this key pair MUST now be destroyed. 407 5.2. Considerations for Manifest Generation 409 A new manifest MUST be issued and published before the nextUpdate 410 time. 412 An authority MUST issue a new manifest in conjunction with the 413 finalization of changes made to objects in the publication point. If 414 any named objects in the publication point are replaced, the 415 authority MUST ensure that the file hash for each replaced object is 416 updated accordingly in the new manifest. Additionally, the authority 417 MUST revoke the certificate associated with each replaced object 418 (other than a CRL), if it is not expired. An authority MAY perform a 419 number of object operations on a publication repository within the 420 scope of a repository change before issuing a single manifest that 421 covers all the operations within the scope of this change. 422 Repository operators MUST implement some form of repository update 423 procedure that mitigates, to the extent possible, the risk that RPs 424 that are performing retrieval operations on the repository are 425 exposed to inconsistent, transient, intermediate states during 426 updates to the repository publication point (directory) and the 427 associated manifest. 429 Since the manifest object URL is included in the SIA of issued 430 certificates, a new manifest MUST NOT invalidate the manifest object 431 URL of previously issued certificates. This implies that the 432 manifest's publication name in the repository, in the form of an 433 object URL, is unchanged across manifest generation cycles. 435 When a CA entity is performing a key rollover, the entity MAY choose 436 to have two CA instances simultaneously publishing into the same 437 repository publication point. In this case, there will be one 438 manifest associated with each active CA instance that is publishing 439 into the common repository publication point (directory). 441 6. Relying Party Processing of Manifests 443 Each RP MUST use the current manifest of a CA to control addition of 444 listed files to the set of signed objects the RP employs for 445 validating basic RPKI objects: certificates, ROAs, and CRLs. Any 446 files not listed on the manifest MUST NOT be used for validation of 447 these objects. However, files not listed on a manifest MAY be 448 employed to validate other signed objects, if the profile of the 449 object type explicitly states that such behavior is allowed (or 450 required). Note that relying on files not listed in a manifest may 451 allow an attacker to effect substitution attacks against such 452 objects. 454 As noted earlier, manifests are designed to allow an RP to detect 455 manipulation of repository data, errors by a CA or repository 456 manager, and/or active attacks on the communication channel between 457 an RP and a repository. Unless all of the files enumerated in a 458 manifest can be obtained by an RP during a fetch operation, the fetch 459 is considered to have failed and the RP MUST retry the fetch later. 461 [RFC6480] suggests (but does not mandate) that the RPKI model employ 462 fetches that are incremental, e.g., an RP transfers files from a 463 publication point only if they are new/changed since the previous, 464 successful, fetch represented in the RP's local cache. This document 465 avoids language that relies on details of the underlying file 466 transfer mechanism employed by an RP and a publication point to 467 effect this operation. Thus the term "fetch" refers to an operation 468 that attempts to acquire the full set of files at a publication 469 point, consistent with the id-ad-rpkiManifest URI extracted from a CA 470 certificate's SIA (see below). 472 If a fetch fails, it is assumed that a subsequent fetch will resolve 473 problems encountered during the fetch. Until such time as a 474 successful fetch is executed, an RP SHOULD use cached data from a 475 previous, successful fetch. This response is intended to prevent an 476 RP from misinterpreting data associated with a publication point, and 477 thus possibly treating invalid routes as valid, or vice versa. 479 The processing described below is designed to cause all RPs with 480 access to the same local cache and RPKI repository data to acquire 481 the same set of validated repository files. It does not ensure that 482 the RPs will achieve the same results with regard to validation of 483 RPKI data, since that depends on how each RP resolves any conflicts 484 that may arise in processing the retrieved files. Moreover, in 485 operation, different RPs will access repositories at different times, 486 and some RPs may experience local cache failures, so there is no 487 guarantee that all RPs will achieve the same results with regard to 488 acquisition or validation of RPKI data. 490 Note also that there is a "chicken and egg" relationship between the 491 manifest and the CRL for a given CA instance. If the EE certificate 492 for the current manifest is revoked, i.e., it appears in the current 493 CRL, then the CA or publication point manager has made a serious 494 error. In this case the fetch has failed; proceed to Section 6.6. 495 Similarly, if the CRL is not listed on a valid, current manifest, 496 acquired during a fetch, the fetch has failed; proceed to 497 Section 6.6, because the CRL is considered missing. 499 6.1. Manifest Processing Overview 501 For a given publication point, an RP MUST perform a series of tests 502 to determine which signed object files at the publication point are 503 acceptable. The tests described below (Section 6.2 to Section 6.5) 504 are to be performed using the manifest identified by the id-ad- 505 rpkiManifest URI extracted from a CA certificate's SIA. All of the 506 files referenced by the manifest MUST be located at the publication 507 point specified by the id-ad-caRepository URI from the (same) CA 508 certificate's SIA. The manifest and the files it references MUST 509 reside at the same publication point. If an RP encounters any files 510 that appear on a manifest but do not reside at the same publication 511 point as the manifest the RP MUST treat the fetch as failed, and a 512 warning MUST be issued (see Section 6.6 below). 514 Note that, during CA key rollover [RFC6489], signed objects for two 515 or more different CA instances will appear at the same publication 516 point. Manifest processing is to be performed separately for each CA 517 instance, guided by the SIA id-ad-rpkiManifest URI in each CA 518 certificate. 520 6.2. Acquiring a Manifest for a CA 522 The RP MUST fetch the manifest identified by the SIA id-ad- 523 rpkiManifest URI in the CA certificate. If an RP cannot retrieve a 524 manifest using this URI, or if the manifest is not valid 525 (Section 4.4), an RP MUST treat this as a failed fetch and proceed to 526 Section 6.6; otherwise proceed to Section 6.3. 528 6.3. Detecting Stale and or Prematurely-issued Manifests 530 The RP MUST check that the current time (translated to UTC) is 531 between thisUpdate and nextUpdate. If the current time lies within 532 this interval, proceed to Section 6.4. If the current time is 533 earlier than thisUpdate, the CA may have made an error or the RP's 534 local notion of time may be in error; the RP MUST treat this as a 535 failed fetch and proceed to Section 6.6. If the current time is 536 later than nextUpdate, then the manifest is stale; this is a failed 537 fetch and RP MUST proceed to Section 6.6; otherwise proceed to 538 Section 6.4. 540 6.4. Acquiring Files Referenced by a Manifest 542 The RP MUST acquire all of the files enumerated in the manifest 543 (fileList) from the publication point. If there are files listed in 544 the manifest that cannot be retrieved from the publication point, the 545 fetch has failed and the RP MUST proceed to Section 6.6; otherwise, 546 proceed to Section 6.5. 548 6.5. Matching File Names and Hashes 550 The RP MUST verify that the hash value of each file listed in the 551 manifest matches the value obtained by hashing the file acquired from 552 the publication point. If the computed hash value of a file listed 553 on the manifest does not match the hash value contained in the 554 manifest, then the fetch has failed and the RP MUST proceed to 555 Section 6.6. 557 6.6. Failed Fetches 559 If a fetch fails for any of the reasons cited in 6.2-6.5, the RP MUST 560 issue a warning indicating the reason(s) for termination of 561 processing with regard to this CA instance. It is RECOMMENDED that a 562 human operator be notified of 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 568 try to acquire and validate subordinate signed objects, e.g., 569 subordinate CA certificates, until the next interval when the RP is 570 scheduled to 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, i.e., a CRL issued by the CA 579 [RFC6481],corresponding to the scope of this manifest. 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 Tim 627 Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto 628 Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, Lars 629 Eggert, Robert Wilton, and Benjamin Kaduk for their helpful review of 630 this document. 632 11. References 634 11.1. Normative References 636 [IANA-NAMING] 637 "RPKI Repository Name Schemes", 638 . 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 647 Housley, R., and W. Polk, "Internet X.509 Public Key 648 Infrastructure Certificate and Certificate Revocation List 649 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 650 . 652 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 653 Resource Certificate Repository Structure", RFC 6481, 654 DOI 10.17487/RFC6481, February 2012, 655 . 657 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 658 Origin Authorizations (ROAs)", RFC 6482, 659 DOI 10.17487/RFC6482, February 2012, 660 . 662 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 663 Algorithms and Key Sizes for Use in the Resource Public 664 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 665 August 2016, . 667 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 668 X.509 PKIX Resource Certificates", RFC 6487, 669 DOI 10.17487/RFC6487, February 2012, 670 . 672 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 673 Template for the Resource Public Key Infrastructure 674 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 675 . 677 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 678 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 679 May 2017, . 681 [X.690] "X.690", 682 . 684 11.2. Informative References 686 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 687 RFC 5652, DOI 10.17487/RFC5652, September 2009, 688 . 690 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 691 Addresses and AS Identifiers", RFC 3779, 692 DOI 10.17487/RFC3779, June 2004, 693 . 695 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 696 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 697 February 2012, . 699 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 700 "Manifests for the Resource Public Key Infrastructure 701 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 702 . 704 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 705 Authority (CA) Key Rollover in the Resource Public Key 706 Infrastructure (RPKI)", BCP 174, RFC 6489, 707 DOI 10.17487/RFC6489, February 2012, 708 . 710 Appendix A. ASN.1 Module 712 RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) 713 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 715 DEFINITIONS EXPLICIT TAGS ::= 716 BEGIN 718 -- EXPORTS ALL -- 720 IMPORTS 722 CONTENT-TYPE 723 FROM CryptographicMessageSyntax-2010 -- in [RFC6268] 724 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 725 pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; 727 -- Manifest Content Type 729 ct-rpkiManifest CONTENT-TYPE ::= 730 { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest } 732 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 733 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 735 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 737 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 739 Manifest ::= SEQUENCE { 740 version [0] INTEGER DEFAULT 0, 741 manifestNumber INTEGER (0..MAX), 742 thisUpdate GeneralizedTime, 743 nextUpdate GeneralizedTime, 744 fileHashAlg OBJECT IDENTIFIER, 745 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 746 } 748 FileAndHash ::= SEQUENCE { 749 file IA5String, 750 hash BIT STRING 751 } 753 END 755 Appendix B. Changes since RFC 6486 757 In 2019, it came to light that multiple Relying Party implementations 758 were in a vulnerable position, possibly due to perceived ambiguity in 759 the original [RFC6486] specification. This document attempts to 760 clarify the innovative concept and application of RPKI Manifests in 761 light of real-world deployment experience in the global Internet 762 routing system, to avoid future problematic cases. 764 The following list summarizes the changes between RFC 6486 and this 765 document: 767 * Forbid "sequential-use" EE certificates, instead mandate "one- 768 time-use" EE certificates. 770 * Clarify that Manifest EE certificates are to be issued with a 771 validity period which coincides with the interval specified in the 772 Manifest eContent, which coincides with the CRL's thisUpdate and 773 nextUpdate. 775 * Clarify the manifestNumber is monotonically incremented in steps 776 of 1. 778 * Recommend CA issuers to coincidence the applicable CRL's 779 nextUpdate with the Manifest's nextUpdate. 781 * The set of valid characters in FileAndHash filenames was 782 constrained. 784 * Clarifications that an RP unable to obtain the full set of files 785 listed on a Manifest is considered a failure state, in which case 786 cached data from a previous attempt should be used (if available). 788 * Clarifications on the requirement for a current CRL to be present, 789 listed, and verified. 791 * Removed the notion of 'local policy'. 793 Authors' Addresses 795 Rob Austein 796 Arrcus, Inc. 797 Email: sra@hactrn.net 799 Geoff Huston 800 APNIC 801 6 Cordelia St 802 South Brisbane QLD 4101 803 Australia 804 Email: gih@apnic.net 806 Stephen Kent 807 Independent 808 Email: kent@alum.mit.edu 809 Matt Lepinski 810 New College Florida 811 5800 Bay Shore Rd. 812 Sarasota, FL 34243 813 USA 814 Email: mlepinski@ncf.edu