RFC 6916

Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)

📅 published April 2013, from ietf

RFC 6916: Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) 🎀

Okay bestie, this is the RFC that tells us how the RPKI swaps to a new crypto algorithm set. It's a Best Current Practice (BCP 182), so it's the community's official "do it this way" doc, and it came out in April 2013. 💅

Written by R. Gagliano (Cisco Systems), S. Kent (BBN Technologies), and S. Turner (IECA, Inc.), published by the Internet Engineering Task Force (IETF). It's on the IETF track as a BCP, ISSN 2070-1721. Its header doesn't list anything it obsoletes or updates, so it's standing on its own. 🌸

Abstract ✨

Okay so this doc lays out the steps that Certification Authorities (CAs) and Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) need to follow to move to a new (and probably cryptographically stronger) algorithm set. 🦋 It's a multi-year glow-up, not a quick fix, so no emergency transition is specified. And the migration only goes top-down, meaning the parent migrates before the children. 👑

Status of This Memo ✨

This memo documents an Internet Best Current Practice. 🧚

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741. 💜

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6916. 🫶

Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) as they stood on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. ⚖️

Table of Contents ✨

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
4.  Key Rollover Steps for Algorithm Migration . . . . . . . . . .  6
  4.1.  Milestones Definition  . . . . . . . . . . . . . . . . . .  6
  4.2.  Process Overview . . . . . . . . . . . . . . . . . . . . .  7
  4.3.  Phase 0  . . . . . . . . . . . . . . . . . . . . . . . . .  9
    4.3.1.  Milestone 1  . . . . . . . . . . . . . . . . . . . . .  9
  4.4.  Phase 1  . . . . . . . . . . . . . . . . . . . . . . . . . 10
  4.5.  Phase 2  . . . . . . . . . . . . . . . . . . . . . . . . . 11
  4.6.  Phase 3  . . . . . . . . . . . . . . . . . . . . . . . . . 12
  4.7.  Phase 4  . . . . . . . . . . . . . . . . . . . . . . . . . 13
  4.8.  Return to Phase 0  . . . . . . . . . . . . . . . . . . . . 14
5.  Support for Multiple Algorithms in the RPKI Provisioning
    Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.  Validation of Multiple Instances of Signed Products  . . . . . 15
7.  Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.  Key Rollover . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.  Repository Structure . . . . . . . . . . . . . . . . . . . . . 17
10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 17
11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Normative References . . . . . . . . . . . . . . . . . . . . . 19

1. Introduction ✨

Okay so the RPKI has to handle public keys changing over time. Certification Authorities (CAs) swap their keys all the time, and that's called "key rollover". 🔄 These changes are planned, and they happen all through the life of the RPKI, with each CA changing its keys on its own schedule. "Non-coordinated" just means each CA picks its own timing locally, not in sync with the rest of the RPKI. 🌈

And ngl, a key change might be forced by a suspected private key compromise, so you can never assume all the CAs in the RPKI will coordinate these events. 😭 In an emergency key rollover, the old certificate gets revoked and a brand new certificate with a brand new key gets issued. The mechanisms for a key rollover (planned or emergency) that keep the same algorithm suite are covered in [RFC6489]. 💅

This document is about the key rollover that happens because the signature algorithm suite is changing. It lays out the process that CAs and Relying Parties (RPs) in the RPKI need to follow to move to a new (and probably cryptographically stronger) algorithm set. ✨ The whole thing is expected to take months or years, so no emergency transition is specified. The procedure only supports a top-down migration (parent migrates before children). 👑

Quick vocab check: a signature-algorithm suite is a signature algorithm (with a specified key size range) paired with a one-way hash algorithm. 🔐 The RPKI will probably need updated key sizes and/or different suites over time. This doc treats swapping in a new hash algorithm while keeping the current signature algorithm as an algorithm migration too, and it requires the CA to change its key. Migrating to a new suite is needed to keep crypto security at an acceptable level and to protect the integrity of certificates, Certificate Revocation Lists (CRLs), and signed objects in the RPKI. 🛡️

