Re: [OPSAWG] Finding and Using Geofeed Data

[Randy Bush <[e-mail]>]

>> 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.

actually, i am hoping that ggm et alia will revive
draft-michaelson-rpki-rta

until then, i am personally not all that concerned about signing.  as
folk start to actually follow this path (and massimo is keeping a list
of those who are), after a while folk may care enough about authenticity
to go through the effort of signing geofeeds.

but we felt it incumbent on us to specify how to do so.

> As I understand it, you are not creating the geofeed: attribute, but
> instead shoving a URL into a "remark".

one thing at a time.  the ietf gave up on specifying rpsl a couple of
decades ago.  a first task i was given as a new ops area director was
to shoot the rps wg.  so we are not attempting to modify rpsl, though
we do suggest how it might be done.

> I don't see an IANA Considerations in RFC2622... so many you have to
> Updates?

let's you and them fight :)

> 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?

got any other congruent authoritative keys?

> I understand RFC8805 to be a simple CSV format.
> One thought I have is to just stuff that into the "remark" directly.

scale issues.  as i just said on nanog

    for some flat fan out last kilometer providers that could be the
    inetnum: object from hell.  there are global providers which segment
    large prefixes over diverse areas.  etc.

    i doubt the rpsl providers would like multi-megabyte inetnum:s.  rpsl
    providers already throttle in defense.

> I think that each inetnum:/inet6num: entry will be unique per prefix.
> Maybe the geography is not 1:1, particularly with larger IPv6
> allocations.

it isn't even for ipv4

> But, if the HTTP(S) indirection via URL requires a signature from the
> same key as the RPSL signature

there is no such thing as an rpsl signature.  and i sure as bleep ain't
gonna propose one.

> 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?

because, as the draft tries to politely say

    Unfortunately the RPSL in many repositories is weakly authenticated
    at best.

randy