[routing-wg] request for feedback: a RPKI Certificate Transparency project?

Dear all,

With summer turning to fall in the Northern Hemisphere, yet again a new
schoolyear is ahead of us! :-) I hope you all are well.

I'm writing the group to solicit feedback for me and others to consider
during upcoming deliberations about activity plans, but even more so as
an RPKI enthusiast who is curious to learn what others see as potential
future evolutions of the RPKI technology stack.

[ TL;DR - Ask to the routing community: is there interest to coordinate
  and support an industry-wide project to introduce the principles of
  "Certificate Transparency" to the RPKI? The project size could be
  substantial, but so are the upsides. ]

Intro: global deployment & operation of the RPKI is a multi-decade project
==========================================================================

Over the last 21 years this industry has collectively helped grow and
nurture 'Secure BGP' [1] into the RPKI/BGP deployment as we know it
today: the smallest and largest of networks in the Default-Free Zone
core are anchoring their BGP routing decisions to a RPKI covering 31% of
space, which in turn helps connect billions of End Users to the
Internet.

>From my personal perspective [10], the RPKI has now reached some level
of maturity. Perhaps now is the time for some of our community's focus
to shift towards designing and implementing innovations on top of the
current RPKI, without jeopardizing its current plateau of stability.

What does trusting a Trust Anchor mean?
=======================================

Some people have (correctly!) pointed out that RPKI Trust Anchor (TA)
operators technically can issue certificates related to any Internet
Number Resource, a consequence of some people considering "all
resources" [5] being subordinate a necessity for day-to-day TA
operations. While I am aware of some minor concerns about the "all
resources" framework (and I personally see room for improvement!), for
me the big question is not "who do I trust?", but "what did they
actually do after I started trusting them?".

In this reality where RIRs can sign "everything" and I (as RP operator) can
cryptographically verify that what I observed through periodic polling
[6] was indeed signed by my locally configured Trust Anchor(s)... one
thing seems to be missing! I don't know anything about what my RP didn't
observe! :-) Perhaps some certificates were issued and very quickly
revoked concerning subordinate Internet Number Resources of great
importance to me? How would I know if I didn't see it myself?

I don't expect to trust Trust Anchor operators to never make any
mistakes, but I do wish to be in a position where I can assess past
performance, and can compare third-party audit logs, to inform my future
decisions! To me it seems important to increase our collective
visibility into TA/CA takes & mistakes. ("Mistakes" meaning the issuance
or revocation of certificates non-compliant with the policy outlined in
RIPE-751).

Most Internet Routing incidents are analyzed after-the-fact through the
use of Route Views [8], RIPE RIS [9], or information viewplayers like
BGPlay. Everyone being enabled to "scrub back in time" greatly enhances
our group's ability to understand what transpired and how to prevent it
going forward.

What is the RPKI equivalent of BGPlay at a cryptographicly auditable
level of detail? ... maybe Certificate Transparency? [7].

Copying good ideas from other PKIs: Certificate Transparency
============================================================

The RPKI is built on top of X.509 and CMS tech. Any developments in
other X.509 special interest communities (such as WebPKI [2], aka "the
https:// experts"), may be amazing ideas or methods worth copying into
'our Internet Number Resource PKI' ecosystem. 

One of the inventors [3] of public-key cryptography (a core concept in
the RPKI), also came up with an idea known as "Merkle Trees" [4]. This
concept can be used to construct inter-domain "append-only" logging
facilities, which can be incredibly useful to help increase trust in a
Trust Anchor in an "assumed trust" model. I'll try to explain why below!

A key concept in Certificate Transparency is that a CA ('the signer')
- ahead of time - shares with select third parties (so-called 'CT Logs')
their commitment to sign a given digital object. After acknowledgement
from the CT Log(s), the signer proceeds to sign and publish the RPKI
object. The CT Logs use Merkle Trees to allow external auditors to
'losslessly replay' all observations of certificate issuance from a
given CT Log, and compare CT Logs with each other.

Implementation of Certificate Transparency would provide this community
with something analogous to the RIPE Database "Historical Queries". The
major difference being all logged data comes with cryptographic
assurances, and the data can be hosted and audited by both RIPE NCC and
any third parties (anyone with Internet access!).

RIPE NCC sending precertificate information to CT Logs?
=======================================================

Would the community mind if RIPE NCC proactively shares to-be-signed
not-yet-public-but-soon-to-be-public information with third parties?

Are there any third parties (could be ISPs like you and me, or RIRs [13]
in other regions) who'd be willing to host and operate 24/7 available CT
Logs working with software such as Trillian [12]?

RIPE NCC as Certificate Transparency Log Operator for other RIRs?
=================================================================

RIPE NCC appears to have an impressive track record when it comes to
bootstrapping and maintaining 'impossible' multi-year projects which
improve "the commons". RIPE Atlas and RIPE RIS are projects only very
few organizations would've been able to pull off. Both RIS and Atlas
offer incredible value to both the RIPE community and the global
community. In my eyes an RPKI Certificate Transparency initiative would
align well with existing projects.

Bootstrapping and maintaining RPKI CT Logs (the open source software
design, subsequent IETF draft contributions, ongoing data processing and
archiving) will require significant investment. However, I do believe
there is an opportunity for RIPE NCC to serve the global Internet
community by offering RPKI CT Log services to any TA or CA in the RPKI.

Final thoughts
==============

Certificate Transparency is an open framework that can help detect
Signed Object trust threats, and brings increased oversight and openness
to the RPKI ecosystem.

Does the community see value in applying Certificate Transparency to the
RPKI? What are your thoughts?

Kind regards,

Job

[1]: https://ieeexplore.ieee.org/document/839934
[2]: https://cabforum.org/
[3]: https://en.wikipedia.org/wiki/Ralph_Merkle
[4]: https://iq.opengenus.org/merkle-tree/
[5]: https://datatracker.ietf.org/doc/html/draft-rir-rpki-allres-ta-app-statement
[6]: http://www.rpkiviews.org/
[7]: https://en.wikipedia.org/wiki/Certificate_Transparency
[8]: http://routeviews.org/
[9]: https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris
[10]: https://console.rpki-client.org/
[11]: https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis
[12]: https://github.com/google/trillian
[13]: https://www.arin.net/participate/community/acsp/suggestions/2021/2021-3/