Here's the tea: all the RPKI data structures already name the signature and hash algorithms they use, but experience has shown that having algorithm IDs isn't enough to actually migrate (that's called algorithm agility). 🫠 Protocols, infrastructure elements, and operational procedures also have to handle the switch from one suite to another. Algorithm migration is super rare, and it needs a "current" and a "next" suite running side by side for a long stretch, probably several years. 🦋

This document defines how RPKI entities carry out a planned CA key rollover when the algorithm suite changes. It covers what CAs, repository operators, and RPs each do, and it describes the behaviour required of both CAs and RPs so these key changes actually work in the RPKI context, including how the RPKI repository system supports the key rollover. 🧚

Not to be dramatic, but this doc doesn't specify any algorithm suite itself. The RPKI Certificate Policy (CP) [RFC6484] requires CAs and RPs to use the algorithms defined in [RFC6485]. When an algorithm transition starts, [RFC6485] MUST be updated (as defined in Section 4.1 of this document) to redefine the algorithms that compliant RPKI CAs and RPs require under the CP. The CP won't change as a side effect of an algorithm transition, so the policy OID in RPKI certificates stays the same. 🆔

For each algorithm transition, a separate document (the algorithm transition timetable) MUST be published as a BCP to set the dates for each milestone in this document. 📅 It sets the phase-transition dates consistent with the descriptions in Section 4, and it explains how the RPKI community will measure whether CAs and RPs are ready to move into each phase. CAs publish certificates, CRLs, and other signed objects under the new algorithm suite as the transition goes on. That gives everyone visibility into how the new suite is rolling out, so the community can check progress. ✅ The transition procedure also lets CAs remove old certificates, CRLs, and signed products after the twilight date, which makes it possible to watch the old suite get phased out. So the phases in this doc help the community track how the transition is going. The timetable document will also describe how to amend the timetable if problems come up while implementing later phases. 🔧 It is RECOMMENDED that the timetable document be developed by representatives of the RPKI community, e.g., IANA, Internet Registries, and network operators. 🌸

2. Requirements Notation ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "NOT RECOMMENDED" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🌈✨

3. Terminology 🎀

okay so bestie, this doc assumes you already know the terms from "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and "A Profile for Resource Certificate Repository Structure" [RFC6481]. Extra terms for the examples are listed below 💅

Algorithm migration: A planned transition from one signature and hash algorithm to a new signature and hash algorithm. 🦋

Algorithm Suite A: The "current" algorithm suite used for hashing and signing. It shows up in the examples in this document. 🌸

Algorithm Suite B: The "next" algorithm suite used for hashing and signing. It also shows up in the examples. ✨

CA X: The CA that issued CA Y's certificate (so CA Y's parent). Used in the examples. 👑

CA Y: The non-leaf CA. Used in the examples. 🧚

CA Z: A CA that is a "child" of CA Y. Used in the examples. 🍓

Correspond: this one is a whole mood 😭 Two certificates issued under different algorithm suites correspond if they're issued to the same entity by the same CA and they bind identical Internet Number Resources (INRs) to that entity. Two CRLs correspond if they're issued by the same CA and list corresponding certificates. Two signed objects (other than manifests) correspond if they're verified using corresponding end-entity (EE) certificates and they contain the same encapsulated Context Info field. Two manifests correspond if they cover corresponding certificates, Route Origination Authorizations (ROAs), CRLs, and other signed objects. (The term "equivalent" gets used the same way when we're talking about RPKI signed products.) 💖

Leaf CA: A CA that only issues EE certificates. 🌈

Non-Leaf CA: A CA that issues certificates to other CAs. 🫶

PoP (proof of possession): Running a protocol that shows an issuer that a subject asking for a certificate actually has the private key that matches the public key in the certificate request they sent. 🔑

ROA: Route Origination Authorization, as defined in [RFC6482]. 🌸

