Re: [Sidrops] 6486bis: Failed Fetches

Tim Bruijnzeels <> Tue, 29 September 2020 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 096963A0E98 for <>; Tue, 29 Sep 2020 07:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MfGf5inEZuPU for <>; Tue, 29 Sep 2020 07:55:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF8EB3A0E96 for <>; Tue, 29 Sep 2020 07:55:00 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:99f5:dd02:32ca:b184] (unknown [IPv6:2001:981:4b52:1:99f5:dd02:32ca:b184]) by (Postfix) with ESMTPSA id D5DEC1F448; Tue, 29 Sep 2020 16:54:58 +0200 (CEST)
Authentication-Results:; dmarc=fail (p=none dis=none)
Authentication-Results:; spf=fail
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1601391298; bh=xtdC6Q/NY/1J7w+qFuKkdQredmfg5+Ujz8dhNpkl3jM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=aDr08IfbiAs9G2epaK2dQdQpkvZcGwUbFtDjAH02NW1JcogAqCU+oq+pyPH6douDk mfUqFx4uBhQuX+4mwH0RTyt18yTOJvwP+fS8BQxvTTIsNJXcrZ1c/rvWdzR9tYc9IF BvkRJYYCK4tqJGtikUqHwyK6Ba3ZlMmiszZthVEo=
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: Tue, 29 Sep 2020 16:54:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Stephen Kent <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Tue, 29 Sep 2020 14:55:02 -0000


On 7 Sep 2020, at 13:17, Tim Bruijnzeels <> wrote:
>>> If we do go down this road then I think that we should also look at the manifest object itself, and let it convey which object (types) are critical (and while we are at it, we can specify types instead of using filename extensions). That way future object types could introduced more easily perhaps - this obviously needs more discussion but it could even allow for semantics like: 1) new object please test, don't use, 2) new objects, use if you can, 3) new objects, critical - fail if you don't understand.
>> One could combine the new SIA URI and a revised manifest, in which the manifest contains the per-object flag, rather than redefining the basic object format to accommodate the flag. That would reduce the number of RFCs that need to change. Good idea.
> Upon reflection I realised that even the introduction of an SIA in the issuing CA certificate will lead to issues. RPs would reject the CA certificate, and as a result the whole PP of the parent CA. This means that the SIA cannot be deployed without leaving a significant number of RP installations behind. E.g. if I run a delegated CA under an RIR which wants to adopt ASPA, and I get a new CA certificate with the additional SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be rejected.

I have done some testing on this.

Section of RFC 6487 seems to say that additional SIA OIDs for CA certificates can be expected and can be ignored. And indeed it seems that all current RP software will accept (and ignore) additional SIAs.

At least that's the result from adding an extra SIA in a Krill branch and running the end to end tests using the following validator versions:

fortvalidator 1.4.0
OctoRPKI v1.1.4 (2019-08-06T16:51:07-0700)
rcynic version believed to be buildbot-1.0.1544679302
routinator 0.7.1
rpkiclient 6.7p1
rpkivalidator3 3.1-2020.

I am still not very happy about the overhead that this approach implies:

Additional publication points which need to be maintained, which may be out of sync. What if MFT A has a certain ROA and MFT B doesn't? This can lead to serious operational impact if an announcement would be valid under one, but not the other.

It would also require much more fundamental code changes for producing CAs - one cannot just support a new object type. One has to support an additional publication model. Parent CAs have to be willing to include the new SIAs as well affecting the ability to deploy for delegated CAs.

But, at least it seems that it can be introduced without breaking things immediately for existing deployed validators.