RFC 6489

Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)

📅 published February 2012, from ietf

Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) 🎀

  • RFC number: 6489
  • Series: Internet Engineering Task Force (IETF)
  • Authors: G. Huston (APNIC), G. Michaelson (APNIC), S. Kent (BBN)
  • Category: Best Current Practice, BCP 174
  • ISSN: 2070-1721
  • Date: February 2012
  • Obsoletes / Updates: nothing is listed in the title block 🧚

Abstract ✨

okay so this doc describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) does a planned rollover of its key pair 🔑 it also covers what this key rollover procedure means for relying parties (RPs). generally, RPs are expected to keep a local cache of the objects published in the RPKI repository, so the way a CA does its key rollover affects RPs, and that's the whole reason this matters 💜

Status of This Memo 🌸

This memo documents an Internet Best Current Practice.

This doc is an IETF product, so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more on BCPs is in Section 2 of RFC 5741.

more info on the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6489.

Copyright (c) 2012 IETF Trust and the people named 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 in effect on the date of publication. please read these carefully, bestie, because they describe 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 ....................................................2
   1.1. Terminology and Concepts ...................................2
2. CA Key Rollover Procedure .......................................3
3. Relying Party Requirements ......................................6
4. Reissuing Certificates and RPKI Signed Objects ..................7
   4.1. CA Certificates ............................................7
   4.2. RPKI Signed Objects ........................................7
5. Security Considerations .........................................8
6. Acknowledgements ................................................8
7. References ......................................................9
   7.1. Normative References .......................................9
   7.2. Informative References .....................................9

1. Introduction 🌈

okay, so this doc lays out an algorithm that a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) [RFC6480] uses to roll over its key pair 🔑

this doc defines a "conservative" procedure for those entities to follow when they do a key rollover. it's "conservative" because the CA's actions during the rollover are not meant to disrupt how relying parties (RPs) keep their local cached copy of the RPKI distributed repository running normally 🫶 with this procedure, RPs can validate all authentic objects in the RPKI, using the validation procedure in [RFC6480], at all times. main character energy for the RPs, honestly ✨

1.1. Terminology and Concepts 📚

it's assumed you already know the terms and concepts in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], the profile for RPKI Certificates [RFC6487], and the RPKI repository structure [RFC6481] .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. these are the words that carry the weight in this doc, so read them carefully 🙈

part 1 of 3 down! 🎀 part 2 is next, so stay tuned ✨

2. CA Key Rollover Procedure ✨

okay so a CA in the RPKI is basically the entity that issues CA and end-entity (EE) certificates plus Certificate Revocation Lists (CRLs) 🎀. Each CA instance is tied to one single key pair [RFC6487], which means if key rollover is a regularly scheduled thing, you end up with lots of CA instances over time 🌸. So strictly speaking, a CA doesn't really "roll over" its key. To get the same effect, it makes a brand new instance of itself with a new key pair, then swaps that "new" instance into the RPKI hierarchy in place of the "old" one 🦋.

Also, this procedure is mainly about planned key rollover, not an emergency one, like when a private key gets suspected or detected as compromised 🚨. It still works for emergencies too, just not for the length of the Staging Period 💅.

There are a bunch of things a CA performing a key rollover MUST follow, and the biggest one is that the RPKI can be used for control of routing integrity [RFC6480]. So key rollover should never cause a temporary gap where an RP ends up with the wrong idea about whether the attestations in the RPKI are authentic 😭. A CA can't assume every RP does path validation and path discovery the exact same way, so the key rollover procedure MUST preserve the integrity of the CRL Distribution Points (CRLDP), Subject Information Access (SIA), and Authority Information Access (AIA) pointers in RPKI certificates 🫶.

Here's the flow. The CA makes a "new" CA instance and gets its new public key published in a "new" CA certificate. The "current" and "new" CA instances share one repository publication point, but each one has its own CRL and its own manifest 🧚. At the start, the "new" CA publishes an empty CRL and a manifest with a single entry for that CRL. The "current" CA keeps its published CRL and manifest at that same publication point too 💜.

Then the CA waits. The point of waiting is to give every RP time to find and grab that "new" CA certificate and store it in its local RPKI repository cache instance. This wait is called the Staging Period ⏳. During it, the "new" CA instance has no subordinate products yet, while the "current" CA instance has issued all of them 👑.

When the Staging Period ends, the "new" CA instance MUST replace all (valid) subordinate products of the "current" CA instance, overwriting the "current" subordinate products at the CA's repository publication point 🔥. Once that's done, the "current" CA instance gets retired and the "new" CA instance becomes the "current" CA 🎉.

While the "current" and "new" instances are swapping, the "new" CA instance MUST reissue all subordinate products of the "current" CA 🦋. This procedure says that, apart from manifests and CRLs, the reissued subordinate products have to be published using the same repository publication point object names, so they basically overwrite the old objects 🎀. The whole point of that overwrite is to keep the AIA pointers of subordinate products at lower tiers of the RPKI hierarchy correct, so the key rollover doesn't need any actions from any subordinate CA 🙌.

