Re: [Sidrops] Test objects: ASPA and BGPSec Router Certificate

Tim Bruijnzeels <tim@nlnetlabs.nl> Sun, 24 July 2022 11:21 UTC

Return-Path: <tim@nlnetlabs.nl>
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 51F15C14F742 for <sidrops@ietfa.amsl.com>; Sun, 24 Jul 2022 04:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lRpvWV98f0z for <sidrops@ietfa.amsl.com>; Sun, 24 Jul 2022 04:21:51 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [185.233.34.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C64CC14F73D for <sidrops@ietf.org>; Sun, 24 Jul 2022 04:21:51 -0700 (PDT)
Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4LrLNW6WVFzFQ; Sun, 24 Jul 2022 11:21:47 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1658661707; bh=1v0YfC5OooKPi8T81E1j0hRqF/IKlXjY+LYNqMqWEwQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=A02owGcxR2LfvEdznTfFsjnVXndkLb/KcAgH+OtIn4YXFocAFxBEKuyWclc7pCNHi GNOCXtRznlyGUlVcwLgBAfyz+fF0H7OYvv86QEt6A4bqopawf84jWwgzMbMo3gF7XY rTvdTzfOaB7tfWauY07ccMKnxsiwpLdvQn60yA3+HlkXyl5h9UKpkUT2b5OxX97X/B YXLIvSdRIeBbrzy8QsM5AFuy9vsnSAlKmXDM76ES3KBQlmYQFKitnEXekOunuI5NEW KY2pOlNNReNP1ZX2uHM7UmXi3c8DATtF+y+pOFDKjq7f37yEClgL0Mvbbgw2pSWUKy yVxQps7KCvHSA==
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <YtvrhKb67lv4GVk+@snel>
Date: Sun, 24 Jul 2022 13:21:44 +0200
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5F017CF-BC18-43EE-92CE-38CD8E989D56@nlnetlabs.nl>
References: <DADDAAB3-109E-4B83-A54A-2AAF65E2FA62@nlnetlabs.nl> <YtvrhKb67lv4GVk+@snel>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/fpnMjew4mGYRxltQyFJ7Ziavdfo>
Subject: Re: [Sidrops] Test objects: ASPA and BGPSec Router Certificate
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 24 Jul 2022 11:21:56 -0000


> On 23 Jul 2022, at 14:37, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> Hi Tim,
> 
> On Fri, Jul 22, 2022 at 03:02:38PM +0200, Tim Bruijnzeels wrote:
> 
>> I just published a BGPSec Router Certificate and an ASPA
>> object under a test CA in our testbed. The CA uses the
>> following rsync base:
>> 
>> rsync://testbed.krill.cloud/repo/local-testbed-child/0/
>> 
>> The TAL for this testbed lives here:
>> https://testbed.krill.cloud/testbed.tal
> 
> There seems to be a logistical issue with the testbed:
> 
> The TAL file 'testbed.tal' references
> rsync://testbed.krill.cloud/ta/ta.cer, which in turn references
> rsync://testbed.krill.cloud/repo/ta/0/1EB6897DBC368F678703F36607DFAB5C89AE8CD7.mft,
> which does not exist:
> 
> $ rsync rsync://testbed.krill.cloud/repo/ta/0/1EB6897DBC368F678703F36607DFAB5C89AE8CD7.mft
> rsync: link_stat "/ta/0/1EB6897DBC368F678703F36607DFAB5C89AE8CD7.mft" (in repo) failed: No such file or directory (2)

Ah, oops.. the TA cert and TAL live outside of the normal set of objects that get
published. It requires a manual action that I forgot when I reset this environment
a while back.

That is now fixed, but I found another issue with the (release candidate) code
running here.. fixing..

> 
>> BGPSec:
>> -------
>> 
>> file: ROUTER-00033979-17316903F0671229E8808BA8E8AB0105FA915A07.cer
>> 
>> This is valid according to our own probing, but please let
>> me know if you find any issues with it.
> 
> The SIA extension of the EE cert in
> ROUTER-00033979-17316903F0671229E8808BA8E8AB0105FA915A07.cer is empty.
> 
> $ openssl x509 -in ./ROUTER-00033979-17316903F0671229E8808BA8E8AB0105FA915A07.cer -inform DER -text | grep -A1 'Subject Information'
>            Subject Information Access:
>                <EMPTY>
> 
> The empty SIA renders the BGPsec Router Key certificate invalid for two
> reasons:
> 
> 1/ Iff a SIA is present in an EE certificate, according to RFC 6487 §
>   4.8.8.2 it MUST have an instance of accessMethod of id-ad-signedObject.
> 
> 2/ Additionally, RFC 8209 § 3.3 states: "BGPsec Router Certificates MUST
>   NOT include the SIA extension."
> 
> I recommend testing with RPKI Cache Validator implementations known to
> support BGPsec Router Key validation (such as rpki-client).
> 
> Testing with multiple independent implementations helps improve
> interopability, and also  discover issues early in the development
> process when authoring a CA implementation.
> 
> Rpki-client's error log messages can be hard to interpret (my
> apologies!), however the absence of a BGPsec Router key in the validated
> JSON output might be a good hint something went wrong in producing a
> given cryptographic product.
> 

Sure thanks for the pointer. Will work on a fix and first try to test
it with rpki-client as well.

Tim


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