Signed product set (also called set or product set): A group of certificates, signed objects, a CRL, and a manifest that belong together because they can all be verified under the same parent CA certificate. 💜

4. Key Rollover Steps for Algorithm Migration ✨

the "current" RPKI algorithm suite (Suite A) is defined in the RPKI CP document, which points to [RFC6485]. when it's time to migrate the RPKI algorithm suite, the very first step MUST be updating [RFC6485] to define the new algorithm suite. the algorithm transition timeline document MUST also get published (as a BCP) so everyone knows the dates for the milestones in the transition, which Section 4.1 covers. the community needs to be in the loop, bestie 📣

4.1. Milestones Definition 📅

CA Ready Algorithm B Date: After this date, all non-leaf CAs MUST be ready to handle a request from a child CA to issue a certificate under Algorithm Suite B. Any CA publishing an [RFC6490] Trust Anchor Locator (TAL) for Algorithm Suite A MUST also publish the matching TAL for Algorithm Suite B. 🫶

CA Go Algorithm B Date: After this date, all CAs MUST have reissued all of their signed product sets under Algorithm Suite B. 🚀

RP Ready Algorithm B Date: After this date, all RPs MUST be prepared to process signed material issued under Algorithm Suite B. 🧠

Twilight Date: After this date, a CA MAY stop issuing signed products under Algorithm Suite A. Also, after this date, an RP MAY stop validating signed materials issued under Algorithm Suite A. 🌅

End-Of-Life (EOL) Date: After this date, Algorithm Suite A MUST be deprecated using the process in Section 10, and every Algorithm Suite A TAL MUST be removed from its publication point. this is the big finale 💀🎀

4.2. Process Overview 🗺️

the migration process here is a series of steps that MUST be run in chronological order by CAs and RPs. the only milestone where CAs and RPs both take action at the same time is the EOL Date. because the RPKI infrastructure is decentralized, an algorithm transition is expected to take several years. it's a marathon, not a sprint 🏃‍♀️💨

to make the transition easier, CAs will start issuing certificates using Algorithm B in a hierarchical, top-down order. in our example, CA Y will only issue certificates under Algorithm Suite B after CA X has started doing so (CA Y Ready Algorithm B Date > CA X Ready Algorithm B Date). this ordering avoids issuing "mixed" suite CA certificates, like a CA certificate signed with Suite A that contains a Suite B key. in the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key that corresponds to an algorithm suite different from the one used to sign that certificate. (X.509 does allow mixed algorithm certificates, but this process skips using that capability.) a non-top-down approach would need those mixed-mode certificates and would lead to exponential growth of the RPKI repository, which is giving chaos 😵‍💫 also, because the RPKI CP mandates PoP for certificate requests, a CA can't request a certificate for Algorithm Suite B until its parent CA supports that suite. (See Section 5 for more details.) 🔍

the algorithm agility model here doesn't stop a CA from issuing an EE certificate with a subject public key from a different algorithm suite, as long as that certificate isn't used to verify repository objects. this exception to the mixed suite rule is okay because an EE certificate that isn't used to verify repository objects doesn't get in the way of RPs downloading and verifying repository content. like we said above, every CA in the RPKI is required to perform a PoP check on the subject public key when issuing a certificate. in general, a subject can't assume a CA can support a different algorithm. but if the subject is closely affiliated with the CA, it's reasonable to assume there are ways for the subject to find out whether the CA can support a request for an EE certificate with a specific, different public key algorithm. this document doesn't say how a subject can figure out whether a CA can issue a mixed suite EE certificate, because it expects those certificates to only show up where the subject and CA are closely affiliated (for example, an ISP issuing certificates to devices it manages). ISP x devices is very on brand 🛜✨

here's an overview of the process 🎀

Process for RPKI CAs:

  Phase 0    Phase 1   Phase 2             Phase 4  Phase 0
--x--------x---------x-------------------x--------x---------
  ^        ^         ^                   ^        ^
  |        |         |                   |        |
 (1)      (2)       (3)                 (5)      (6)

