diff options
Diffstat (limited to 'doc/rfc/rfc6489.txt')
| -rw-r--r-- | doc/rfc/rfc6489.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc6489.txt b/doc/rfc/rfc6489.txt new file mode 100644 index 0000000..7959b13 --- /dev/null +++ b/doc/rfc/rfc6489.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Huston +Request for Comments: 6489 G. Michaelson +BCP: 174 APNIC +Category: Best Current Practice S. Kent +ISSN: 2070-1721 BBN + February 2012 + + + Certification Authority (CA) Key Rollover in + the Resource Public Key Infrastructure (RPKI) + +Abstract + + This document describes how a Certification Authority (CA) in the + Resource Public Key Infrastructure (RPKI) performs a planned rollover + of its key pair. This document also notes the implications of this + key rollover procedure for relying parties (RPs). In general, RPs + are expected to maintain a local cache of the objects that have been + published in the RPKI repository, and thus the way in which a CA + performs key rollover impacts RPs. + +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. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6489. + +Copyright Notice + + Copyright (c) 2012 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) 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 Simplified BSD License text as described in Section 4.e of + + + + +Huston, et al. Best Current Practice [Page 1] + +RFC 6489 Key Rollover February 2012 + + + the Trust Legal Provisions and are provided 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 + + This document describes an algorithm to be employed by a + Certification Authority (CA) in the Resource Public Key + Infrastructure (RPKI) [RFC6480] to perform a rollover of its key + pair. + + This document defines a conservative procedure for such entities to + follow when performing a key rollover. This procedure is + "conservative" in that the CA's actions in key rollover are not + intended to disrupt the normal operation of relying parties (RPs) in + maintaining a local cached version of the RPKI distributed + repository. Using this procedure, RPs are in a position to be able + to validate all authentic objects in the RPKI using the validation + procedure described in [RFC6480] at all times. + +1.1. Terminology and Concepts + + It is assumed that the reader is familiar with the terms and concepts + described 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]. + + + + + +Huston, et al. Best Current Practice [Page 2] + +RFC 6489 Key Rollover February 2012 + + +2. CA Key Rollover Procedure + + A CA in the RPKI is an entity that issues CA and end-entity (EE) + certificates and Certificate Revocation Lists (CRLs). A CA instance + is associated with a single key pair [RFC6487], implying that if key + rollover is a regularly scheduled event, then, over time, there will + be many CA instances. The implication in the context of key rollover + is that, strictly speaking, a CA does not perform a key rollover per + se. In order to perform the equivalent of a key rollover, the CA + creates a "new" instance of itself, with a new key pair, and then + effectively substitutes this "new" CA instance into the RPKI + hierarchy in place of the "old" CA instance. + + Note that focus of this procedure is planned key rollover, not an + emergency key rollover, e.g., promoted by a suspected or detected + private key compromise. However, the procedure described here is + applicable in emergency key rollover situations, with the exception + of the "Staging Period" duration. + + There are several considerations regarding this procedure that MUST + be followed by a CA performing a key rollover operation. The + critical consideration is that the RPKI has potential application in + the area of control of routing integrity [RFC6480], and key rollover + should not cause any transient hiatus in which an RP is led to + incorrect conclusions regarding the authenticity of attestations made + in the context of the RPKI. A CA cannot assume that all RPs will + perform path validation and path discovery in the same fashion; + therefore, 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. + + In the procedure described here, the CA creates a "new" CA instance, + and has the associated new public key published in the form of a + "new" CA certificate. While the "current" and "new" CA instances + share a single repository publication point, each CA has its own CRL + and its own manifest. Initially, the "new" CA publishes an empty CRL + and a manifest that contains a single entry for the CRL. The + "current" CA also maintains its published CRL and manifest at this + repository publication point. + + The CA performing key rollover waits for a period of time to afford + every RP an opportunity to discover and retrieve this "new" CA + certificate, and store it in its local RPKI repository cache + instance. This period of time is termed the Staging Period. During + this period, the CA will have a "new" CA instance, with no + subordinate products, and a "current" CA instance that has issued all + subordinate products. At the expiration of the Staging Period, the + + + +Huston, et al. Best Current Practice [Page 3] + +RFC 6489 Key Rollover February 2012 + + + "new" CA instance MUST replace all (valid) subordinate products of + the "current" CA instance, overwriting the "current" subordinate + products in the CA's repository publication point. When this process + is complete, the "current" CA instance is retired, and the "new" CA + instance becomes the "current" CA. + + During the transition of the "current" and "new" CA instances, the + "new" CA instance MUST reissue all subordinate products of the + "current" CA. The procedure described here requires that, with the + exception of manifests and CRLs, the reissued subordinate products be + published using the same repository publication point object names, + effectively overwriting the old objects with these reissued objects. + The intent of this overwriting operation is to ensure that the AIA + pointers of subordinate products at lower tiers in the RPKI hierarchy + remain correct, and that CA key rollover does not require any + associated actions by any subordinate CA. + + There are three CA states described here: + + CURRENT: + The CURRENT CA is the active CA instance used to accept and + process certificate issuance and revocation requests. The + starting point for this algorithm is that the key of the CURRENT + CA is to be rolled over. + + NEW: + The NEW CA is the CA instance that is being created. The NEW CA + is not active, and thus does not accept nor process certificate + issuance and revocation requests. The NEW CA SHOULD issue a CRL + and an EE certificate in association with its manifest to provide + a trivial, complete, and consistent instance of a CA. + + OLD: + The CA instance is in the process of being removed. An OLD CA + instance is unable to process any certificate issuance and + revocation requests. An OLD CA instance will continue to issue + regularly scheduled CRLs and issue an EE certificate as part of + the process of updating its manifest to reflect the updated CRL. + + To perform a key rollover operation, 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 use by the NEW CA. Because the + goal of this algorithm is key rollover, the key pair generated + in this step MUST be different from the pair in use by the + CURRENT CA. + + + +Huston, et al. Best Current Practice [Page 4] + +RFC 6489 Key Rollover February 2012 + + + 2. Generate a certificate request with this key pair and pass the + request to the CA that issued the CURRENT CA certificate. This + request MUST include the same SIA extension that is present in + the CURRENT CA certificate. This request, when satisfied, will + result in the publication of the NEW CA certificate. This + (NEW) CA certificate will contain a subject name selected by + the issuer, which 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 will + indicate the time frame within which a certificate request is + expected to be processed. + + 3. Publish the NEW CA's CRL and manifest. + + The steps involved here are: + + - Wait for the issuer of the NEW CA to publish the NEW CA + certificate. + + - As quickly as possible following the publication of the NEW + CA certificate, use the key pair associated with the NEW CA + to generate an initially empty CRL, and publish this CRL in + the NEW CA's repository publication point. It is + RECOMMENDED that the CRL for the NEW CA have a nextUpdate + value that will cause 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. Pass 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 containing 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 determined by the CA, but it SHOULD be no + less than 24 hours. The Staging Period is intended to afford + an opportunity for all RPs to download the NEW CA certificate + prior to publication of certificates, CRLs, and RPKI signed + objects under the NEW CA. During the Staging Period, the NEW + CA SHOULD reissue, but not publish, all of the products that + + + +Huston, et al. Best Current Practice [Page 5] + +RFC 6489 Key Rollover February 2012 + + + were issued under the CURRENT CA. This includes all CA + certificates, EE certificates, and RPKI signed objects. + Section 4 describes how each reissued product relates to the + product that it replaces. During the Staging Period, the + CURRENT CA SHOULD continue to accept and process certificate + issuance requests and MUST continue to accept and process + certificate revocation requests. If any certificates are + issued by the CURRENT CA during the Staging Period, they MUST + be reissued under the NEW CA during this period. Any + certificates that are revoked under the CURRENT CA MUST NOT be + reissued under the NEW CA. As noted above, in the case of an + emergency key rollover, a CA will decide whether the 24 hour + minimal Staging Period interval is appropriate, or if a shorter + Staging Period is needed. As the Staging Period imposes no + additional burden on Relying Parties, there is no stipulated or + recommended maximum Staging Period. + + 5. Upon expiration of the Staging Period, the NEW CA MUST publish + the signed products that have been reissued under the NEW CA, + replacing the corresponding products issued under the CURRENT + CA at the NEW CA's repository publication point. This + replacement is implied by the file naming requirements imposed + by [RFC6481] for these signed products. The trivial manifest + for the NEW CA (which contained only one entry, for the NEW + CA's CRL) is 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. It is anticipated that this step is very brief, perhaps a + few minutes in duration, because the CA has reissued all of the + signed products during the Staging Period. Nonetheless, it is + desirable that the activities performed in this step be viewed + as atomic by RPs. + + 6. Generate a certificate revocation request for the OLD CA + certificate and submit it to the issuer of that certificate. + When the OLD CA certificate is revoked, the CRL for the OLD CA + is 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 performing a key + rollover operation. This period is defined as a period no shorter + than 24 hours. + + + + + + +Huston, et al. Best Current Practice [Page 6] + +RFC 6489 Key Rollover February 2012 + + + RPs who maintain a local cache of the distributed RPKI repository + MUST perform a local cache synchronization operation against the + distributed RPKI repository at regular intervals of no longer than 24 + hours. + +4. Reissuing Certificates and RPKI Signed Objects + + This section provides rules a CA MUST use when it reissues + subordinate certificates and RPKI signed objects [RFC6488] as part of + the key rollover process. Note that CRLs and manifests are not + reissued, per se. They are generated for each CA instance. A + manifest catalogues the contents of a publication point relative to a + CA instance. A CRL lists revoked certificates relative to a CA + instance. Key rollover processing for CRLs and manifests is + described above, in Section 3. + +4.1. CA Certificates + + When a CA, as part of the key rollover process, reissues a CA + certificate, it copies all of the field and extension values from the + old certificate into the new certificate. The only exceptions to + this rule are that the notBefore value MAY be set to the current date + and time, and the certificate serial number MAY change. Because the + reissued CA certificate is issued by a different CA instance, it is + not a requirement that the certificate serial number change in the + reissued certificate. Nonetheless, the CA MUST ensure that each + certificate issued under a specific CA instance (a distinct name and + key) contains a unique serial number. + +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 occurs, the EE certificate for the + RPKI signed object MUST be reissued, under the key of the NEW CA. A + CA MAY choose to treat this EE certificate the same way that it deals + with CA certificates, i.e., to copy over all fields and extensions, + and MAY change only the notBefore date and the serial number. If the + CA adopts this approach, then the new EE certificate is inserted into + the CMS wrapper, but the signed context remains 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.) + Alternatively, the CA MAY elect to generate a new key pair for this + EE certificate. If it does so, the object content MUST be resigned + under the private key corresponding to 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, but all + other field and extension values, other than those relating to the + + + +Huston, et al. Best Current Practice [Page 7] + +RFC 6489 Key Rollover February 2012 + + + digital signature and its associated certificate validation path, + remain unchanged. 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. + +5. Security Considerations + + 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 increases the risk that the rollover procedures will not be + followed to the appropriate level of precision, increasing the risk + of operational failure of some form in the key rollover process. + Regular scheduling of key rollover is generally considered to be a + part of a prudent key management practice. However, key rollover + does impose additional operational burdens on both the CA and the + population of RPs. + + These considerations imply that in 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. When a CA + rekeys, it changes many signed objects, thus impacting all RPs. + +6. Acknowledgements + + The authors would like to acknowledge the review comments of Tim + Bruijnzeels and Sean Turner in preparing this document. + + + + + + + + + + +Huston, et al. Best Current Practice [Page 8] + +RFC 6489 Key Rollover February 2012 + + +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. + + + + + + + + + + + + + + + + + + + + +Huston, et al. Best Current Practice [Page 9] + +RFC 6489 Key Rollover 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Huston, et al. Best Current Practice [Page 10] + |