From 968033f009b8f6705a3364d6fb848574d8cb8677 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Mon, 6 Jul 2020 10:58:40 -0700 Subject: [PATCH] some egregious typos --- draft-ymbk-sidrops-6486bis.txt | 348 ++++++++++++++++----------------- 1 file changed, 174 insertions(+), 174 deletions(-) diff --git a/draft-ymbk-sidrops-6486bis.txt b/draft-ymbk-sidrops-6486bis.txt index 250903d..e08f9bc 100644 --- a/draft-ymbk-sidrops-6486bis.txt +++ b/draft-ymbk-sidrops-6486bis.txt @@ -6,11 +6,11 @@ Network Working Group R. Austein Internet-Draft Arrcus, Inc. Updates: 6486 (if approved) G. Huston Intended status: Standards Track APNIC -Expires: December 26, 2020 S. Kent +Expires: January 7, 2021 S. Kent Independent M. Lepinski New College Florida - June 24, 2020 + July 6, 2020 Manifests for the Resource Public Key Infrastructure (RPKI) @@ -48,14 +48,14 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 26, 2020. + This Internet-Draft will expire on January 7, 2021. -Austein, et al. Expires December 26, 2020 [Page 1] +Austein, et al. Expires January 7, 2021 [Page 1] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 Copyright Notice @@ -88,18 +88,18 @@ Table of Contents 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 8 5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8 5.2. Considerations for Manifest Generation . . . . . . . . . 9 - 6. Relying Party Use of Manifests . . . . . . . . . . . . . . . 9 - 6.1. Manifest Processing Overview . . . . . . . . . . . . . . 10 + 6. Relying Party Processing of Manifests . . . . . . . . . . . . 9 + 6.1. Manifest Processing Overview . . . . . . . . . . . . . . 11 6.2. Acquiring a Manifest for a CA . . . . . . . . . . . . . . 11 6.3. Detecting Stale and or Prematurely-issued Manifests . . . 11 - 6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 11 + 6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 12 6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12 6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12 - 6.7. Termination of Processing . . . . . . . . . . . . . . . . 12 - 7. Publication Repositories . . . . . . . . . . . . . . . . . . 12 + 6.7. Failed Fetches . . . . . . . . . . . . . . . . . . . . . 12 + 7. Publication Repositories . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15 @@ -109,9 +109,9 @@ Table of Contents -Austein, et al. Expires December 26, 2020 [Page 2] +Austein, et al. Expires January 7, 2021 [Page 2] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 1. Introduction @@ -165,9 +165,9 @@ Internet-Draft RPKI Manifests June 2020 -Austein, et al. Expires December 26, 2020 [Page 3] +Austein, et al. Expires January 7, 2021 [Page 3] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 2. Manifest Scope @@ -221,9 +221,9 @@ Internet-Draft RPKI Manifests June 2020 -Austein, et al. Expires December 26, 2020 [Page 4] +Austein, et al. Expires January 7, 2021 [Page 4] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 4. Manifest Definition @@ -277,9 +277,9 @@ Internet-Draft RPKI Manifests June 2020 -Austein, et al. Expires December 26, 2020 [Page 5] +Austein, et al. Expires January 7, 2021 [Page 5] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 specified in nextUpdate or until a manifest is issued with a greater @@ -333,9 +333,9 @@ Internet-Draft RPKI Manifests June 2020 -Austein, et al. Expires December 26, 2020 [Page 6] +Austein, et al. Expires January 7, 2021 [Page 6] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 encompasses a CRL, the nextUpdate field of the manifest MUST match @@ -389,9 +389,9 @@ Internet-Draft RPKI Manifests June 2020 -Austein, et al. Expires December 26, 2020 [Page 7] +Austein, et al. Expires January 7, 2021 [Page 7] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 5. Manifest Generation @@ -445,9 +445,9 @@ Internet-Draft RPKI Manifests June 2020 -Austein, et al. Expires December 26, 2020 [Page 8] +Austein, et al. Expires January 7, 2021 [Page 8] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 Note that the manifest does not include a self reference (i.e., @@ -493,27 +493,43 @@ Internet-Draft RPKI Manifests June 2020 manifest associated with each active CA instance that is publishing into the common repository publication point (directory). -6. Relying Party Use of Manifests +6. Relying Party Processing of Manifests - Each RP MUST determine which signed objects it will use for + Each RP must determine which signed objects it will use for validating assertions about INRs and their use (e.g., which ROAs to - use in the construction of route filters). Manifests are designed to + use in the construction of route filters). As noted earlier, -Austein, et al. Expires December 26, 2020 [Page 9] +Austein, et al. Expires January 7, 2021 [Page 9] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 - allow an RP to detect manipulation of repository data and/or errors - by a CA or repository manager. Unless _all_ of the files enumerated - in a manifest can be obtained by an RP (either from a publication - point or from a local cache), an RP MUST ignore the data associated - with the publication point. This stringent response is needed to - prevent an RP from misinterpreting data associated with a publication - point, and thus possibly treating invalid routes as valid, or vice - versa. + manifests are designed to allow an RP to detect manipulation of + repository data, errors by a CA or repository manager, and/or active + attacks on the communication channel between an RP and a repository. + Unless all of the files enumerated in a manifest can be obtained by + an RP during a fetch operation, the fetch is considered to have + failed and the RP MUST retry the fetch later. + + [RFC6480] suggests (but does not mandate) that the RPKI model employ + fetches that are incremental, e.g., an RP transfers files from a + publication point only if they are new/changed since the previous, + successful, fetch represented in the RP's local cache. This document + avoids language that relies on details of the underlying file + transfer mechanism employed by an RP and a publication point to + effect this operation. Thus the term "fetch" refers to an operation + that attempts to acquire the full set of files at a publication + point, consistent with the id-ad-rpkiManifest URI extracted from a CA + certificate's SIA (see below). + + If a fetch fails, it is assumed that a subsequent fetch will resolve + problems encountered during the fetch. Until such time as a + successful fetch is executed, an RP SHOULD use cached data from a + previous, successful fetch. This response is intended to prevent an + RP from misinterpreting data associated with a publication point, and + thus possibly treating invalid routes as valid, or vice versa. The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to achieve @@ -521,159 +537,148 @@ Internet-Draft RPKI Manifests June 2020 operation, different RPs will access repositories at different times, and some RPs may experience local cache failures, so there is no guarantee that all RPs will achieve the same results with regard to - validation of RPKI data + validation of RPKI data. Note that there is a "chicken and egg" relationship between the manifest and the CRL for a given CA instance. If the EE certificate for the current manifest is revoked, i.e., it appears in the current CRL, then the CA or publication point manager has made a serious - error. In this case all signed objects associated with the CA - instance MUST be ignored. Similarly, if the CRL is not listed on a - valid, current manifest, all signed objects associated with the CA - instance MUST be ignored, because the CRL is considered missing. + error. In this case the fetch has failed; proceed to Section 6.7. + Similarly, if the CRL is not listed on a valid, current manifest, + acquired during a fetch, the fetch has failed; proceed to + Section 6.7, because the CRL is considered missing. + + Note that if a CA and its associated publication point are operating + properly, there will always be exactly one manifest and one + associated CRL at the publication point identified in the CA's SIA + (see below). + + + + + +Austein, et al. Expires January 7, 2021 [Page 10] + +Internet-Draft RPKI Manifests July 2020 + 6.1. Manifest Processing Overview For a given publication point, an RP MUST perform a series of tests to determine which signed object files at the publication point are - acceptable. The tests described below are to be performed using - themanifest identified by the id-ad-rpkiManifest URI extracted from a - CA certificate's SIA. _All_ of the files referenced by the manifest - MUST be be located at the publication point specified by the id-ad- - caRepositoryURI from the (same) certificate's SIA. The manifest and - the files it references MUST reside at the same publication point. - An RP MUST ignore any files that appear on a manifest but do not - reside as the same publication point as the manifest. + acceptable. The tests described below (Section 6.2 to Section 6.6) + are to be performed using the manifest identified by the id-ad- + rpkiManifest URI extracted from a CA certificate's SIA. All of the + files referenced by the manifest MUST be be located at the + publication point specified by the id-ad-caRepository URI from the + (same) CA certificate's SIA. The manifest and the files it + references MUST reside at the same publication point. If an RP + encounters any files that appear on a manifest but do not reside at + the same publication point as the manifest the RP MUST treat the + fetch as failed, and a warning MUST be issued (see Section 6.7 + below). - 1. All of the files referenced by the manifest MUST be be located at - the publication point specified by the id-ad-caRepository URI - from the (same) certificate's SIA. If the manifest and the files - it references do not reside at the same publication point, an RP - MUST *???* + A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be + at the location specified in the CRLDP in the manifest's EE + certificate. If more than one .crl file appears in the manifest, the + fetch has failed and the RP MUST proceed to Section 6.7; otherwise + proceed to Section 6.2. - 2. A manifest SHOULD contain exactly one CRL (.crl) file and it MUST - be at the location specified in the CRLDP in the manifest's EE - certificate. - - - -Austein, et al. Expires December 26, 2020 [Page 10] - -Internet-Draft RPKI Manifests June 2020 - - - 3. If more than one .crl file appears in the manifest, only file - names matching the CRL specified by the CRLDP will be processed. - If more than one .crl entry appears in the manifest, and matches - the CRLDP, the first one encountered MUST be used. Any other - .crl files MUST be ignored and a warning MUST be issued. - - 4. Note that, during CA key rollover [RFC6489], signed objects for - two or more different CA instances will appear at the same - publication point. - - 5. Manifest processing is to be performed separately for each CA - instance, guided by the SIA id-ad-rpkiManifest URI in each CA - certificate. - - 6. Note also that the processing described here will be performed - using locally cached files if an RP does not detect newer - versions of the files in the RPKI repository system. + Note that, during CA key rollover [RFC6489], signed objects for two + or more different CA instances will appear at the same publication + point. Manifest processing is to be performed separately for each CA + instance, guided by the SIA id-ad-rpkiManifest URI in each CA + certificate. 6.2. Acquiring a Manifest for a CA - Acquire the manifest identified by the SIA id-ad-rpkiManifest URI in - the CA certificate. If an RP cannot retrieve a manifest using this - URI, or if the manifest is not valid (Section 4.4), an RP SHOULD - examine the most recent, cached manifest matching this URI. If that - manifest is current (Section 4.4) proceed to Section 6.3. If the - publication point does not contain a valid manifest, and the cached - manifest is not current, proceed to Section 6.7. + The RP MUST fetch the manifest identified by the SIA id-ad- + rpkiManifest URI in the CA certificate. If an RP cannot retrieve a + manifest using this URI, or if the manifest is not valid + (Section 4.4), an RP MUST treat this as a failed fetch and, proceed + to Section 6.7; otherwise proceed to Section 6.3. 6.3. Detecting Stale and or Prematurely-issued Manifests - Check that the current time (translated to UTC) is between thisUpdate - and nextUpdate. If the current time lies within this interval, - proceed to Section 6.4. If the current time is earlier than - thisUpdate, the CA has made an error. If the RP cache contains a - current manifest, use that manifest instead and issue a warning. If - an RP has no access to a current manifest, processing stops and a - warning MUST be issued. If the current time is later than - nextUpdate, then the manifest is stale. If the RP cache contains a - current manifest, use that manifest instead and issue a warning.If no - current manifest is available, proceed to Section 6.7. + The RP MUST check that the current time (translated to UTC) is + between thisUpdate and nextUpdate. If the current time lies within + this interval, proceed to Section 6.4. If the current time is + earlier than thisUpdate, the CA has made an error; this a failed + fetch and the RP MUST proceed to Section 6.7. If the current time is + later than nextUpdate, then the manifest is stale; this is a failed + fetch and RP MUST proceed to Section 6.7; otherwise proceed to + Section 6.4. + + + + + +Austein, et al. Expires January 7, 2021 [Page 11] + +Internet-Draft RPKI Manifests July 2020 + 6.4. Acquiring Files Referenced by a Manifest - Acquire all files enumerated in the manifest (fileList) from the - publication point. This includes the CRL, each object containing an - EE certificate issued by the C, and all subordinate CA and EE - certificates. If there are files listed in the manifest that cannot - be retrieved from the publication point, or if they fail the validity - - - -Austein, et al. Expires December 26, 2020 [Page 11] - -Internet-Draft RPKI Manifests June 2020 - - - tests specified in [RFC6488], the RP SHOULD examine its cache to - determine if these files are available locally. If all of the - missing/invalid files are available from the RP's cache, i.e., each - file name matches the list extracted from the manifest, the RP SHOULD - use the cached files to replace those missing from the publication - point, and proceed to Section 6.5. However, if _any_ of the missing/ - invalid files cannot be replaced in this fashion, then proceed to - Section 6.7. + The RP MUST acquire all of the files enumerated in the manifest + (fileList) from the publication point. This includes the CRL, each + object containing an EE certificate issued by the CA, and any + subordinate CA and EE certificates. If there are files listed in the + manifest that cannot be retrieved from the publication point, or if + they fail the validity tests specified in [RFC6488], the fetch has + failed and the RP MUST proceed to Section 6.7; otherwise, proceed to + Section 6.5. 6.5. Matching File Names and Hashes - Verify that the hash value of every file listed in the manifest - matches the value obtained by hashing the file acquired from the - publication point or local cache. If the computed hash value of a - file listed on the manifest does not match the hash value contained - in the manifest, then an RP SHOULD examine its local cache to - determine if the same file is available. The RP SHOULD use cached - files to replace any (damaged) downloaded files, so long as the hash - of the cached file matches the hash from the manifest. If any of the - files with hash mismatches cannot be replaced in this fashion, - proceed to 6.7. Otherwise proceed to Section 6.6. + The RP MUST verify that the hash value of each file listed in the + manifest matches the value obtained by hashing the file acquired from + the publication point. If the computed hash value of a file listed + on the manifest does not match the hash value contained in the + manifest, then the fetch has failed and the RP MUST proceed to + Section 6.7; otherwise proceed to Section 6.6. 6.6. Out of Scope Manifest Entries If a current manifest contains entries for objects that are not - within the scope of the manifest (Section 2), then the out-of-scope - entries MUST be disregarded. + within the scope of the manifest (Section 6.2), the fetch has failed + and the RP proceed to Section 6.7; otherwise the fetch is deemed + successful and the RP will process the fetched objects. -6.7. Termination of Processing +6.7. Failed Fetches - If an RP cannot acquire a current, valid manifest, or acquire - current, valid instances of all of the objects enumerated in a - current valid manifest, then processing of the signed objects - associated with the CA has failed. The RP MUST issue a warning - indicating the reason(s) for termination of processing with regard to - this CA. + If an RP does not acquire a current valid manifest, or does not + acquire current valid instances of all of the objects enumerated in a + current valid manifest as a result of a fetch, then processing of the + signed objects associated with the CA instance has failed for this + fetch cycle. The RP MUST issue a warning indicating the reason(s) + for termination of processing with regard to this CA instance. It is + RECOMMENDED that a human operator be notified of this warning. + + Termination or 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. + + + + + + + +Austein, et al. Expires January 7, 2021 [Page 12] + +Internet-Draft RPKI Manifests July 2020 - Termination or processing means that all of the ROAs and subordinate - certificates (CA and EE) MUST be considered invalid. This implies - that the RP MUST not try to acquire and validate _subordinate_ signed - objects, until the next interval when the RP is scheduled to process - data for this part of the RPKI repository system. 7. Publication Repositories The RPKI publication system model requires that every publication point be associated with one or more CAs, and be non-empty. Upon creation of the publication point associated with a CA, the CA MUST - - - -Austein, et al. Expires December 26, 2020 [Page 12] - -Internet-Draft RPKI Manifests June 2020 - - create and publish a manifest as well as a CRL. A CA's manifest will always contain at least one entry, namely, the CRL issued by the CA upon repository creation [RFC6481]. @@ -717,19 +722,19 @@ Internet-Draft RPKI Manifests June 2020 Object" and three-letter filename extensions for "RPKI Repository Name Schemes," no new action is requested of the IANA. + + + +Austein, et al. Expires January 7, 2021 [Page 13] + +Internet-Draft RPKI Manifests July 2020 + + 10. Acknowledgements The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark - - - -Austein, et al. Expires December 26, 2020 [Page 13] - -Internet-Draft RPKI Manifests June 2020 - - Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. The authors also wish to thank Job Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of @@ -776,14 +781,9 @@ Internet-Draft RPKI Manifests June 2020 - - - - - -Austein, et al. Expires December 26, 2020 [Page 14] +Austein, et al. Expires January 7, 2021 [Page 14] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 [X.690] International International Telephone and Telegraph @@ -837,9 +837,9 @@ Appendix A. ASN.1 Module -Austein, et al. Expires December 26, 2020 [Page 15] +Austein, et al. Expires January 7, 2021 [Page 15] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) @@ -893,9 +893,9 @@ Authors' Addresses -Austein, et al. Expires December 26, 2020 [Page 16] +Austein, et al. Expires January 7, 2021 [Page 16] -Internet-Draft RPKI Manifests June 2020 +Internet-Draft RPKI Manifests July 2020 Geoff Huston @@ -949,4 +949,4 @@ Internet-Draft RPKI Manifests June 2020 -Austein, et al. Expires December 26, 2020 [Page 17] +Austein, et al. Expires January 7, 2021 [Page 17]