Process for RPKI RPs:

            Phase 0              Phase 3   Phase 4  Phase 0
-------------------------------x---------x--------x---------
  ^                            ^         ^        ^
  |                            |         |        |
 (1)                          (4)       (5)      (6)

(1) RPKI algorithm document is updated, and the algorithm transition timeline document is issued 📝 (2) CA Ready Algorithm B Date 🫶 (3) CA Go Algorithm B Date 🚀 (4) RP Ready Algorithm B Date 🧠 (5) Twilight Date 🌅 (6) End-Of-Life (EOL) Date 💀

each of these milestones gets its own moment in the next section, where we walk through every phase of the transition 💅

there are two situations that can make us pause or roll back the transition. the first one happens if the RPKI community isn't ready to make the switch. for example, lots of CAs might not be set up to issue signed products under Suite B, or lots of RPs might not be ready to process Suite B products. in that case, the timetable MUST be reissued, which postpones the date for that phase and pushes back the dates for later phases. the other situation is if serious concerns come up during the transition about the security of the Suite B algorithms. those concerns would be a reason to end the transition and roll back signed products, meaning go back to Suite A. in that case, the timetable MUST be republished, and the RPKI algorithm document MUST be superseded. the phase descriptions below mention these two situations where it makes sense 🚨

4.3. Phase 0 🌸

Phase 0 is the steady-state phase of the process. the whole time we're in this phase, Algorithm Suite A is the only supported algorithm suite in the RPKI. Phase 0 is also the steady state for the RPKI, so it's just life as usual 😌

during Phase 0, CAs X, Y, and Z are required to generate signed product sets using only Algorithm Suite A. RPs are also required to validate signed product sets issued using only Algorithm Suite A. no surprises, just vibes 🧘‍♀️

the next figure shows what the structure of signed objects in the repository looks like. it shows which algorithm suites are in use and how the three CAs (X, Y, and Z) form a certification chain. objects that line up vertically were signed by the same CA using the same private key. the different horizontal indentation also shows different publication points for objects signed by different CAs. the characters "|->" are just there to help visualize both the signing relationship and the publication point change. for example, CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A, and CA-X-Signed-Objects-Algorithm-Suite-A are all signed using the private key that goes with CA-X-Certificate-Algorithm-Suite-A, and they're all published at CA X's publication point 🗂️🦋

CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
        |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
                        |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                        |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                |-> CA-Y-Signed-Objects-Algorithm-Suite-A
        |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
        |-> CA-X-Signed-Objects-Algorithm-Suite-A

Note: Cert-XA represents the certificate for CA X, which is signed using Algorithm Suite A. 📌

4.3.1. Milestone 1 🚀

okay so the first milestone is the one that kicks off the whole migration, bestie 💅 It updates [RFC6485] with the following definitions for the RPKI:

  • Algorithm Suite A
  • Algorithm Suite B

Additionally, the new algorithm transition timeline document MUST be published with the following information:

  • CA Ready Algorithm B Date
  • CA Go Algorithm B Date
  • RP Ready Algorithm B Date
  • Twilight Date
  • EOL Date
  • Readiness metrics for CAs and RPs in each phase

Each date specified here is assumed to be at one minute after midnight, UTC. No finer granularity time specification is required or supported. ⏰🦋

4.4. Phase 1 ✨

Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all non-leaf CAs MUST be ready to process a request from a child CA to issue or revoke a certificate using Algorithm Suite B. If it is determined that a substantial number of CAs are not ready, the algorithm transition timeline document MUST be reissued, as noted in Section 4.2. However, CAs that are capable of issuing Suite B certificates may continue to do so, if requested by their child CAs. As this phase does not require any RPs to process signed objects under Suite B, and since Suite B product sets SHOULD be stored at independent publication points, there is no adverse impact on RPs. If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, and Algorithm Suite B MUST be deprecated using the process described in Section 10. 🙈

