Kyle:
> This document appears to propose overlapping mechanisms for
> establishment of trust in geofeed data. As far as I can tell, geofeed
> data may be authenticated both by:
>
> * RPKI private key signature of a digest of a canonicalized form of the
> geofeed data file. * Web PKI via https URL for geofeed data file.
not exactly.
the web pki has no authority over IP address space ownership.
Understood. I'm not suggesting the web PKI be used to authenticate IP address space ownership. I'm suggesting that the following chain would be sufficient:
* RPKI authenticates the routing information, which includes the IP address space and the https URLs for each geofeed file. * Web PKI authenticates the data served at that URL. * Client verifies that the IP ranges in the geofeed data are contained within the (RPKI-authenticated) routing information.
This is not quite right. It is true that theWebPKI provide authentication and integrity when https:// is used, but this is not required. If http:// were used, and the file was modified in transit by an attacker, the RPKI signature check would fail.
I.e., you are chaining trust from the RPKI explicitly to the (https) URL, and implicitly to the data served from that URL. The web PKI is used only to ensure that the data is not modified in transit. It is not used to authorize IP address space ownership: regardless of the PKI used to authenticate the geofeed data, the client still needs to cross-check the IP ranges in the geofeed data against the ownership in the RPKI-authenticated routing information.
My point is that there is no chaining of trust.
Russ
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
