Two weeks ago AFRINIC was placed under receivership by the Supreme Court of Mauritius. This event prompted me to rethink the RPKI trust model and associated risk surface.
The RPKI technology was designed to be versatile and flexible to accommodate a myriad of real-world deployment scenarios including multiple trust anchors existing, inter-registry transfers, multiple
transports, and permissionless innovation for signed objects, for example. All good and well … but ofcourse there is a fine print. 
Over the years various people have expressed astonishment about each RIR having issued so-called ‘all-resources’ (0.0.0.0/0 + ::/0) trust anchor certificates, but this aspect often is misunderstood: the risk is not necessarily in the listing of ‘all-resources’ itself, it is in the RIR being able to issue an ‘all-resources’ certificate in the first place. RPKI trust anchor operators indeed can voluntarily reduce the scope of subordinate Internet Number Resources, but just as easily increase the scope of their authority. In other words, a trust anchor cannot truly constrain itself.
Upon reconsideration on how exactly RPKI hooks into the real world; I concluded trust anchors do not require unbounded trust in order to provide constructive services in the realm of BGP routing security.
Some examples: ARIN does not support inter-RIR IPv6 transfers, so it would not make any sense to see a ROA subordinate to ARIN’s trust anchor covering RIPE-managed IPv6 space. Conversely, it wouldn’t make sense to observe a ROA covering ARIN-managed IPv6 space under APNIC’s, LACNIC’s, or RIPE’s trust anchor - even if a cryptographically valid certificate path existed. Along these lines AFRINIC doesn’t support inter-RIR transfers of any kind; and none of the RIRs have authority over private resources like 10.0.0.0/8 or AS 65535. It seems feasible to paint constraints around RPKI trust anchors in broad strokes.
Over the last two weeks I’ve diligently worked with Theo Buehler to research RIR transfer policies, untangle the history of the IANA->RIR and RIR->RIR allocation spaghetti, design & implement a maintainable constraints mechanism for rpki-client(8), and publicly document the concept of applying operator-defined policy to derived trust arcs.
Please take a moment to read
Your feedback is appreciated!
Kind regards,
Job