Because the transition will happen using a hierarchical, top-down model, a child CA will be able to issue certificates using Algorithm Suite B only after its parent CA has issued its own. The RPKI provisioning protocol can identify if a parent CA is capable of issuing certificates using Algorithm Suite B and can identify the corresponding algorithm suite in each Certificate Signing Request (CSR; see Section 5). During much of this phase, the Suite B product tree will be incomplete, i.e., not all CAs will have issued products under Suite B. Thus, for production purposes, RPs MUST fetch and validate only Suite A products. Suite B products should be fetched and processed only for testing purposes. 🧪

The following figure shows the status of repository entries for the three example CAs during this phase. Two distinct certificate chains are maintained, and CA Z has not yet requested any material using Algorithm Suite B.

CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
        |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
                        |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                        |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                |-> CA-Y-Signed-Objects-Algorithm-Suite-A
        |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
        |-> CA-X-Signed-Objects-Algorithm-Suite-A

CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
        |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
                |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
                |-> CA-Y-Signed-Objects-Algorithm-Suite-B
        |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
        |-> CA-X-Signed-Objects-Algorithm-Suite-B

4.5. Phase 2 🌈

Phase 2 starts at the CA Go Algorithm B Date. At the start of this phase, each signed product set MUST be available using both Algorithm Suite A and Algorithm Suite B. Thus, prior to the start of this phase, every CA MUST ensure that there is a Suite B product corresponding to each Suite A product that the CA has issued. Throughout this phase, each CA MUST maintain this correspondence. During this phase, RPs MUST be prepared to validate sets issued using Algorithm Suite A and MAY be prepared to validate sets issued using the Algorithm Suite B.

If it is determined that a substantial number of CAs are not ready, the algorithm transition timeline document MUST be reissued, as noted in Section 4.2. (Since the processing requirement for RPs here is a MAY, if RPs have problems with Suite B products, this does not require pushing back the Phase 2 milestone, but it does motivate delaying the start of Phase 3.) CAs that are capable of publishing products under Suite B MAY continue to do so. Phase 2, like Phase 1, does not require any RPs to process signed objects under Suite B. Also, Suite B products SHOULD be stored at independent publication points so that there is no adverse impact on RPs that are not prepared to process Suite B products. (See Section 9 for additional details.) If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, and Algorithm Suite B MUST be deprecated using the process described in Section 10. 💅

It is RECOMMENDED that RPs that can process Algorithm Suite B fetch and validate Suite B products. RPs that are not ready to process Suite B products MUST continue to make use of Suite A products. An RP that elects to validate signed product sets using both Algorithm Suite A and Algorithm Suite B should expect the same results. If there are discrepancies when evaluating corresponding signed product sets, successful validation of either product set is acceptable. A detailed analysis of the validation of multiple instances of signed objects is included in Section 6. 🧠

The following figure shows the status of the repository entries for the three example CAs throughout this phase, where all signed objects are available using both algorithm suites.

CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
        |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
                        |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                        |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                |-> CA-Y-Signed-Objects-Algorithm-Suite-A
        |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
        |-> CA-X-Signed-Objects-Algorithm-Suite-A

CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
        |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
                |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
                        |-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB)
                        |-> CA-Z-Signed-Objects-Algorithm-Suite-B
                |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
                |-> CA-Y-Signed-Objects-Algorithm-Suite-B
        |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
        |-> CA-X-Signed-Objects-Algorithm-Suite-B

4.6. Phase 3 🦋

Phase 3 starts at the RP Ready Algorithm B Date. During this phase, all signed product sets are available using both algorithm suites, and all RPs MUST be able to validate them. (The correspondence between Suite A and Suite B products was required for Phase 2 and was maintained throughout that phase. The same requirements apply throughout this phase.) It is RECOMMENDED that, in preparation for Phase 4, RPs retrieve and process Suite B product sets first and treat them as the preferred product sets for validation throughout this phase. Thus, an RP SHOULD try to validate the sets of signed products retrieved from the Algorithm Suite B repository first. 🎀