There are three CA states here:

  • CURRENT: The CURRENT CA is the active CA instance that accepts and processes certificate issuance and revocation requests 💅. The starting point for this algorithm is that the key of the CURRENT CA is about to be rolled over.
  • NEW: The NEW CA is the CA instance being created 🌱. It isn't active, so it doesn't accept or process certificate issuance and revocation requests. The NEW CA SHOULD issue a CRL and an EE certificate along with its manifest, so it's a trivial, complete, and consistent CA instance 🧁.
  • OLD: The CA instance is being removed 🗑️. An OLD CA instance can't process any certificate issuance or revocation requests. It keeps issuing its regularly scheduled CRLs, and it issues an EE certificate as part of updating its manifest to reflect the updated CRL 💫.

To do a key rollover, the CA MUST perform the following steps in the order given here. Unless specified otherwise, each step SHOULD be performed without any intervening delay ⏩. The process MUST be run through to completion 🏁.

  1. Generate a new key pair for the NEW CA 🔑. Since the goal here is key rollover, the key pair generated in this step MUST be different from the pair the CURRENT CA is using 🙅‍♀️.
  2. Generate a certificate request with this key pair and send it to the CA that issued the CURRENT CA certificate 📨. This request MUST include the same SIA extension that's in the CURRENT CA certificate 🎀. Once the request is satisfied, the NEW CA certificate gets published 🥳. This (NEW) CA certificate has a subject name picked by the issuer, and that name MUST be distinct from the subject name used in the CURRENT CA certificate 💅. The Certificate Practice Statement (CPS) for the issuer of the NEW CA certificate says what time frame to expect for processing a certificate request 🗓️.
  3. Publish the NEW CA's CRL and manifest 📄. The steps involved are:
    • Wait for the issuer of the NEW CA to publish the NEW CA certificate ⏳.
    • As quickly as possible after the NEW CA certificate is published, use the key pair associated with the NEW CA to generate an initially empty CRL, and publish it at the NEW CA's repository publication point 🌷. It is RECOMMENDED that the CRL for the NEW CA have a nextUpdate value that causes the CRL to be replaced at the end of the Staging Period (see in Step 4 below) 🦋.
    • Generate a new key pair, and generate an associated EE certificate request with an AIA value of the NEW CA's repository publication point 🔐. Send this EE certificate request to the NEW CA, and use the returned (single-use) EE certificate as the NEW CA's manifest EE certificate 🎟️.
    • Generate a manifest that contains the new CA's CRL as the only entry, and sign it with the private key associated with the manifest EE certificate ✍️. Publish the manifest at the NEW CA's repository publication point 💌.
    • Destroy the private key associated with the manifest EE certificate 💥.
  4. The NEW CA enters a Staging Period ⏸️. The duration of the Staging Period is up to the CA, but it SHOULD be no less than 24 hours ⏰. The Staging Period gives all RPs an opportunity to download the NEW CA certificate before any certificates, CRLs, or RPKI signed objects get published under the NEW CA 🎁. During the Staging Period, the NEW CA SHOULD reissue, but not publish, all of the products that were issued under the CURRENT CA 🧃. That includes all CA certificates, EE certificates, and RPKI signed objects 📦. Section 4 describes how each reissued product relates to the product it replaces 🔍. During the Staging Period, the CURRENT CA SHOULD keep accepting and processing certificate issuance requests, and it MUST keep accepting and processing certificate revocation requests 🙏. If the CURRENT CA issues any certificates during the Staging Period, they MUST be reissued under the NEW CA during this period 🔁. Any certificates revoked under the CURRENT CA MUST NOT be reissued under the NEW CA 🚫. As noted above, in an emergency key rollover, a CA decides whether the 24 hour minimal Staging Period is appropriate or whether a shorter Staging Period is needed 🚑. Since the Staging Period puts no extra burden on Relying Parties, there is no stipulated or recommended maximum Staging Period 🌈.
  5. When the Staging Period expires, the NEW CA MUST publish the signed products that were reissued under the NEW CA 🚀. These replace the matching products issued under the CURRENT CA at the NEW CA's repository publication point 🔄. This replacement is implied by the file naming requirements that [RFC6481] puts on these signed products 📛. The trivial manifest for the NEW CA (which had only one entry, for the NEW CA's CRL) gets replaced by a manifest listing all of these reissued, signed products 📋. At this point, the CURRENT CA becomes the OLD CA, and the NEW CA becomes the CURRENT CA 👑. Use the OLD CA to issue a manifest that lists only the OLD CA's CRL 🗂️. This step is expected to be super brief, maybe a few minutes, because the CA already reissued all the signed products during the Staging Period ⚡. Still, the activities in this step should be seen as atomic by RPs 🫧.
  6. Generate a certificate revocation request for the OLD CA certificate and submit it to the issuer of that certificate 🙋‍♀️. Once the OLD CA certificate is revoked, the CRL for the OLD CA gets removed from the repository, along with the manifest for the OLD CA 🧹. The private key for the OLD CA is destroyed 🔥.

