Re: [Sidrops] Interim Meeting Follow-up Mail

Tim Bruijnzeels <> Thu, 29 October 2020 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DB713A03FC for <>; Thu, 29 Oct 2020 05:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xpT696B5TitZ for <>; Thu, 29 Oct 2020 05:56:32 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2CEF3A0A16 for <>; Thu, 29 Oct 2020 05:56:31 -0700 (PDT)
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1003460B19; Thu, 29 Oct 2020 12:56:28 +0000 (UTC)
Received: from ( []) by
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=soverin; t=1603976187; bh=ZJGjXkOxb2Kt1yLoXqlI0939Za2Rwpq8k8P+AHmOt44=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Gsjs3JRJjKjcCmspSwMoZnp7NBg4fp1a7GCDWtfAEs0wtwv68MVU25jYfVi/JhUs7 qCSiILSDGusW/qcuFefuyI5aEEHFfX4fcwUag9viiEZXQUg87PAAgIEk/2gkVsSGTK W5Me530DskVdq/4uN6OusvOc8DMKCXkPSwnV4kjXEFyL/GVztwpZOAIX5Fik+geuZp sg25h5rJgWulyc9usXf2FzOVqxZVqDwlKhHLmZiIheOB/YV7jDDfqfPmmQ83NDebzC L4hxNndp4HO/VJ+uDvfvtuJJURxbv8utuJQubCO1m+JOiqlv1ObV2O/d535LapNYYL 5+Q2peW4evGjA==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Thu, 29 Oct 2020 13:56:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Stephen Kent <>
Archived-At: <>
Subject: Re: [Sidrops] Interim Meeting Follow-up Mail
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Oct 2020 12:56:34 -0000

Hi Steve,

> On 28 Oct 2020, at 17:02, Stephen Kent <> 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 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 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.


> _______________________________________________
> Sidrops mailing list