On 10 Sep 2021, at 11:57, Job Snijders <job@fastly.com> wrote:
On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
I think all would agree that transparency is good.
A key difference between RPKI and most other PKIs is that in the RPKI all objects are published in the open for all the see.
Small nitpick: all objects are SUPPOSED to be published, in the open, for all to see. However it is important to keep in mind we cannot assume all objects were published in a way for all to see.
As you mentioned your RPKI validator may miss intermediate state changes if it retrieves objects using rsync, but the RRDP protocol supports deltas, see [1].
I believe that transparency can most easily be achieved by ensuring that these deltas are preserved, and that they cannot be modified.
RRDP is an unauthenticated and unsigned protocol. It is possible for a Publication Point to present different RRDP deltas to one RP compared to what they present to another RP. Archiving RRDP deltas is interesting, but IMHO happens too late in the pipeline for TA/CA audit purposes.
RRDP is not a replacement for Certificate Transparency, both technologies solve different problems.
I did not say that it was. I just suggested that *in the context of RPKI* RRDP can be used as a basis to keep track of all historic public changes. I think we can discuss, preferably in the IETF as well, how multiple parties can observe changes in RRDP repositories and report them to an append only historic record. A useful concept also used in CT. Paranoid (as they should be) RPKI validators would then be able to verify that the state that they see (notification/snaphot/deltas) matches what others have seen. The biggest advantage to an approach like this could also be applied on top of the existing infrastructure without requiring substantial changes in the stack. If you do not trust that the Publication Server (which serves RRDP) accurately reflects what the RPKI CAs asked to be published then you indeed have a different problem. CT logs could be one way to approach this, but I am not convinced yet that this is the only way or the best way. Also note that in case of RIPE NCC the CAs and Publication Server are controlled by the same organisation. Kind regards, Tim
Kind regards,
Job