If a substantial number of RPs are unable to process product sets signed with Suite B, the algorithm transition timeline document MUST be reissued, pushing back the date for this and later milestones, as discussed in Section 4.2. Since the Suite B products SHOULD be published at distinct publication points, RPs that cannot process Suite B products can be expected to revert to the Suite A products that still exist. If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced and Algorithm Suite B MUST be deprecated using the process described in Section 10.

There are no changes to the CA behavior throughout this phase. 🫶

4.7. Phase 4 🔥

Phase 4 starts at the Twilight Date. At that date, Algorithm A is labeled as "old" and the Algorithm B is labeled as "current".

During this phase, all signed product sets MUST be issued using Algorithm Suite B and MAY be issued using Algorithm Suite A. All signed products sets issued using Suite B MUST be published at their corresponding publication points. Signed products sets issued using Suite A might not be available at their corresponding publication points. Every RP MUST validate signed product sets using Suite B. RPs MAY validate signed product sets using Suite A. However, RPs SHOULD NOT assume that the collection of Suite A product sets is complete. Thus, RPs SHOULD make use of only Suite B products sets. (See Section 6 for further details.) 👑

If it is determined that many RPs are not capable of processing the new algorithm suite, the algorithm transition timeline document MUST be reissued, pushing back the date for this and the next milestone. The document MUST require the CA not to remove Suite A product sets if this phase is delayed. If Algorithm Suite B is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, Algorithm Suite B MUST be deprecated using the process described in Section 10, and CAs MUST NOT remove Suite A product sets. At this stage, RPs are still capable of processing Suite A signed products, so the RPKI is still viable. 🌸

The following figure describes a possible status for the repositories of the example CAs.

CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
        |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                |-> CA-Y-Signed-Objects-Algorithm-Suite-A
        |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
        |-> CA-X-Signed-Objects-Algorithm-Suite-A

CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
        |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
                |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
                        |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB)
                        |-> CA-Z-Signed-Objects-Algorithm-Suite-B
                |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB)
                |-> CA-Y-Signed-Objects-Algorithm-Suite-B
        |-> CA-X-CRL-Algorithm-Suite-A (CRL-XB)
        |-> CA-X-Signed-Objects-Algorithm-Suite-B

4.8. Return to Phase 0 💜

The EOL Date triggers the return to Phase 0 (steady state). At this point, the old algorithm suite, Algorithm Suite A, MUST be deprecated using the process described in Section 10.

This phase closes the loop, as the new algorithm suite (Algorithm Suite B) is now the only required algorithm suite in RPKI. From this point forward, this suite is referred to as Algorithm Suite A. ✨

If it is determined that many RPs are not capable of processing the new algorithm suite, the algorithm transition timeline document MUST be reissued, pushing back the date for this milestone. 🧚

5. Support for Multiple Algorithms in the RPKI Provisioning Protocol ✨

okay so the migration in this doc is a top-down process, and two syncing problems have to get solved between child and parent CAs 🫶

  • a child CA needs to figure out which algorithm suites its parent CA supports 💅
  • a child CA needs to signal which algorithm suite the parent should use to sign a CSR 🎀

the RPKI provisioning protocol [RFC6492] handles multiple algorithm suites by setting up a different resource class for each suite. and several resource classes can also use the same suite for different resource sets, which is lowkey so clever 🧚

a child CA that wants to find out which suites its parent supports MUST do these tasks:

  1. set up a provisioning protocol session with its parent CA 💖
  2. run a "list" command like it's described in Section 3.3.1 of [RFC6492] 🌸
  3. from the Payload in the "list response" resource class, pull out the "issuer's certificate" for each class. the suite for each class matches the suite used to issue that "issuer's certificate" (as spelled out in the SubjectPublicKeyInfo field of that certificate) ✨

