idnits 2.17.00 (12 Aug 2021) /tmp/idnits57347/draft-ietf-sidrops-rpki-tree-validation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (September 16, 2018) is 1336 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR Operations O. Muravskiy 3 Internet-Draft RIPE NCC 4 Intended status: Informational T. Bruijnzeels 5 Expires: March 20, 2019 NLNetLabs 6 September 16, 2018 8 RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator 9 draft-ietf-sidrops-rpki-tree-validation-03 11 Abstract 13 This document describes the approach to validate the content of the 14 RPKI certificate tree, as it is implemented in the RIPE NCC RPKI 15 Validator. This approach is independent of a particular object 16 retrieval mechanism. This allows it to be used with repositories 17 available over the rsync protocol, the RPKI Repository Delta 18 Protocol, and repositories that use a mix of both. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 20, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Scope of this document . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. General Considerations . . . . . . . . . . . . . . . . . . . 4 57 3.1. Hash comparisons . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Discovery of RPKI objects issued by a CA . . . . . . . . 4 59 3.3. Manifest entries versus repository content . . . . . . . 4 60 4. Top-down Validation of a Single Trust Anchor Certificate Tree 5 61 4.1. Fetching the Trust Anchor Certificate Using the Trust 62 Anchor Locator . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. CA Certificate Validation . . . . . . . . . . . . . . . . 6 64 4.2.1. Finding the most recent valid manifest and CRL . . . 7 65 4.2.2. Manifest entries validation . . . . . . . . . . . . . 8 66 4.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 9 67 5. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 9 68 5.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 9 69 5.1.1. Fetch repository objects . . . . . . . . . . . . . . 10 70 5.1.2. Fetch single repository object . . . . . . . . . . . 10 71 6. Local Object Store . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Store Operations . . . . . . . . . . . . . . . . . . . . 11 73 6.1.1. Store Repository Object . . . . . . . . . . . . . . . 11 74 6.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 11 75 6.1.3. Get certificate objects by URI . . . . . . . . . . . 11 76 6.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 11 77 6.1.5. Delete objects for a URI . . . . . . . . . . . . . . 12 78 6.1.6. Delete outdated objects . . . . . . . . . . . . . . . 12 79 6.1.7. Update object's validation time . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 9.1. Hash collisions . . . . . . . . . . . . . . . . . . . . . 12 84 9.2. Algorithm agility . . . . . . . . . . . . . . . . . . . . 12 85 9.3. Mismatch between the expected and the actual location of 86 an object in the repository . . . . . . . . . . . . . . . 13 87 9.4. Manifest content versus publication point content . . . . 13 88 9.5. Possible denial of service . . . . . . . . . . . . . . . 14 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 91 10.2. Informative References . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Scope of this document 96 This document describes how the RIPE NCC RPKI Validator version 2.23 97 has been implemented. Source code to this software can be found at 98 [github]. The purpose of this document is to provide transparency to 99 users of (and contributors to) this software tool, as well as serve 100 to be subjected to scrutiny by the SIDR Operations Working Group. It 101 is not intended as a document that describes a standard or best 102 practices on how validation should be done in general. 104 2. Introduction 106 In order to use information published in RPKI repositories, Relying 107 Parties (RP) need to retrieve and validate the content of 108 certificates, certificate revocation lists (CRLs), and other RPKI 109 signed objects. To validate a particular object, one must ensure 110 that all certificates in the certificate chain up to the Trust Anchor 111 (TA) are valid. Therefore the validation of a certificate tree is 112 performed top-down, starting from the TA certificate and descending 113 down the certificate chain, validating every encountered certificate 114 and its products. The result of this process is a list of all 115 encountered RPKI objects with a validity status attached to each of 116 them. These results may later be used by a Relying Party in taking 117 routing decisions, etc. 119 Traditionally RPKI data is made available to RPs through the 120 repositories [RFC6481] accessible over [rsync] protocol. Relying 121 parties are advised to keep a local copy of repository data, and 122 perform regular updates of this copy from the repository (Section 5 123 of [RFC6481]). The RPKI Repository Delta Protocol [RFC8182] 124 introduces another method to fetch repository data and keep the local 125 copy up to date with the repository. 127 This document describes how the RIPE NCC RPKI Validator discovers 128 RPKI objects to download, builds certificate paths, and validates 129 RPKI objects, independently from what repository access protocol is 130 used. To achieve this, it puts downloaded RPKI objects in an object 131 store, where each RPKI object can be found by its URI, the hash of 132 its content, value of its Authority Key Identifier (AKI) extension, 133 or a combination of these. It also keeps track of the download and 134 the validation time for every object, to decide which locally stored 135 objects are not used in the RPKI tree validation and could be 136 removed. 138 3. General Considerations 140 3.1. Hash comparisons 142 This algorithm relies on the collision resistance properties of the 143 file hash algorithm (defined in [RFC7935]) to compute the hash of 144 repository objects. It assumes that any two objects for which the 145 hash value is the same, are identical. 147 The hash comparison is used when matching objects in the repository 148 with entries on the manifest (Section 4.2.2), and when looking up 149 objects in the object store (Section 6). 151 3.2. Discovery of RPKI objects issued by a CA 153 There are several possible ways of discovering potential products of 154 a CA certificate: one could use all objects located in a repository 155 directory designated as a publication point for a CA, or only objects 156 mentioned on the manifest located at that publication point (see 157 Section 6 of[RFC6486]), or use all known repository objects whose AKI 158 extension matches the Subject Key Identifier (SKI) extension 159 (Section 4.2.1 of[RFC5280]) of a CA certificate. 161 For publication points whose content is consistent with the manifest 162 and issuing certificate all of these approaches should produce the 163 same result. For inconsistent publication points the results might 164 be different. Section 6 of [RFC6486] leaves the decision on how to 165 deal with inconsistencies to a local policy. 167 The implementation described here does not rely on content of 168 repository directories, but uses the Authority Key Identifier (AKI) 169 extension of a manifest and a certificate revocation list (CRL) to 170 find in an object store (Section 6) a manifest and a CRL issued by a 171 particular Certification Authority (CA) (see Section 4.2.1). It 172 further uses the hashes of manifest's fileList entries (Section 4.2.1 173 of [RFC6486]) to find other objects issued by the CA, as described in 174 Section 4.2.2. 176 3.3. Manifest entries versus repository content 178 Since the current set of RPKI standards requires use of the manifest 179 [RFC6486] to describe the content of a publication point, this 180 implementation requires strict consistency between the publication 181 point content and manifest content. (This is a more stringent 182 requirement than established in [RFC6486].) Therefore it will not 183 process objects that are found in the publication point but do not 184 match any of the entries of that publication point's manifest (see 185 Section 4.2.2). It will also issue warnings for all found 186 mismatches, so that the responsible operators could be made aware of 187 inconsistencies and fix them. 189 4. Top-down Validation of a Single Trust Anchor Certificate Tree 191 1. The validation of a Trust Anchor (TA) certificate tree starts 192 from its TA certificate. To retrieve the TA certificate, a Trust 193 Anchor Locator (TAL) object is used, as described in Section 4.1. 195 2. If the TA certificate is retrieved, it is validated according to 196 Section 7 of [RFC6487] and Section 2.2 of [RFC7730]. Otherwise 197 the validation of certificate tree is aborted and an error is 198 issued. 200 3. If the TA certificate is valid, then all its subordinate objects 201 are validated as described in Section 4.2. Otherwise the 202 validation of certificate tree is aborted and an error is issued. 204 4. For each repository object that was validated during this 205 validation run, its validation timestamp is updated in the object 206 store (see Section 6.1.7). 208 5. Outdated objects are removed from the store as described in 209 Section 4.3. This completes the validation of the TA certificate 210 tree. 212 4.1. Fetching the Trust Anchor Certificate Using the Trust Anchor 213 Locator 215 The following steps are performed in order to fetch a Trust Anchor 216 Certificate: 218 1. (Optional) If the Trust Anchor Locator contains a "prefetch.uris" 219 field, pass the URIs contained in that field to the fetcher (see 220 Section 5.1.1). (This field is a non-standard addition to the 221 TAL format. It helps fetching non-hierarchical rsync 222 repositories more efficiently.) 224 2. Extract the first TA certificate URI from the TAL's URI section 225 (see Section 2.1 of [RFC7730]) and pass it to the object fetcher 226 (Section 5.1.2). If the fetcher returns an error, repeat this 227 step for every URI in the URI section, until no error is 228 encountered, or no more URIs left. 230 3. Retrieve from the object store (see Section 6.1.3) all 231 certificate objects, for which the URI matches the URI extracted 232 from the TAL in the previous step, and the public key matches the 233 subjectPublicKeyInfo extension of the TAL (see Section 2.1 of 234 [RFC7730]). 236 4. If no, or more than one such objects are found, issue an error 237 and abort certificate tree validation process with an error. 238 Otherwise, use the single found object as the Trust Anchor 239 certificate. 241 4.2. CA Certificate Validation 243 The following steps describe the validation of a single CA Resource 244 certificate: 246 1. If both the caRepository (Section 4.8.8.1 of [RFC6487]), and the 247 id-ad-rpkiNotify (Section 3.2 of [RFC8182]) SubjectInfoAccess 248 (SIA) pointers are present in the CA certificate, use a local 249 policy to determine which pointer to use. Extract the URI from 250 the selected pointer and pass it to the object fetcher (that will 251 then fetch all objects available from that repository, see 252 Section 5.1.1). 254 2. For the CA certificate, find the current manifest and certificate 255 revocation list (CRL), using the procedure described in 256 Section 4.2.1. If no such manifest and CRL could be found, stop 257 validation of this certificate, consider it invalid, and issue an 258 error. 260 3. Compare the URI found in the id-ad-rpkiManifest field 261 (Section 4.8.8.1 of [RFC6487]) of the SIA extension of the 262 certificate with the URI of the manifest found in the previous 263 step. If they are different, issue a warning, but continue 264 validation process using the manifest found in the previous step. 265 (This warning indicates that there is a mismatch between the 266 expected and the actual location of an object in a repository. 267 See Section 9 for the explanation of this mismatch and the 268 decision taken.) 270 4. Perform manifest entries discovery and validation as described in 271 Section 4.2.2. 273 5. Validate all resource certificate objects found on the manifest, 274 using the CRL object found on the manifest: 276 * if the strict validation option is enabled by the operator, 277 the validation is performed according to Section 7 of 278 [RFC6487], 280 * otherwise, the validation is performed according to Section 7 281 of [RFC6487], with the exception of the resource certification 282 path validation, that is performed according to 283 Section 4.2.4.4 of [RFC8360]. 285 (Note that this implementation uses the operator configuration to 286 decide which algorithm to use for path validation. It applies 287 the selected algorithm to all resource certificates, rather than 288 applying appropriate algorithm per resource certificate, based on 289 the object identifier (OID) for the Certificate Policy found in 290 that certificate, as specified in [RFC8360].) 292 6. Validate all Route Origin Authorization (ROA) objects found on 293 the manifest, using the CRL object found on the manifest, 294 according to Section 4 of [RFC6482]. 296 7. Validate all Ghostbusters Record objects found on the manifest, 297 using the CRL object found on the manifest, according to 298 Section 7 of [RFC6493]. 300 8. For every valid CA certificate object found on the manifest, 301 apply the procedure described in this section (Section 4.2), 302 recursively, provided that this CA certificate (identified by its 303 SKI) has not yet been validated during current tree validation 304 run. 306 4.2.1. Finding the most recent valid manifest and CRL 308 1. Fetch from the store (see Section 6.1.4) all objects of type 309 manifest, whose certificate's AKI extension matches the SKI of 310 the current CA certificate. If no such objects are found, stop 311 processing the current CA certificate and issue an error. 313 2. Find among found objects the manifest object with the highest 314 manifestNumber field (Section 4.2.1 of [RFC6486]), for which all 315 following conditions are met: 317 * There is only one entry in the manifest for which the store 318 contains exactly one object of type CRL, the hash of which 319 matches the hash of the entry. 321 * The manifest's certificate AKI equals the above CRL's AKI. 323 * The above CRL is a valid object according to Section 6.3 of 324 [RFC5280]. 326 * The manifest is a valid object according to Section 4.4 of 327 [RFC6486], and its EE certificates is not in the CRL found 328 above. 330 3. If there is an object that matches above criteria, consider this 331 object to be the valid manifest, and the CRL found at the 332 previous step - the valid CRL for the current CA certificate's 333 publication point. 335 4. Report an error for every other manifest with a number higher 336 than the number of the valid manifest. 338 4.2.2. Manifest entries validation 340 For every entry in the manifest object: 342 1. Construct an entry's URI by appending the entry name to the 343 current CA's publication point URI. 345 2. Get all objects from the store whose hash attribute equals 346 entry's hash (see Section 6.1.2). 348 3. If no such objects are found, issue an error for this manifest 349 entry and progress to the next entry. This case indicates that 350 the repository does not have an object at the location listed in 351 the manifest, or that the object's hash does not match the hash 352 listed in the manifest. 354 4. For every found object, compare its URI with the URI of the 355 manifest entry. 357 * For every object with a non-matching URI issue a warning. 358 This case indicates that the object from the manifest entry is 359 (also) found at a different location in a (possibly different) 360 repository. 362 * If no objects with a matching URI are found, issue a warning. 363 This case indicates that there is no object found in the 364 repository at the location listed in the manifest entry (but 365 there is at least one matching object found at a different 366 location). 368 5. Use all found objects for further validation as per Section 4.2. 370 Please note that the above steps will not reject objects whose hash 371 matches the hash listed in the manifest, but the URI does not. See 372 Section 9.3 for additional information. 374 4.3. Object Store Cleanup 376 At the end of every TA tree validation some objects are removed from 377 the store using the following rules: 379 1. Given all objects that were encountered during the current 380 validation run, remove from the store (Section 6.1.6) all objects 381 whose URI attribute matches the URI of one of the encountered 382 objects, but the content's hash is different. This removes from 383 the store objects that were replaced in the repository by their 384 newer versions with the same URIs. 386 2. Remove from the store all objects that were last encountered 387 during validation a long time ago (as specified by the local 388 policy). This removes objects that do not appear on any valid 389 manifest anymore (but possibly are still published in a 390 repository). 392 3. Remove from the store all objects that were downloaded recently 393 (as specified by the local policy), but have never been used in 394 the validation process. This removes objects that have never 395 appeared on any valid manifest. 397 Shortening the time interval used in step 2 will free more disk space 398 used by the store, at the expense of downloading removed objects 399 again if they are still published in the repository. 401 Extending the time interval used in step 3 will prevent repeated 402 downloads of repository objects, with the risk that such objects, if 403 created massively by mistake or by an adversary, will fill up local 404 disk space, if they are not cleaned up promptly. 406 5. Remote Objects Fetcher 408 The fetcher is responsible for downloading objects from remote 409 repositories (described in Section 3 of [RFC6481]) using rsync 410 protocol ([rsync]), or RPKI Repository Delta Protocol (RRDP) 411 ([RFC8182]). 413 5.1. Fetcher Operations 415 For every visited URI the fetcher keeps track of the last time a 416 successful fetch occurred. 418 5.1.1. Fetch repository objects 420 This operation receives one parameter - a URI. For an rsync 421 repository this URI points to a directory. For an RRDP repository it 422 points to the repository's notification file. 424 The fetcher performs following steps: 426 1. If data associated with the URI has been downloaded recently (as 427 specified by the local policy), skip following steps. 429 2. Download remote objects using the URI provided (for an rsync 430 repository use recursive mode). If the URI contains schema 431 "https" and download has failed, issue a warning, replace "https" 432 schema in the URI by "http", and try to download objects again, 433 using the resulting URI. 435 3. If remote objects can not be downloaded, issue an error and skip 436 following steps. 438 4. Perform syntactic verification of fetched objects. The type of 439 every object (certificate, manifest, CRL, ROA, or Ghostbusters 440 record), is determined based on the object's filename extension 441 (.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of 442 the object is described in Section 4 of [RFC6487] for resource 443 certificates, step 1 of Section 3 of [RFC6488] for signed 444 objects, and specifically, Section 4 of [RFC6486] for manifests, 445 [RFC5280] for CRLs, Section 3 of [RFC6482] for ROAs, and 446 Section 5 of [RFC6493] for Ghostbusters records. 448 5. Put every downloaded and syntactically correct object in the 449 object store (Section 6.1.1). 451 The time interval used in the step 1 should be chosen based on the 452 acceptable delay in receiving repository updates. 454 5.1.2. Fetch single repository object 456 This operation receives one parameter - a URI that points to an 457 object in a repository. 459 The fetcher performs following operations: 461 1. Download remote object using the URI provided. If the URI 462 contains "https" schema and download failed, issue a warning, 463 replace "https" schema in the URI by "http", and try to download 464 the object using the resulting URI. 466 2. If the remote object can not be downloaded, issue an error and 467 skip following steps. 469 3. Perform syntactic verification of fetched object. The type of 470 object (certificate, manifest, CRL, ROA, or Ghostbusters record), 471 is determined based on the object's filename extension (.cer, 472 .mft, .crl, .roa, and .gbr, respectively). The syntax of the 473 object is described in Section 4 of [RFC6487] for resource 474 certificates, step 1 of Section 3 of [RFC6488] for signed 475 objects, and specifically, Section 4 of [RFC6486] for manifests, 476 [RFC5280] for CRLs, Section 3 of [RFC6482] for ROAs, and 477 Section 5 of [RFC6493] for Ghostbusters records. 479 4. If the downloaded object is not syntactically correct, issue an 480 error and skip further steps. 482 5. Delete all objects from the object store (Section 6.1.5) whose 483 URI matches the URI given. 485 6. Put the downloaded object in the object store (Section 6.1.1). 487 6. Local Object Store 489 6.1. Store Operations 491 6.1.1. Store Repository Object 493 Put given object in the store, along with its type, URI, hash, and 494 AKI, if there is no record with the same hash and URI fields. Note 495 that in the (unlikely) event of hash collision the given object will 496 not replace the object in the store. 498 6.1.2. Get objects by hash 500 Retrieve all objects from the store whose hash attribute matches the 501 given hash. 503 6.1.3. Get certificate objects by URI 505 Retrieve from the store all objects of type certificate, whose URI 506 attribute matches the given URI. 508 6.1.4. Get manifest objects by AKI 510 Retrieve from the store all objects of type manifest, whose AKI 511 attribute matches the given AKI. 513 6.1.5. Delete objects for a URI 515 For a given URI, delete all objects in the store with matching URI 516 attribute. 518 6.1.6. Delete outdated objects 520 For a given URI and a list of hashes, delete all objects in the store 521 with matching URI, whose hash attribute is not in the given list of 522 hashes. 524 6.1.7. Update object's validation time 526 For all objects in the store whose hash attribute matches the given 527 hash, set the last validation time attribute to the given timestamp. 529 7. Acknowledgements 531 This document describes the algorithm as it is implemented by the 532 software development team at the RIPE NCC, which included over time: 533 Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da 534 Cruz Pereira, Yannis Gonianakis, Andrew Snare, Varesh Tapadia, Paolo 535 Milani, Thies Edeling, Hans Westerbeek, Rudi Angela, and Constantijn 536 Visinescu. The authors would also like to acknowledge contributions 537 by Carlos Martinez, Andy Newton, Rob Austein, and Stephen Kent. 539 8. IANA Considerations 541 This document has no actions for IANA. 543 9. Security Considerations 545 9.1. Hash collisions 547 This implementation will not detect possible hash collisions in the 548 hashes of repository objects (calculated using the file hash 549 algorithm specified in [RFC7935]). It considers objects with same 550 hash values as identical. 552 9.2. Algorithm agility 554 This implementation only supports hash algorithms and key sizes 555 specified in [RFC7935]). Algorithm agility described in [RFC6916] is 556 not supported. 558 9.3. Mismatch between the expected and the actual location of an object 559 in the repository 561 According to Section 2 of [RFC6481], all objects issued by a 562 particular CA certificate are expected to be located in one 563 repository publication point, specified in the SIA extension of that 564 CA certificate. The manifest object issued by that CA certificate 565 enumerates all other issued objects, listing their file names and 566 content hashes. 568 However, it is possible that an object whose content hash matches the 569 hash listed in the manifest, has either a different file name, or is 570 located at a different publication point in a repository. 572 On the other hand, all RPKI objects, either explicitly or within 573 their embedded EE certificate, have an Authority Key Identifier 574 extension that contains the key identifier of their issuing CA 575 certificate. Therefore it is always possible to perform an RPKI 576 validation of the object whose expected location does not match its 577 actual location, provided that the certificate that matches the AKI 578 of the object in question is known to the system that performs 579 validation. 581 In case of a mismatch described above this implementation will not 582 exclude an object from further validation merely because its actual 583 location or file name does not match the expected location or file 584 name. This decision was chosen because the actual location of a file 585 in a repository is taken from the repository retrieval mechanism, 586 which, in case of an rsync repository, does not provide any 587 cryptographic security, and in case of an RRDP repository, provides 588 only a transport layer security, with the fallback to unsecured 589 transport. On the other hand, the manifest is an RPKI signed object, 590 and its content could be verified in the context of the RPKI 591 validation. 593 9.4. Manifest content versus publication point content 595 This algorithm uses the content of a manifest object to determine 596 other objects issued by a CA certificate. It verifies that the 597 manifest is located in the publication point designated in the CA 598 Certificate's SIA extension. However, if there are other (not listed 599 in the manifest) objects located in the same publication point 600 directory, they are ignored, even if they might be valid and issued 601 by the same CA as the manifest. (This RP behavior is allowed, but 602 not required, by [RFC6486].) 604 9.5. Possible denial of service 606 The store cleanup procedure described in Section 4.3 tries to 607 minimise removal and subsequent re-fetch of objects that are 608 published in a repository, but not used in the validation. Once such 609 objects are removed from the remote repository, they will be 610 discarded from the local object store after a period of time 611 specified by a local policy. By generating an excessive amount of 612 syntactically valid RPKI objects, a man-in-the-middle attack between 613 a validating tool and a repository could force an implementation to 614 fetch and store those objects in the object store (see Section 5.1.1) 615 before they are validated and discarded, leading to an out-of-memory 616 or out-of-disk-space conditions, and, subsequently, a denial of 617 service. 619 10. References 621 10.1. Normative References 623 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 624 Housley, R., and W. Polk, "Internet X.509 Public Key 625 Infrastructure Certificate and Certificate Revocation List 626 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 627 . 629 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 630 Resource Certificate Repository Structure", RFC 6481, 631 DOI 10.17487/RFC6481, February 2012, 632 . 634 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 635 Origin Authorizations (ROAs)", RFC 6482, 636 DOI 10.17487/RFC6482, February 2012, 637 . 639 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 640 "Manifests for the Resource Public Key Infrastructure 641 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 642 . 644 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 645 X.509 PKIX Resource Certificates", RFC 6487, 646 DOI 10.17487/RFC6487, February 2012, 647 . 649 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 650 Template for the Resource Public Key Infrastructure 651 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 652 . 654 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 655 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 656 February 2012, . 658 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 659 Procedure for the Resource Public Key Infrastructure 660 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 661 2013, . 663 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 664 "Resource Public Key Infrastructure (RPKI) Trust Anchor 665 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 666 . 668 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 669 Algorithms and Key Sizes for Use in the Resource Public 670 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 671 August 2016, . 673 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 674 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 675 DOI 10.17487/RFC8182, July 2017, 676 . 678 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 679 Newton, A., and D. Shaw, "Resource Public Key 680 Infrastructure (RPKI) Validation Reconsidered", RFC 8360, 681 DOI 10.17487/RFC8360, April 2018, 682 . 684 10.2. Informative References 686 [github] "RIPE NCC RPKI Validator on GitHub", 687 . 689 [rsync] "Rsync home page", . 691 Authors' Addresses 692 Oleg Muravskiy 693 RIPE NCC 695 Email: oleg@ripe.net 696 URI: https://www.ripe.net/ 698 Tim Bruijnzeels 699 NLNetLabs 701 Email: tim@nlnetlabs.nl 702 URI: https://www.nlnetlabs.nl/