Change Publication Server used by an RPKI CA

Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Introduction There are a number of reasons why a CA may wish to migrate from its current Publication Server to a new one. One reason may be that an organisation is running their own Publication Server, but they wish to migrate to a server operated by their parent (e.g. a Regional Internet Registry). Possibly because their parent did not offer this service when they first set up their CA, but now they do. Another reason may be that the current Publication Server used by a CA is failing behind in terms of their availability on either the publication protocol , or the public rsync or RRDP repository compared to other options. If the current Publication Server has become unavailable, and there is no sign that it will become available again, then that may constitute an even more urgent reason to migrate to a new server. In this document we explain how Krill, an RPKI CA and Publication Server implementation, currently uses a modified RPKI Key Rollover process to allow a CA to change the Publication Server used.

Migration Process

Upload new Repository Response The migration to a new Publication Server is initiated by uploading a new Repository Response XML for that new server. When the XML is uploaded the CA verifies that it can communicate with the new server by sending it an list query. If the query is successful, the new server is accepted and the CA proceeds to the next step.

Create new Key The second step in the process is that the CA generates a new key pair, and then requests a new certificate for this key from its parent (using [!@RFC6492]). The Certificate Sign Request for this new key uses the URIs that pertain to the new Publication Server.

Manifest and CRL for new Key When the CA receives a certificate for the new key, which uses the new Publication Server, it generates a CRL and Manifest and publishes these at the new server. RPKI signed objects such as ROAs or possibly CA certificates for its own children are only published under the "current" key. I.e. they are not yet published at the new server. This is similar to step 3 in the CA Key Rollover Procedure defined in section 2 of [!@RFC6489].

Staging Period According to step 4, in section 2 of [!@RFC6489] a staging period of at least 24 hours SHOULD be used. The current implementation in Krill leaves this decision to the operators. A shorter period is advisable if the current Publication Server is unavailable.

Activate new Key When the new key is activated all RPKI signed objects are published under the new key, and therefore published at the new Publication Server, and they are removed from the current key's manifest and publication point. This is essentially the same as defined in step 5 of section 2 of [!@RFC6489], except that keys use a different Publication Servers and they will typically use a different "siabase" and "rrdpnotification_uri".

Revoke old Key The final step in the process is that the CA requests revocation of its, previously CURRENT, now OLD key. When this key is revoked the CA removes all content from the OLD publication server for this key.

Possible Improvements

AIA It should be noted that the AIA URIs for delegated CA certificates will change when the new repository is used, even if the child CA keys and subjects did not change, and even if the produced .cer files have the same name - they will be published in a different publication point. Relying Parties may warn when AIA URIs in the RPKI signed objects (Manifest, ROAs, etc) and possible certificates (delegated CA or BGPSec Router certificates) published do not match the location of the signing CA certificate in the new publication point, but they would accept them as long as they are otherwise valid.

Timing Issues One important thing to note is that the CA needs to publish in two different locations when the new key is activated in the process defined here. This can lead to timing issues where Relying Parties see equivalent objects under both keys. This happens if they get the NEW objects before seeing them disappear from the OLD key. This is not expected to lead to significant issues. On the other hand, it may also turn out that the Relying Party sees the objects disappear from under the OLD key, but it has not yet seen the equivalent objects under the NEW key. This can have a big impact. All ROAs would disappear temporarily which could impact routing even if announcements would fall back to the ROV state "Not Found" (). But, any delegated CA certificates would also disappear (temporarily) and as a consequence any ROAs or other objects published by children. So, if this happens to a CA near the top of the RPKI tree the impact can be quite significant. For this reason we may want to change the "Activate Key" step to use three separate steps:

publish objects under the NEW key,
enter a staging period
only then remove the objects from the (now OLD) key

Duplication? If we would use the staging period mentioned in the previous section, then Relying Parties will find any possible delegated CA certificates under both publication points for some time. Both CA certificates will use the same subject key and SIA values. Therefore, Relying Parties will find the published objects under two paths - and they will appear valid under both. This will cause RPs to keep more data. This is not expected to be a huge issue.. as any duplicated Validated ROA Prefixes would be filtered out in the RPKI-RTR protocol ().

IANA Considerations OID needs to be requested.

Security Considerations TBD

Acknowledgements TBD