In the Resource Public Key Infrastructure (RPKI), each Regional Internet Registry (RIR) runs a separate Trust Anchor (TA). The TA is the Certification Authority (CA) for the RIR’s RPKI root certificate, from which all other resource certificates and objects issued by the RIR derive their validity.
Relying Parties (RPs) are typically configured with a set of Trust Anchor Locators (TALs), one for each RIR. The TAL contains the TA certificate’s URL, as well as its public key. These two values can be used by an RP to retrieve the TA certificate and confirm its validity by comparing the TA certificate’s key with that from the TAL.
TALs allow operators to reissue the TA certificate without requiring all RPs to update their configuration. While the URL and the key remain the same, RPs will retrieve and make use of the updated certificate. However, because RPs depend on the key being the same for retrieval to work, it’s not possible for a TA operator to change the key and have that change carry through to relying parties automatically with the current system.
This design creates a significant limitation. If an RIR wants to change the TA’s key, the TAL must also be changed. Because there is no mechanism for pushing new TALs to RPs, this change would require every RP to manually update its configuration. That means that it would likely take a long time for the new key to be universally adopted.
The main benefit of being able to reliably change keys is that RIRs gain greater operational flexibility in the management of the Hardware Security Modules (HSMs) used to manage those keys. For example, an HSM vendor may not support exporting keys to updated hardware, or to more cost-efficient hardware developed by a competitor.
The RIRs have been aware of this problem for some time and have been working jointly on a better key change process. That work was published late last year as RFC 9691: A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs). This specification defines a new object type that a TA operator can publish to signal its intent to transition to a new key.
When an RP observes that this new object is being used by the TA operator to transition to a new key, it sets a 30-day timer. If the object continues to be published as-is for the duration of the timer period, then the RP replaces its current TAL configuration for the TA with the new configuration from the object. From that point, it uses the updated configuration.
In addition to enabling key transitions within RP software, RFC 9691 can benefit TAL distributors more broadly. For example, distributors like Debian (see the rpki-trust-anchors package) can use the signed objects defined in RFC 9691 to verify the authenticity of TAL changes before distributing them. This means that even RPs that don’t directly implement RFC 9691 can still benefit indirectly in some cases, as they receive validated updates through these external sources.
Currently, the RIRs are investigating the work required to implement these objects as part of their broader activities under the NRO RPKI Program.
If you have feedback on this work, please contact rpki_program@nro.net or apnic-services@apnic.net.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.