Re: [Sidrops] 6486bis: referenced object validation

Job Snijders <> Fri, 04 December 2020 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B08173A100A for <>; Fri, 4 Dec 2020 13:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SiRI0r3NjQaS for <>; Fri, 4 Dec 2020 13:23:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6FB13A102B for <>; Fri, 4 Dec 2020 13:23:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id 576E5220133; Fri, 4 Dec 2020 21:23:17 +0000 (UTC)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id 05f0a090; Fri, 4 Dec 2020 21:23:14 +0000 (UTC)
Date: Fri, 04 Dec 2020 21:23:14 +0000
From: Job Snijders <>
To: Tim Bruijnzeels <>
Cc: Benno Overeinder <>, SIDR Operations WG <>, Martin Hoffmann <>, Ben Maddison <>
Message-ID: <>
References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Sidrops] 6486bis: referenced object validation
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: Fri, 04 Dec 2020 21:23:28 -0000

Dear group,

On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrote:
> On 6486 in particular there was a strong desire communicated by
> operators that RPs behave the *same* way.

> Which is why we were hesitant to implement the changes suggested by
> you in the GH issue. 

I have a celebratory moment to share with all of you, below is a
terminal transcript and some hashes which will allow you to confirm my

The below was executed on a modern POSIX.1 implementation with default
settings. I used routinator's '-n' option and a symlink to ensure the
input to both routinator and rpki-client is the same, up and including
to all filesystem metadata.

We have some tals:

    # ls /etc/rpki
    afrinic.tal apnic.tal   arin.tal    disabled    lacnic.tal  ripe.tal

Execute rpki-client, which will fork rsync and gather all data from the
Internet. The system is located in Amsterdam. I've also included the
size of the cache and a hash of all the object filenames that were in
the cache at that moment.

    # rpki-client -jc > /dev/zero 2>&1 && date
    Fri Dec  4 20:33:14 UTC 2020
    # cd /var/cache/rpki-client && du -s
    839028  .

    # find . | sha256

rpki-client VRP set:

    # sort /var/db/rpki-client/csv | sha256

routinator 0.8.2-rc1 VRP set:

    # ls -lahtr .rpki-cache/repository/rsync
    lrwxr-xr-x  1 job  job    23B Dec  4 20:09 .rpki-cache/repository/rsync -> /var/cache/rpki-client/

    # ./target/debug/routinator -v -t /etc/rpki vrps -n 2>/dev/zero | sort | sha256

>From the above we learn it truly is possible for multiple entirely
different implementations written by different people to arrive at the
**exact** same results, based on data derived from a complex distributed
PKI system with 5 Trust Anchors and 22,084 manifests from tens of
thousands of CAs resulting in the exact same 205,768 unique VRPs.

I *also* went back to December 1st, 2020 at 00:00:13 UTC and fed that
data from the tarball linked at
into both routinator and rpki-client, and the resulting VRP lists from
both rpki-client and routinator resulted in the same hash:

However rocky the road was to get to this point, this really is a
marvelous achievement at scale for the internet engineering community.
Congratulations NLNetLabs. I hope other implementations will soon arrive
at the be9e7fd656c3d143f2eb5cbb0b13d299a3534c6043f49a3330f5ac14854e621f
checksum when mimicking that december 1st moment with that x509 data

Kind regards,


ps. Please note the above two data points are only single snapshots in
time, but encouraging ones. At present I am aware of implementation
differences between RP implementations related to ASN/BER/DER handling,
and possibly other differences, which will probaably manifest themselves
(pun intended) at one point or another in the future, or already have in
the past.