idnits 2.17.1 draft-ietf-sidrops-6486bis-09.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 == 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. -- The document date (21 December 2021) is 857 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 749 == Missing Reference: 'RFC6268' is mentioned on line 732, but not defined == Unused Reference: 'RFC6482' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC6493' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC8209' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC8488' is defined on line 689, 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) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Downref: Normative reference to an Informational RFC: RFC 8488 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: 24 June 2022 S. Kent 7 Independent 8 M. Lepinski 9 New College Florida 10 21 December 2021 12 Manifests for the Resource Public Key Infrastructure (RPKI) 13 draft-ietf-sidrops-6486bis-09 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. This document obsoletes RFC 31 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 24 June 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . 16 95 Appendix B. Changes to RFC 6486 . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 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) [RFC3370] 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 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 value 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, it is RECOMMENDED that the EE certificate have a validity 231 period that coincides with the interval from thisUpdate to nextUpdate 232 in the 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. 258 thisUpdate: 259 This field contains the time when the manifest was created. This 260 field has the same format constraints as specified in [RFC5280] 261 for the CRL field of the same name. The issuer MUST ensure that 262 the value of this field is more recent any previously-generated 263 Manifest. Each RP MUST verify that this field value is greater 264 (more recent) than the most recent Manifest it has validated. 266 nextUpdate: 267 This field contains the time at which the next scheduled manifest 268 will be issued. The value of nextUpdate MUST be later than the 269 value of thisUpdate. The specification of the GeneralizedTime 270 value is the same as required for the thisUpdate field. 272 If the authority alters any of the items that it has published in 273 the repository publication point, then the authority MUST issue a 274 new manifest. Even if no changes are made to objects at a 275 publication point, a new manifest MUST be issued before the 276 nextUpdate time. Each manifest encompasses a CRL, and the 277 nextUpdate field of the manifest SHOULD match that of the CRL's 278 nextUpdate field, as the manifest will be re-issued when a new CRL 279 is published. When a new manifest is issued before the time 280 specified in nextUpdate of the current manifest, the CA MUST also 281 issue a new CRL that revokes the EE certificate corresponding to 282 the old manifest. 284 fileHashAlg: 285 This field contains the OID of the hash algorithm used to hash the 286 files that the authority has placed into the repository. The hash 287 algorithm used MUST conform to the RPKI Algorithms and Key Size 288 Profile specification [RFC6485]. 290 fileList: 291 This field is a sequence of FileAndHash objects. There is one 292 FileAndHash entry for each currently valid signed object that has 293 been published by the authority (at this publication point). Each 294 FileAndHash is an ordered pair consisting of the name of the file 295 in the repository publication point (directory) that contains the 296 object in question and a hash of the file's contents. 298 4.2.2. Names in FileAndHash objects 300 Names that appear in the fileList MUST consist of one or more 301 characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ 302 (UNDERSCORE), followed by a single . (DOT), followed by a three- 303 letter extension. The extension MUST be one of those enumerated in 304 the "RPKI Repository Naming Scheme" registry maintained by IANA 305 [IANA-NAMING]. 307 As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. 309 The example above contains a mix of uppercase and lowercase 310 characters in the filename. CAs and RPs MUST be able to perform 311 filesystem operations in a case-sensitive, case-preserving manner. 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 Note: Although it is RECOMMENDED that the thisUpdate and nextUpdate 332 fields in the manifest match the corresponding fields in the CRL 333 associated with the manifest, RPs SHOULD NOT reject a manifest if 334 these fields do not match. 336 If the above procedure indicates that the manifest is invalid, then 337 the manifest MUST be discarded and treated as though no manifest were 338 present. 340 5. Manifest Generation 342 5.1. Manifest Generation Procedure 344 For a CA publication point in the RPKI repository system, a CA MUST 345 perform the following steps to generate a manifest: 347 1. Generate a new key pair for use in a "one-time-use" EE 348 certificate. 350 2. Issue an EE certificate for this key pair. The CA MUST revoke 351 the EE certificate used for the manifest being replaced. 353 This EE certificate MUST have an SIA extension access description 354 field with an accessMethod OID value of id-ad-signedobject, where 355 the associated accessLocation references the publication point of 356 the manifest as an object URL.(RPs are required to verify both of 357 these syntactic constraints.) 359 This EE certificate MUST describe its Internet Number Resources 360 (INRs) using the "inherit" attribute, rather than explicit 361 description of a resource set (see [RFC3779]).(RPs are required 362 to verify this.) 364 It is RECOMMENDED that the validity interval of the EE 365 certificate exactly match the thisUpdate and nextUpdate times of 366 the manifest. 368 Note: An RP MUST verify all mandated syntactic constraints, i.e., 369 constraints imposed on a CA via a "MUST". 371 3. The EE certificate MUST NOT be published in the authority's 372 repository publication point. 374 4. Construct the manifest content. 376 The manifest content is described in Section 4.2.1. The 377 manifest's fileList includes the file name and hash pair for each 378 object issued by this CA that has been published at this 379 repository publication point (directory). The collection of 380 objects to be included in the manifest includes all certificates 381 issued by this CA that are published at the CA's repository 382 publication point, the most recent CRL issued by the CA, and all 383 objects verified by EE certificates that were issued by this CA 384 that are published at this repository publication point. 385 (Sections 6.1-5 describes the checks that an RP MUST perform in 386 support of the manifest content noted here.) 388 Note that the manifest does not include a self reference (i.e., 389 its own file name and hash), since it would be impossible to 390 compute the hash of the manifest itself prior to it being signed. 392 5. Encapsulate the manifest content using the CMS SignedData content 393 type (as specified Section 4), sign the manifest using the 394 private key corresponding to the subject key contained in the EE 395 certificate, and publish the manifest in the repository system 396 publication point that is described by the manifest. (RPs are 397 required to verify the CMS signature.) 399 6. Because the key pair is to be used only once, the private key 400 associated with this key pair MUST now be destroyed. 402 5.2. Considerations for Manifest Generation 404 A new manifest MUST be issued and published before the nextUpdate 405 time. 407 An authority MUST issue a new manifest in conjunction with the 408 finalization of changes made to objects in the publication point. If 409 any named objects in the publication point are replaced, the 410 authority MUST ensure that the file hash for each replaced object is 411 updated accordingly in the new manifest. Additionally, the authority 412 MUST revoke the certificate associated with each replaced object 413 (other than a CRL), if it is not expired. An authority MAY perform a 414 number of object operations on a publication repository within the 415 scope of a repository change before issuing a single manifest that 416 covers all the operations within the scope of this change. 417 Repository operators MUST implement some form of repository update 418 procedure that mitigates, to the extent possible, the risk that RPs 419 that are performing retrieval operations on the repository are 420 exposed to inconsistent, transient, intermediate states during 421 updates to the repository publication point (directory) and the 422 associated manifest. 424 Since the manifest object URL is included in the SIA of issued 425 certificates, a new manifest MUST NOT invalidate the manifest object 426 URL of previously issued certificates. This implies that the 427 manifest's publication name in the repository, in the form of an 428 object URL, is unchanged across manifest generation cycles. 430 When a CA entity is performing a key rollover, the entity MAY choose 431 to have two CA instances simultaneously publishing into the same 432 repository publication point. In this case, there will be one 433 manifest associated with each active CA instance that is publishing 434 into the common repository publication point (directory). 436 6. Relying Party Processing of Manifests 438 Each RP MUST use the current manifest of a CA to control addition of 439 listed files to the set of signed objects the RP employs for 440 validating basic RPKI objects: certificates, ROAs, and CRLs. Any 441 files not listed on the manifest MUST NOT be used for validation of 442 these objects. However, files not listed on a manifest MAY be 443 employed to validate other signed objects, if the profile of the 444 object type explicitly states that such behavior is allowed (or 445 required). Note that relying on files not listed in a manifest may 446 allow an attacker to effect substitution attacks against such 447 objects. 449 As noted earlier, manifests are designed to allow an RP to detect 450 manipulation of repository data, errors by a CA or repository 451 manager, and/or active attacks on the communication channel between 452 an RP and a repository. Unless all of the files enumerated in a 453 manifest can be obtained by an RP during a fetch operation, the fetch 454 is considered to have failed and the RP MUST retry the fetch later. 456 [RFC6480] suggests (but does not mandate) that the RPKI model employ 457 fetches that are incremental, e.g., an RP transfers files from a 458 publication point only if they are new/changed since the previous, 459 successful, fetch represented in the RP's local cache. This document 460 avoids language that relies on details of the underlying file 461 transfer mechanism employed by an RP and a publication point to 462 effect this operation. Thus the term "fetch" refers to an operation 463 that attempts to acquire the full set of files at a publication 464 point, consistent with the id-ad-rpkiManifest URI extracted from a CA 465 certificate's SIA (see below). 467 If a fetch fails, it is assumed that a subsequent fetch will resolve 468 problems encountered during the fetch. Until such time as a 469 successful fetch is executed, an RP SHOULD use cached data from a 470 previous, successful fetch. This response is intended to prevent an 471 RP from misinterpreting data associated with a publication point, and 472 thus possibly treating invalid routes as valid, or vice versa. 474 The processing described below is designed to cause all RPs with 475 access to the same local cache and RPKI repository data to acquire 476 the same set of validated repository files. It does not ensure that 477 the RPs will achieve the same results with regard to validation of 478 RPKI data, since that depends on how each RP resolves any conflicts 479 that may arise in processing the retrieved files. Moreover, in 480 operation, different RPs will access repositories at different times, 481 and some RPs may experience local cache failures, so there is no 482 guarantee that all RPs will achieve the same results with regard to 483 acquisition or validation of RPKI data. 485 Note also that there is a "chicken and egg" relationship between the 486 manifest and the CRL for a given CA instance. If the EE certificate 487 for the current manifest is revoked, i.e., it appears in the current 488 CRL, then the CA or publication point manager has made a serious 489 error. In this case the fetch has failed; proceed to Section 6.6. 490 Similarly, if the CRL is not listed on a valid, current manifest, 491 acquired during a fetch, the fetch has failed; proceed to 492 Section 6.6, because the CRL is considered missing. 494 6.1. Manifest Processing Overview 496 For a given publication point, an RP MUST perform a series of tests 497 to determine which signed object files at the publication point are 498 acceptable. The tests described below (Section 6.2 to Section 6.5) 499 are to be performed using the manifest identified by the id-ad- 500 rpkiManifest URI extracted from a CA certificate's SIA. All of the 501 files referenced by the manifest MUST be located at the publication 502 point specified by the id-ad-caRepository URI from the (same) CA 503 certificate's SIA. The manifest and the files it references MUST 504 reside at the same publication point. If an RP encounters any files 505 that appear on a manifest but do not reside at the same publication 506 point as the manifest the RP MUST treat the fetch as failed, and a 507 warning MUST be issued (see Section 6.6 below). 509 Note that, during CA key rollover [RFC6489], signed objects for two 510 or more different CA instances will appear at the same publication 511 point. Manifest processing is to be performed separately for each CA 512 instance, guided by the SIA id-ad-rpkiManifest URI in each CA 513 certificate. 515 6.2. Acquiring a Manifest for a CA 517 The RP MUST fetch the manifest identified by the SIA id-ad- 518 rpkiManifest URI in the CA certificate. If an RP cannot retrieve a 519 manifest using this URI, or if the manifest is not valid 520 (Section 4.4), an RP MUST treat this as a failed fetch and proceed to 521 Section 6.6; otherwise proceed to Section 6.3. 523 6.3. Detecting Stale and or Prematurely-issued Manifests 525 The RP MUST check that the current time (translated to UTC) is 526 between thisUpdate and nextUpdate. If the current time lies within 527 this interval, proceed to Section 6.4. If the current time is 528 earlier than thisUpdate, the CA may have made an error or the RP's 529 local notion of time may be in error; the RP MUST treat this as a 530 failed fetch and proceed to Section 6.6. If the current time is 531 later than nextUpdate, then the manifest is stale; this is a failed 532 fetch and RP MUST proceed to Section 6.6; otherwise proceed to 533 Section 6.4. 535 6.4. Acquiring Files Referenced by a Manifest 537 The RP MUST acquire all of the files enumerated in the manifest 538 (fileList) from the publication point. If there are files listed in 539 the manifest that cannot be retrieved from the publication point, the 540 fetch has failed and the RP MUST proceed to Section 6.6; otherwise, 541 proceed to Section 6.5. 543 6.5. Matching File Names and Hashes 545 The RP MUST verify that the hash value of each file listed in the 546 manifest matches the value obtained by hashing the file acquired from 547 the publication point. If the computed hash value of a file listed 548 on the manifest does not match the hash value contained in the 549 manifest, then the fetch has failed and the RP MUST proceed to 550 Section 6.6; otherwise proceed to Section 6.6. 552 6.6. Failed Fetches 554 If a fetch fails for any of the reasons cited in 6.2-6.5, the RP MUST 555 issue a warning indicating the reason(s)for termination of processing 556 with regard to this CA instance. It is RECOMMENDED that a human 557 operator be notified of this warning. 559 Termination of processing means that the RP SHOULD continue to use 560 cached versions of the objects associated with this CA instance, 561 until such time as they become stale or they can be replaced by 562 objects from a successful fetch. This implies that the RP MUST not 563 try to acquire and validate subordinate signed objects, e.g., 564 subordinate CA certificates, until the next interval when the RP is 565 scheduled to fetch and process data for this CA instance. 567 7. Publication Repositories 569 The RPKI publication system model requires that every publication 570 point be associated with one or more CAs, and be non-empty. Upon 571 creation of the publication point associated with a CA, the CA MUST 572 create and publish a manifest as well as a CRL. A CA's manifest will 573 always contain at least one entry, i.e., a CRL issued by the CA 574 [RFC6481],corresponding to the scope of this manifest. 576 Every published signed object in the RPKI [RFC6488] is published in 577 the repository publication point of the CA that issued the EE 578 certificate, and is listed in the manifest associated with that CA 579 certificate. 581 8. Security Considerations 583 Manifests provide an additional level of protection for RPKI RPs. 584 Manifests can assist an RP to determine if a repository object has 585 been deleted, occluded, or otherwise removed from view, or if a 586 publication of a newer version of an object has been suppressed (and 587 an older version of the object has been substituted). 589 Manifests cannot repair the effects of such forms of corruption of 590 repository retrieval operations. However, a manifest enables an RP 591 to determine if a locally maintained copy of a repository is a 592 complete and up-to-date copy, even when the repository retrieval 593 operation is conducted over an insecure channel. In cases where the 594 manifest and the retrieved repository contents differ, the manifest 595 can assist in determining which repository objects form the 596 difference set in terms of missing, extraneous, or superseded 597 objects. 599 The signing structure of a manifest and the use of the nextUpdate 600 value allows an RP to determine if the manifest itself is the subject 601 of attempted alteration. The requirement for every repository 602 publication point to contain at least one manifest allows an RP to 603 determine if the manifest itself has been occluded from view. Such 604 attacks against the manifest are detectable within the time frame of 605 the regular schedule of manifest updates. Forms of replay attack 606 within finer-grained time frames are not necessarily detectable by 607 the manifest structure. 609 9. IANA Considerations 611 As [RFC6488] created and populated the registries "RPKI Signed 612 Object" and three-letter filename extensions for "RPKI Repository 613 Name Schemes," no new action is requested of the IANA. 615 10. Acknowledgements 617 The authors would like to acknowledge the contributions from George 618 Michelson and Randy Bush in the preparation of the manifest 619 specification. Additionally, the authors would like to thank Mark 620 Reynolds and Christopher Small for assistance in clarifying manifest 621 validation and RP behavior. The authors also wish to thank Tim 622 Bruijnzeels, Job Snijders, Oleg Muravskiy, and Sean Turner for their 623 helpful review of this document. 625 11. References 627 11.1. Normative References 629 [IANA-NAMING] 630 "RPKI Repository Name Schemes", 631 . 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, 636 DOI 10.17487/RFC2119, March 1997, 637 . 639 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 640 Housley, R., and W. Polk, "Internet X.509 Public Key 641 Infrastructure Certificate and Certificate Revocation List 642 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 643 . 645 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 646 Resource Certificate Repository Structure", RFC 6481, 647 DOI 10.17487/RFC6481, February 2012, 648 . 650 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 651 Origin Authorizations (ROAs)", RFC 6482, 652 DOI 10.17487/RFC6482, February 2012, 653 . 655 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 656 Use in the Resource Public Key Infrastructure (RPKI)", 657 RFC 6485, DOI 10.17487/RFC6485, February 2012, 658 . 660 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 661 "Manifests for the Resource Public Key Infrastructure 662 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, 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] "X.690", 696 . 698 11.2. Informative References 700 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 701 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 702 . 704 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 705 Addresses and AS Identifiers", RFC 3779, 706 DOI 10.17487/RFC3779, June 2004, 707 . 709 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 710 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 711 February 2012, . 713 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 714 Authority (CA) Key Rollover in the Resource Public Key 715 Infrastructure (RPKI)", BCP 174, RFC 6489, 716 DOI 10.17487/RFC6489, February 2012, 717 . 719 Appendix A. ASN.1 Module 721 RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) 722 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 724 DEFINITIONS EXPLICIT TAGS ::= 725 BEGIN 727 -- EXPORTS ALL -- 729 IMPORTS 731 CONTENT-TYPE 732 FROM CryptographicMessageSyntax-2010 -- in [RFC6268] 733 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 734 pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; 736 -- Manifest Content Type 738 ct-rpkiManifest CONTENT-TYPE ::= 739 { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest } 741 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 742 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 744 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 746 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 748 Manifest ::= SEQUENCE { 749 version [0] INTEGER DEFAULT 0, 750 manifestNumber INTEGER (0..MAX), 751 thisUpdate GeneralizedTime, 752 nextUpdate GeneralizedTime, 753 fileHashAlg OBJECT IDENTIFIER, 754 fileList SEQUENCE SIZE (0..MAX) OF FileAndHash 755 } 757 FileAndHash ::= SEQUENCE { 758 file IA5String, 759 hash BIT STRING 760 } 762 END 764 Appendix B. Changes to RFC 6486 766 In 2019 it came to light that multiple Relying Party implementations 767 were in a vulnerable position, possibly due to perceived ambiguity in 768 the original [RFC6486] specification. This document attempts to 769 clarify the innovative concept and application of RPKI Manifests in 770 light of real-world deployment experience in the global Internet 771 routing system, to avoid future problematic cases. 773 The following list summarizes the changes between RFC 6486 and this 774 document: 776 * Forbid "sequential-use" EE certificates, instead mandate "one- 777 time-use" EE certificates. 779 * Emphasize a recommendation for EE certificates to have a validity 780 period that coincides with the interval specified in the Manifest 781 eContent. 783 * Clarify the manifestNumber is monotonically incremented in steps 784 of 1. 786 * Recommend CA issuers to coincidence the applicable CRL's 787 nextUpdate with the Manifest's nextUpdate. 789 * The set of valid characters in FileAndHash filenames was 790 constrained. 792 * Clarifications that an RP unable to obtain the full set of files 793 listed on a Manifest is considered a failure state, in which case 794 cached data from a previous attempt should be used (if available). 796 * Clarifications on the requirement for a current CRL to be present, 797 listed, and verified. 799 * Removed the notion of 'local policy'. 801 Authors' Addresses 803 Rob Austein 804 Arrcus, Inc. 806 Email: sra@hactrn.net 808 Geoff Huston 809 APNIC 810 6 Cordelia St 811 South Brisbane QLD 4101 812 Australia 814 Email: gih@apnic.net 816 Stephen Kent 817 Independent 818 Email: kent@alum.mit.edu 820 Matt Lepinski 821 New College Florida 822 5800 Bay Shore Rd. 823 Sarasota, FL 34243 824 USA 826 Email: mlepinski@ncf.edu