3. Relying Party Requirements 💜

This procedure defines a Staging Period for CAs doing a key rollover operation 🫶. The period is defined as one no shorter than 24 hours ⏳.

RPs who keep a local cache of the distributed RPKI repository MUST run a local cache synchronization operation against the distributed RPKI repository at regular intervals of no longer than 24 hours 🔄. Keep those syncs on schedule, bestie 🕰️.

4. Reissuing Certificates and RPKI Signed Objects 🎀

This section has the rules a CA MUST follow when it reissues subordinate certificates and RPKI signed objects [RFC6488] as part of the key rollover process 📜. Quick note: CRLs and manifests don't get reissued, per se 🙈. They're generated for each CA instance instead. A manifest catalogues the contents of a publication point relative to a CA instance 🗃️. A CRL lists revoked certificates relative to a CA instance 🚫. The key rollover handling for CRLs and manifests is covered above, in Section 3 🌸.

4.1. CA Certificates 💖

okay so when a CA is doing the key rollover thing and reissues its CA certificate, it copies every single field and extension value from the old cert into the new one 🎀 no skipping! The only exceptions are that the notBefore value MAY be set to the current date and time, and the certificate serial number MAY change. ✨ Since the reissued cert comes from a different CA instance, the serial number doesn't have to change, but the CA MUST make sure that each certificate issued under a specific CA instance (a distinct name and key) has a unique serial number 🔥 that part is non-negotiable, bestie!

4.2. RPKI Signed Objects 🦋

An RPKI signed object is a Cryptographic Message Syntax (CMS) signed-data object, containing an EE certificate and a payload (content) [RFC6488]. 📦 When a key rollover happens, the EE certificate for the RPKI signed object MUST be reissued under the key of the NEW CA 💅

Now the CA has two options, and both are giving main character energy 👑 The first option is to treat this EE certificate the same way it treats CA certificates, so it copies over all fields and extensions (i.e., everything), and MAY change only the notBefore date and the serial number 🌸 If the CA goes this route, the new EE certificate gets slotted into the CMS wrapper, but the signed context stays the same. (If the signing time or binary signing time values in the CMS wrapper are non-null, they MAY be updated to reflect the current time ⏰)

The second option is to generate a brand new key pair for the EE certificate 🧚 If the CA does this, the object content MUST be resigned under the private key that matches the EE certificate. In this case the EE certificate MUST contain a new public key and a new notBefore value, and it MAY contain a new notAfter value. Everything else (all the other field and extension values, except the ones about the digital signature and its certificate validation path) stays unchanged 🫶 And again, if the signing time or binary signing time values in the CMS wrapper are non-null, they MAY be updated to reflect the current time 💜

As noted in Sections 2.1.6.4.3 and 2.1.6.4.4 of [RFC6488], the presence or absence of the signing-time and/or the binary-signing-time attribute MUST NOT affect the validity of the RPKI signed object. 🚫 So whether those attributes are there or not, the object's validity is unaffected, iykyk 🙈

5. Security Considerations 🔥

okay this section is SERIOUS but also lowkey iconic 😭 No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis 💀 Infrequent key rollover raises the risk that the rollover procedures won't be followed with the appropriate level of precision, which increases the risk of operational failure of some form in the key rollover process. Regular scheduling of key rollover is generally considered part of prudent key management practice 🍓 BUT key rollover also puts extra operational burdens on both the CA and the population of RPs, so it's a trade-off, fr fr.

These considerations mean that when choosing lifetimes for the keys it manages, a CA should balance security and operational impact (on RPs) ⚖️ A CA should perform key rollover at regularly scheduled intervals. These intervals should be frequent enough to minimize the risks associated with key compromise (noted above) and to maintain local operational proficiency with respect to the key rollover process. However, key lifetimes should be sufficiently long so that the (system-wide) load associated with key rollover events across the entire RPKI does not impose an excessive burden upon the population of RPs 😮‍💨 RPs are encouraged to maintain an accurate local cache of the current state of the RPKI, which implies frequent queries to the RPKI repository system to detect changes 🌈 And when a CA rekeys, it changes many signed objects, so it impacts ALL RPs. Literally everyone feels it 💅

6. Acknowledgements 🎀

The authors would like to acknowledge the review comments of Tim Bruijnzeels and Sean Turner in preparing this document. 💖 Big thank-yous to them!

7. References ✨

7.1. Normative References 📚

  • [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.
  • [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
  • [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
  • [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.

7.2. Informative References 🌸

  • [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.

Authors' Addresses 🦋

Geoff Huston
APNIC

EMail: gih@apnic.net
URI:   http://www.apnic.net


George Michaelson
APNIC

EMail: ggm@apnic.net
URI:   http://www.apnic.net


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

EMail: kent@bbn.com
📦 where this page comes from