a child CA that wants to tell its parent which algorithm suite to use (like in a certificate request) MUST do these tasks:

  1. do all the stuff above to figure out the suites the parent supports and the resource class for each suite 🦋
  2. name the matching resource class in the right provisioning protocol command (like "issue" or "revoke") 👑

when a parent CA gets a certificate request from a child CA, it's going to verify the PoP of the private key 🔐 if the child asks for a certificate under an algorithm suite that doesn't match any resource class, the PoP validation fails and the request just doesn't get performed. bestie, that's a hard no 💀

6. Validation of Multiple Instances of Signed Products 🌈

during Phases 1, 2, 3, and 4, two algorithm suites are valid at the same time in RPKI. this section is about how an RP should behave when it validates matching signed products made with different suites 🦋

during Phase 1, there MAY be two matching instances of each signed product, one signed under Algorithm Suite A and one under Algorithm Suite B. like we saw in Section 4.4, this phase has a preference for Suite A product sets. every product is available under Suite A, but only some are available under Suite B 💅 for production stuff, an RP MAY fetch and validate only Suite A products. Suite B products SHOULD only be fetched and validated for test purposes. when product sets exist under both suites, they should give equivalent results so testing is easier 🧪 (you can't directly compare Suite A and Suite B product sets, because the certificates, CRLs, and manifests will look syntactically different, ngl. but the output, meaning the ROA payloads (the Autonomous System number and address prefix data), SHOULD match, modulo timing issues 🙈)

during Phases 2 and 3, two matching instances of all signed products MUST be available to RPs. like we saw in Section 4.5, it is RECOMMENDED that Suite B capable RPs fetch and validate Suite B product sets during Phase 2 🔥 if an RP runs into validation problems with the Suite B products, it SHOULD go back to using Suite A products. RPs that are Suite B capable MAY fetch both product sets and compare the results (like the ROA outputs) for testing 🫶

in Phase 3, all RPs MUST be Suite B capable and MUST fetch Suite B product sets 👑 if an RP has problems with Suite B product sets, it can revert to Suite A products. RPs that hit those problems SHOULD contact the relevant repository maintainers (for example, using the mechanism defined in [RFC6493] to report problems.) 📣

during Phase 4, only Suite B product sets are required to be present for all RPKI entities, like we saw in Section 4.7 🌸 so RPs SHOULD retrieve and validate only these product sets. retrieving Suite A product sets may give an incomplete set of signed products, so it is NOT RECOMMENDED. not me getting an incomplete set 😭

7. Revocation 💜

the algorithm migration process requires keeping two parallel but equivalent certification hierarchies running during Phases 2 and 3. during these phases, a CA MUST revoke and request revocation of certificates consistently under both algorithm suites 🎀 when a CA isn't doing a key rollover operation (as described in Section 8), a CA that requests revocation of its certificate during these two phases MUST do that request for both algorithm suites (A and B). a non-leaf CA SHOULD NOT verify that its child CAs comply with this requirement 🙈 also, a CA MUST request revocation of its certificate relative to a specific algorithm suite using the mechanism described in Section 5

during Phase 1, a CA that revokes a certificate under Suite A SHOULD revoke the matching certificate under Suite B if that certificate exists. during Phase 4, a CA that revokes a certificate under Suite B SHOULD revoke the matching certificate under Suite A if that certificate exists ✨

during Phase 1, a CA MAY revoke certificates under Suite B without revoking them under Suite A, since the Suite B products are just for test purposes 🧪 during Phase 4, a CA MAY revoke certificates issued under Suite A without revoking them under Suite B, since Suite A products are being deprecated 👋

8. Key Rollover 🔑

key rollover (without algorithm changes) happens independently for each algorithm suite, and it MUST follow the process described in [RFC6489] 💖

9. Repository Structure 🗂️

the two parallel hierarchies that exist during the transition SHOULD have independent publication points. the repository structures for each algorithm suite are described in [RFC6481] 🦋

10. Deprecating an Algorithm Suite 💀

to deprecate an algorithm suite, every CA in the RPKI MUST run the following process:

  1. each CA MUST stop issuing certificates under the suite. that means any request for a CA certificate from a child gets rejected, for example by sending an "error_response" message with error code "request - no such resource class", as defined in [RFC6492] 🚫
  2. each CA MUST stop generating signed products under the deprecated algorithm suite, except the CRL and manifest 🛑
  3. each CA MUST revoke the EE certificates for all signed products it has issued under the deprecated algorithm suite. the CA SHOULD delete these products from its publication point so RPs don't have to waste time downloading and processing them 🗑️
  4. each CA MUST revoke all CA certificates it has issued under the deprecated algorithm suite 🙅
  5. each CA SHOULD remove all CA certificates it has issued under the deprecated algorithm suite 🧹
  6. each CA that publishes a TAL under the deprecated algorithm suite MUST remove it from the TAL's publication point. (the original text says "removed" here, which is a typo, so I'm keeping the requirement but not the spelling 🙈)
  7. each CA SHOULD keep maintaining the publication point for the deprecated algorithm suite at least until the CRL nextUpdate. this publication point MUST contain only the CRL and a manifest for that publication point. this gives RPs a window to find out about the revoked status of the signed products that got deleted ⏰
  8. each RP MUST remove any TALs that it has published under the deprecated algorithm suite 💅

