| Internet-Draft | Change Publication Server | September 2025 |
| Bruijnzeels, et al. | Expires 19 March 2026 | [Page] |
This document outlines how an RPKI CA can migrate from one RFC 8181 Publication Server to another. The process is similar to the RPKI CA Key Rollover process defined in RFC 6489, except that in this case a new location is used for the new key.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 March 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 organization is running their own Publication Server, but wishes 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 falling behind in terms of their availability on either the publication protocol [RFC8181], or the public rsync or RRDP [RFC8182] 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.¶
This document describes a modified RPKI Key Rollover [RFC6489] process that can be used to change the Publication Server used by an RPKI CA.¶
This section assumes familiarity with RPKI Key Rollovers [RFC6489].¶
The migration process is similar to the process described in section 2 of [RFC6489] with some notable differences that we will describe below.¶
This document uses the three CA states CURRENT, NEW and OLD as described in section 2 of [RFC6489].¶
Before initiating the Publication Server migration the relationship between the publishing CA and the new server MUST be estiblished and verified.¶
First, a Publisher Request XML file MUST be retrieved from the CA. The CA MAY re-use the same XML and BPKI TA certificate that was used for the setup of the current Publication Server for this purpose.¶
Then, the Publication Server MAY generate a Repository Response XML file for this CA. If the Publication Server refuses to execute this step, then the migration MUST be cancelled.¶
When the CA receives the Respository Response XML file it MUST verify that it can communicate with the new server by sending it an [RFC8181] list query. If the query is successful, the new server is accepted and the CA proceeds to the next step. If the query is unsuccessful then the migration process MUST be cancelled.¶
The second step in the process is to generate a key pair for the NEW CA, and then request a new certificate for it from its parent as described in steps 1 and 2 in section 2 of [RFC6489].¶
The NEW CA MUST reissue all signed certificates and RPKI signed objects as described in section 4 of [RFC6489] and publish them at its (new) Publication Server.¶
This is necessary because if the NEW CA were to delay re-issuance and publication until it is promoted to become the CURRENT CA and the then OLD CA is revoked immediately as described in steps 3-6 in section 2 of [RFC6489], then this would lead to a situation where no certificates and RPKI signed objects could be found by RP software due to timing issues in fetching both repositories. This issue does not apply to the normal [RFC6489] Key Rollover process as all the updates would be published at the same Publication Server in that case as a single atomic delta.¶
During the staging period the CA MUST maintain signed content under both its current and new key, and MUST ensure that these are in sync.¶
A staging period of 24 hours SHOULD be used to avoid any race conditions where RP software was not yet able to get the content from the NEW CA repository before revoking the CURRENT CA as per the next step in this process.¶
However, if there is any operational issue with the Publication Server and/or its repository used by the CURRENT CA then this staging period SHOULD be skipped.¶
After the staging period has passed, or has been skipped, the CURRENT CA becomes the OLD CA and NEW CA becomes the CURRENT CA.¶
The final step in the process is that the OLD CA MUST be revoked by sending an [RFC6492] revocation request for its key. Furthermore, all content for the OLD CA SHOULD be removed from the (old) Publication Server used by it. Note that this may be impossible in cases where a non-functioning Publication Server prompted this migration.¶
The private key for the OLD CA MUST be destroyed.¶
This section is to be removed if and before this document becomes an RFC.¶
Version -00 of this document is implemented by [krill] release 0.9.2 and later.¶
OID needs to be requested.¶
TBD¶