>> 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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
