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

kent hacking along

Browse source
This commit is contained in:
Randy Bush 2020-10-30 17:37:29 -07:00
parent 277bf99c29
commit 99b9d49e5d
1 changed files with 27 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -10,7 +10,7 @@
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-sidrops-6486bis-00" updates="6486" ipr="trust200902">
<rfc category="std" docName="draft-ietf-sidrops-6486bis-01" updates="6486" ipr="trust200902">
<front>
@ -706,14 +706,22 @@
<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
<xref target="sect-6.5"/>.
(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
[RFC6488], the fetch has failed and the RP MUST proceed to <xref
target="sect-6.7"/>; otherwise, proceed to <xref
target="sect-6.5"/>. 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 Section 2.1.3.2 above) of such
objects; encountering such objects does not, per se, result in a
failed fetch.
</t>
</section>
@ -744,26 +752,24 @@
<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
operator be notified of this warning.
If a fetch fails for any of the reasons cited in <xref
target="sect-6.2"/>-<xref target="sect-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
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>
</section>
@ -891,10 +897,13 @@
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5280"?>
<?rfc include="reference.RFC.6481"?>
<?rfc include="reference.RFC.6482"?>
<?rfc include="reference.RFC.6485"?>
<?rfc include="reference.RFC.6487"?>
<?rfc include="reference.RFC.6488"?>
<?rfc include="reference.RFC.6493"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8209"?>
<reference anchor="X.690">
<front>
<title>ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)</title>