CAs in the RPKI hierarchy might find out about the deprecation at different times, so they may run the procedure above asynchronously from one another. for example, a CA might request revocation of its CA certificate, only to learn that the issuing CA already revoked it 😬 revoking a CA certificate makes the CRL and manifest issued under it impossible to validate. this asynchronous running will likely cause some temporary "inconsistencies" among the publication points tied to the deprecated algorithm suite. still, those inconsistencies should give "fail-safe" results, meaning RPs SHOULD reject the objects signed under the deprecated suite 🛡️

11. Security Considerations 🚨

an algorithm transition in RPKI should be a super rare event, and it needs wide community consensus 🫶 the stuff that leads to an algorithm transition may be a weakness in the cryptographic strength of the suite RPKI is using, which is normal to happen over time. the procedures in this document mean it will take years to finish an algorithm transition. during that time, the RPKI system is vulnerable to any cryptographic weakness that may have set off this procedure (for example, a downgrade attack) 😱

this document does not describe an emergency mechanism for algorithm migration. because RPKI is distributed and has a huge number of CAs and RPs, the authors don't believe an emergency algorithm migration procedure is feasible 🙅‍♀️

if a CA doesn't finish its migration to the new algorithm suite as described in this document (after the EOL of the "old" algorithm suite), its signed product set will stop being valid. so at the end of Phase 4, the RPKI may have fewer valid signed products than it had before starting the process 💔 on the flip side, an RP that doesn't follow this process will lose the ability to validate signed products issued under the new algorithm suite. the incomplete view of routing information from the RPKI (because CAs or RPs failed to finish the transition) could degrade routing on the public Internet 🌐 this one is serious, bestie 🥺

12. Acknowledgements 🫶

the authors would like to thank the SIDR working group co-chairs (Sandra Murphy, Chris Morrow, and Alexey Melnikov), and also Geoff Huston, Arturo Servin, Brian Weis, Terry Manderson, Brian Dickson, David Black, and Danny McPherson for their contributions 🌟

13. Normative References ✨

okay bestie, this is the list of everything this doc leans on to work 🎀 (the "normative" ones are the stuff you HAVE to read to implement it, no cap)

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
  • [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
  • [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
  • [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012.
  • [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
  • [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
  • [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
  • [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, February 2012.
  • [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.

Authors' Addresses 💜

these are the people who wrote it, and how to reach them if you have questions 🫶

Roque Gagliano
Cisco Systems
Avenue des Uttins 5
Rolle  1180
Switzerland

EMail: rogaglia@cisco.com


Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA  02138
USA

EMail: kent@bbn.com


Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA  22031
USA

EMail: turners@ieca.com
📦 where this page comes from