SIDR G. Huston Internet-Draft G. Michaelson Intended status: BCP APNIC Expires: April 4, 2011 S. Kent BBN October 1, 2010 CA Key Rollover in the RPKI draft-ietf-sidr-keyroll-01.txt Abstract This document describes an algorithm to allow an entity who undertakes the role of a Certification Authority in the Resource Public Key Infrastructure to perform a rollover of its key pair. This document also notes the requirements placed on Relying Parties who maintain a local cache of the objects that have been published in the distributed Resource Public Key Infrastructure repository publication structure. Status of this Memo 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 http://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 April 4, 2011. Copyright Notice Copyright (c) 2010 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 Huston, et al. Expires April 4, 2011 [Page 1]
Internet-Draft Key Rollover October 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3 2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . . 3 3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 7 4. Reissuing Certificates and RPKI Signed Objects . . . . . . . . 7 4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . . 7 4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Huston, et al. Expires April 4, 2011 [Page 2]
Internet-Draft Key Rollover October 2010 1. Introduction This document describes an algorithm to by employed by a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) [ID.ietf-sidr-arch] to perform a rollover of its key pair. This document defines a conservative procedure for such entities to follow when performing a key rollover, so that Relying Parties are in a position to be able to validate all authentic objects in the RPKI using the validation procedure described in [ID.ietf-sidr-arch] 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 [ID.ietf-sidr-res-certs], and the RPKI repository structure [ID.ietf-sidr-repos-struct] . 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 RFC 2119. 2. CA Key Rollover Procedure A certification Authority (CA) in the RPKI is an entity that issues certificates and CRLs. Over time, there will be many instances of a CA. A CA instance is associated with a single key pair ([ID.ietf-sidr-res-certs]). 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 substitutes this new CA instance into the RPKI hierarchy in place of the old CA instance. 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 [ID.ietf-sidr-arch], , and key rollover should not cause any transient hiatus where a Relying Party (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, and therefore the key rollover procedure MUST preserve Huston, et al. Expires April 4, 2011 [Page 3]
Internet-Draft Key Rollover October 2010 the integrity of the CRLDP, SIA and 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 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 it is necessary for the new CA instance to re-issue all subordinate products of the current CA. The procedure described here requires that, with the exception of manifests and CRLs, the re-issued subordinate products be published using the same repository publication point object names, effectively overwriting the old objects with these re-issued 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. Huston, et al. Expires April 4, 2011 [Page 4]
Internet-Draft Key Rollover October 2010 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, 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. 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 an Subject Name selected by the issuer, which MUST be distinct from the Subject Name used in the CURRENT CA certificate. The 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 initial, empty CRL, and publish this CRL in the NEW CA's repository publication point. Huston, et al. Expires April 4, 2011 [Page 5]
Internet-Draft Key Rollover October 2010 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. This duration of the Staging Period is determined by the CA, but it MUST 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 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 re-issued under the NEW CA during the period. Any certificates that are revoked under the CURRENT CA MUST NOT be re-issued under the NEW CA. 5. Upon expiration of the Staging Period, the NEW CA MUST publish the signed products that have been re-issued 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 [ID.ietf-sidr-repos-struct] 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 CURENT CA becomes the OLD CA, and the NEW CA becomes the CURRENT CA. Use the OLD CA to issue a manifest that lists Huston, et al. Expires April 4, 2011 [Page 6]
Internet-Draft Key Rollover October 2010 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. RPs who maintain a local cache of the distributed RPKI repository MUST perform a local cache synchronisation 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 certificates and RPKI signed objects 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 is that the certificate serial number MUST change, and the notBefore value MAY be set to the current date and time. 4.2. RPKI Signed Objects An RPKI signed object is a CMS signed-data object, containing an EE certificate and a payload (content). When a key rollover occurs, the Huston, et al. Expires April 4, 2011 [Page 7]
Internet-Draft Key Rollover October 2010 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 change only the serial number and the notBefore date. 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, it MAY contain a new notAfter value, but all other field and extension values remain constant. (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.) 5. Security Considerations [To be added] 6. IANA Considerations [Note to IANA, to be removed prior to publication: there are no IANA considerations stated in this document.] 7. Acknowledgements The authors would like to acknowledge the review comments of Tim Bruijnzeels in preparing this document. 8. References 8.1. Normative References [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. Huston, et al. Expires April 4, 2011 [Page 8]
Internet-Draft Key Rollover October 2010 8.2. Informative References [ID.ietf-sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-11 (work in progress), September 2010. [ID.ietf-sidr-repos-struct] Huston, G., Loomans, R., and G. Michaleson, "A Profile for Resource Certificate Repository Structure", Internet Draft draft-ietf-sidr-repos-struct-04.txt, May 2010. [ID.ietf-sidr-res-certs] Huston, G., Michaleson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", Internet Draft draft-ietf-sidr-res-certs-18.txt, May 2010. Authors' Addresses Geoff Huston Asia Pacific Network Information Centre Email: gih@apnic.net URI: http://www.apnic.net George Michaelson 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. Expires April 4, 2011 [Page 9]