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

Update section 6.4

Browse source 
Text from Stephen Kent, input from Tim Bruijnzeels

	Date: Thu, 29 Oct 2020 15:37:30 +0000
	From: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
	To: Tim Bruijnzeels <tim@nlnetlabs.nl>
	Cc: sidrops@ietf.org
	Subject: Re: [Sidrops] Interim Meeting Follow-up Mail
This commit is contained in:
Job Snijders 2020-10-30 18:56:36 +00:00
parent 277bf99c29
commit 7618144e25
1 changed files with 29 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

51
draft-ietf-sidrops-6486bis.xml
View file

@ -706,15 +706,27 @@
<t>
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 <xref target="RFC6488"/>, the fetch has failed and the RP
MUST proceed to <xref target="sect-6.7"/>; otherwise, proceed to
(fileList) from the publication point. 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 <xref target="RFC6488"/>,
the fetch has failed and the RP MUST proceed to Section 6.7; otherwise,
proceed to <xref target="sect-6.7"/>; otherwise, proceed to
<xref target="sect-6.5"/>.
</t>
<t>
Note that all RPs MUST be able to process Manifests, Note that
all RPs MUST be able to process Manifests, CRLs and Resource
Certificates <xref target="RFC6487"/>, BGPsec Router Certificates
<xref target="RFC8209"/>, Ghostbuster Records <xref target="RFC6493"/>,
and ROAs <xref target="RFC6482"/>. The set of retrieved objects may
include other RPKI object types that the RP is not prepared to process.
When such objects are encountered by an RP, the RP MUST NOT attempt to
validate the eContent (as described in
<xref target="sect-2.1">Section 2.1.3.2</xref> above) of such objects;
encountering such objects does not, per se, result in a failed fetch.
</t>
</section>
<section title="Matching File Names and Hashes" anchor="sect-6.5">
@ -744,25 +756,20 @@
<section title="Failed Fetches" anchor="sect-6.7">
<t>
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
If a fetch fails for any of the reasons cited in 6.2-6.6, 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.
</t>
<t>
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.
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.
</t>
</section>