[Sidrops] rpki-client implementation report (Was: 6486 bis)

Job Snijders <job@ntt.net> Wed, 24 June 2020 11:39 UTC

Return-Path: <job@ntt.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8FA3A0D73 for <sidrops@ietfa.amsl.com>; Wed, 24 Jun 2020 04:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLcECk5JVZcb for <sidrops@ietfa.amsl.com>; Wed, 24 Jun 2020 04:39:06 -0700 (PDT)
Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5F13A0D70 for <sidrops@ietf.org>; Wed, 24 Jun 2020 04:39:06 -0700 (PDT)
Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 9A9A622014C; Wed, 24 Jun 2020 11:39:05 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 8A25927C0058; Wed, 24 Jun 2020 07:39:04 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 24 Jun 2020 07:39:04 -0400
X-ME-Sender: <xms:VzvzXmXmlb_A5lk1GlcPk_kKqFa_fsifNnFVqejHCkO6eGgZnivVgw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdttd dttddtvdenucfhrhhomheplfhosgcuufhnihhjuggvrhhsuceojhhosgesnhhtthdrnhgv theqnecuggftrfgrthhtvghrnhephffhtdehteeiveehkedvuedtffeuieejtdetfeegie ffudfhkefhgeelvddtvdejnecukfhppeduledvrddugeejrdduieekrddutdejnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhosgdomhgvsh hmthhprghuthhhphgvrhhsohhnrghlihhthidquddtgeejleduheekgedqvdeffeefkeef vddtqdhjohgspeepnhhtthdrnhgvthesshhosghorhhnohhsthdrnhgvth
X-ME-Proxy: <xmx:WDvzXinz44JIAwUgN_CE_rxh6gu4rnGWYB2i4369zHi1h79aofRhww> <xmx:WDvzXqa2sTYc7k7M8wx1CcOL1_3SjPFHBF80FphpPvWdP6TyFsnICg> <xmx:WDvzXtVUr414ckGtsNMkTtFOg6hpBYSlAka-YAznf305YkaAb7O2YA> <xmx:WDvzXulX6BuPe6U0NGQ8gmiNbsn3Ak1PD6LQAwJvNvWGkHYmsVAaRg>
Received: from bench.sobornost.net (bench.sobornost.net [192.147.168.107]) by mail.messagingengine.com (Postfix) with ESMTPA id A005A328005A; Wed, 24 Jun 2020 07:39:03 -0400 (EDT)
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id b874688b; Wed, 24 Jun 2020 11:39:01 +0000 (UTC)
Date: Wed, 24 Jun 2020 11:39:00 +0000
From: Job Snijders <job@ntt.net>
To: sidrops@ietf.org
Message-ID: <20200624113900.GA87904@bench.sobornost.net>
References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> <bb3748c0-33ad-6512-d3d8-d6888fd4aac5@verizon.net> <CAL9jLaYZ3LS=5Mke1ELj8TpDpazcGTmynaTZKUvn+kt2-qqyDA@mail.gmail.com> <CAL9jLabmLQQaTYGcqb=tDYGPdFT7EJCRXunfKcsvvLMiM2V22Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL9jLabmLQQaTYGcqb=tDYGPdFT7EJCRXunfKcsvvLMiM2V22Q@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/aNl14ngWmxRE7w5xDX4kRMgqSb4>
Subject: [Sidrops] rpki-client implementation report (Was: 6486 bis)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 11:39:08 -0000

Dear group,

This is an implementation report based on my understanding of OpenBSD's
current rpki-client's behavior. We've worked hard in the last few months
to convince the community at large that there are important isues in how
some implementations treated untrusted data. Please verify this yourself
as well, I could be wrong!

Other RPKI cache implementers who care about security may want to copy
this template so we can more easily compare notes. <<< HOMEWORK >>>

The "OK" in the below table means that *I* think rpki-client's
understanding of the proposed internet-draft text is compliant with the
source code. The "OK" does not mean good/bad, in some cases there might
be reason to deviate from the specs (an implementation could be ahead of
its time). The normative terms are where the money is, so by mapping
normative terms to behavior we can more easily understand whether
consensus is emerging in this group.

The goal of this implementation report template is not to get as many
OKs as possible, but to see which implementers are tracking this effort
and where they currently stand. I know that routinator for instance will
check 'NOPE' for some of these normative terms, but they already have
plans to change that in the upcoming weeks.

An '??' can mean that I didn't have the time to figure it out, don't
understand the text, or don't understand the code. :-)

Report - 2020-06-23 OpenBSD rpki-client 6.7-current || Stephen Kent's text
 
....an RP MUST ignore the data associated with the publication point ......: rpki-client OK
....all signed objects associated with the CA instance MUST be ignored ....: rpki-client OK
...signed objects associated with the CA instance MUST be ignored, because : rpki-client OK
....an RP MUST perform a series of tests to determine which signed object .: rpki-client OK
..._All_ of the files referenced by the manifest MUST be located at the ...: rpki-client OK
...the same publication point, an RP MUST *???* ...........................: rpki-client ??
...A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be ...: rpki-client OK
....and matches the CRLDP, the first one encountered MUST be used .........: rpki-client ??
...Any other .crl files MUST be ignored and a warning MUST be issued ......: rpki-client OK
..an RP SHOULD examine the most recent cached manifest ....................: rpki-client OK
...no access to a current manifest, processing stops and a warning MUST ...: rpki-client OK
...the RP SHOULD examine its cache to determine if these files ............: rpki-client OK
....the RP SHOULD use the cached files to replace those missing ...........: rpki-client OK
....then an RP SHOULD examine its local cache to determine ................: rpki-client OK
...The RP SHOULD use cached files to replace any ..........................: rpki-client OK
...then the out-of-scope entries MUST be disregarded ......................: rpki-client OK
...certificates (CA and EE) MUST be considered invalid ....................: rpki-client OK
..the RP MUST not try to acquire and validate _subordinate_ signed objects.: rpki-client OK

If you develop RP software, please produce a similar report and share it
with sidrops@ietf.org. We share implementation reports in IDR, and often
this turns out to be a very valuable ritual.

Kind regards,

Job