Re: [Sidrops] Interim Meeting Follow-up Mail

Hi Steve,

> On 28 Oct 2020, at 17:02, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
> 
> Tim,
> 
> I looked at the revised bullet points we agreed upon and crafted a new Section 6.4 to reflect the last point. (The first three were already covered in this or other sub-sections of Section 6.) The proposed, revised text is below. If you concur, I'll ask that 6486-bis be revised accordingly.
> 
> 
> 
> 
> 6.4.  Acquiring Files Referenced by a Manifest

Right, indeed it's section 6.4 that needs the update. I was a bit confused by the repeated text in 6.7 (Failed Fetches). Maybe this first sentence could be dropped?

   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.

To me this reads like these checks are done as part of 6.7, whereas actually these checks to determine that a fetch failed were all done in earlier sections and that is why implementers were directed to proceed to 6.7, right?

>    The RP MUST acquire all of the files enumerated in the manifest
>    (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 Section 6.7; otherwise, proceed to
>    Section 6.5. Note that the set of retrieved objects may include types that
>    the PR is not prepared to process, e.g., objects other than CRLs, certificates, 
>    and Ghostbuster records (all of which MUST be processed by an RP, if present). 
>    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.

I see you use "e.g." when enumerating types which MUST be processed. But I think it would be better to either enumerate all object types explicitly, or have no enumeration and leave the choice which types MUST be supported out of this context.

If you go for explicit enumeration, then it will most likely need updating by future RFCs. E.g. the ASPA RFC when it comes out could update the list. How about something like this:

   Note that the following objects MUST all be fully validated if present:
    * Manifests (this document)
    * CRLs [RFC6487]
    * Resource Certificates [RFC6487]
    * BGPsec Router Certificates [RFC8209]
    * Ghostbuster Records [RFC6493]
    * Route Origin Authorizations [RFC6482]

   However, the publication point MAY include other 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.  

As a note to implementers: there is little (inter-)operational experience in producing and validating BGPsec Router Certificates and Ghostbuster Records. I am okay with including them in a list, but I would advise that CAs test with known RP software and collaborate, before deploying these objects in production environments.

Tim

> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
> 