randy/draft-6486bis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

some egregious typos

Browse source
This commit is contained in:
Randy Bush 2020-07-06 10:58:40 -07:00
parent 69899755f3
commit 968033f009
1 changed files with 174 additions and 174 deletions
Download patch file Download diff file Expand all files Collapse all files

344
draft-ymbk-sidrops-6486bis.txt
View file

@ -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
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. 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.
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]