Re: [OPSAWG] Finding and Using Geofeed Data

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 12 September 2020 23:21 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22183A0E96 for <opsawg@ietfa.amsl.com>; Sat, 12 Sep 2020 16:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 qjfUucMdeYFg for <opsawg@ietfa.amsl.com>; Sat, 12 Sep 2020 16:21:50 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1633F3A0BA3 for <opsawg@ietf.org>; Sat, 12 Sep 2020 16:21:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 083F4389B2; Sat, 12 Sep 2020 18:42:52 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iSclAbbCvvGd; Sat, 12 Sep 2020 18:42:46 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id B3137389B1; Sat, 12 Sep 2020 18:42:46 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4204C5E; Sat, 12 Sep 2020 19:04:00 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Randy Bush <randy@psg.com>, Massimo Candela <massimo@us.ntt.net>, opsawg@ietf.org
In-Reply-To: <m25z8kdoqb.wl-randy@psg.com>
References: <8450cc78-8c60-ff7a-19f5-ea7335d262cd@us.ntt.net> <m25z8kdoqb.wl-randy@psg.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 12 Sep 2020 19:04:00 -0400
Message-ID: <4685.1599951840@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/p-trFmQD4J5OMdjniQucnnrdJtk>
Subject: Re: [OPSAWG] Finding and Using Geofeed Data
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Sep 2020 23:21:53 -0000

>   Identifying the private key associated with the certificate, and
>   getting the department with the HSM to sign the CMS blob is left as
>   an exercise for the implementor.

This cynical comment jumped out at me.
It seems that you don't have a lot of confidence that the key will be easily used.

As I understand it, you are not creating the geofeed: attribute, but instead
shoving a URL into a "remark".  (Wasn't JCL afflicted by endless hacks like this?)
(I don't see an IANA Considerations in RFC2622... so many you have to Updates?)

I gather from my quick reading that the geofeed data should be signed by the
same RPKI key, and that such keys are rather high value.
Should they be signing geofeed data?

I understand RFC8805 to be a simple CSV format.
One thought I have is to just stuff that into the "remark" directly.
I think that each inetnum:/inet6num: entry will be unique per prefix.
Maybe the geography is not 1:1, particularly with larger IPv6 allocations.

But, if the HTTP(S) indirection via URL requires a signature from the same
key as the RPSL signature, then why not just put a SHA256 hash into the
remark, eliminating the need to find the private key?
That way, the same person with access signs both?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide