idnits 2.17.1 draft-ietf-sidr-keyroll-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 30, 2010) is 4950 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-11 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: BCP APNIC 5 Expires: April 3, 2011 S. Kent 6 BBN 7 September 30, 2010 9 CA Key Rollover in the RPKI 10 draft-ietf-sidr-keyroll-00.txt 12 Abstract 14 This document describes an algorithm to allow an entity who 15 undertakes the role of a Certification Authority in the Resource 16 Public Key Infrastructure to perform a rollover of its key pair. 17 This document also notes the requirements placed on Relying Parties 18 who maintain a local cache of the objects that have been published in 19 the distributed Resource Public Key Infrastructure repository 20 publication structure. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 3, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3 58 2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . . 3 59 3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 This document describes an algorithm to allow an entity undertaking 71 the role of a Certification Authority (CA) in the Resource Public Key 72 Infrastucture (RPKI) [ID.ietf-sidr-arch] to perform a rollover of its 73 key pair. 75 The intent of this document is to define a conservative procedure for 76 such entities to follow when performing a key rollover so that 77 Relying Parties are in a position to be able to validate all 78 authentic objects in the RPKI using the validation procedure 79 described in [ID.ietf-sidr-res-certs] at all times. 81 1.1. Terminology and Concepts 83 It is assumed that the reader is familiar with the terms and concepts 84 described in "Internet X.509 Public Key Infrastructure Certificate 85 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 86 Extensions for IP Addresses and AS Identifiers" [RFC3779], and the 87 profile for RPKI Certificates [ID.ietf-sidr-res-certs] . 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119. 93 2. CA Key Rollover Procedure 95 A CA instance is associated with a single key pair 96 ([ID.ietf-sidr-res-certs]). The implication in the context of key 97 rollover is that, strictly speaking, a CA does not perform a key 98 rollover per se. In order to perform the equivalent of a key 99 rollover, the entity who undertakes the role of a CA needs to 100 instantiate a new instance of a CA, with the new key pair, and then 101 substitute this new CA into the RPKI hierarchy in place of the old 102 CA. 104 There are some considerations regarding this procedure that should be 105 followed by an entity performing a key rollover operation. The 106 critical consideration is that the RPKI has potential application in 107 the area of control of routing integrity [ID.ietf-sidr-arch], and key 108 rollover should not cause any transient hiatus where a Relying Party 109 is led to incorrect conclusions regarding the authenticity of 110 attestations and authorities made in the context of the RPKI. A CA 111 should not assume that Relying Parties will universally use one form 112 of construction of a potential validation path over any other, and 113 therefore the key rollover procedure should endeavour at all times to 114 preserve the integrity of the SIA and AIA pointers in RPKI 115 certificates. 117 In the procedure described here, the entity creates a "new" CA 118 instance, and has the associated new public key published in the form 119 af a "new" CA certificate. While the "current" and "new" CA 120 instances share a single repository publication point, each CA has 121 its own CRL, and its own manifest. Initially, the "new" CA publishes 122 an empty CRL and a manifest that contains a single entry for the CRL. 123 The "current" CA also is 125 The entity should then wait for a period of time to allow Relying 126 Parties to discover and retrieve this "new" CA certificate and store 127 it in their local RPKI Repository cache instances (this period of 128 time is termed the "staging period"). During this period, the entity 129 will have a "new" CA instance, with no subordinate products, and an 130 "current" CA instance which has issued all subordinate products. At 131 the expiration of the staging period the "new" CA instance can re- 132 issue all subordinate products of the previous CA instance, 133 overwriting the old subordinate products in the CA's repository 134 publication point. When this is complete the "current" CA instance 135 can be retired, and the "new" CA instance can be re-termed the 136 "current" CA. 138 During the transition of the CA instances it is necessary for the 139 "new" CA instance to re-issue all subordinate products of the 140 "current" CA. The procedure described here specifies that, with the 141 exception of manifests and CRLs, the re-issued subordinate products 142 be published using the same repository publication point object 143 names, effectively overwriting the old subordinate objects with these 144 re-issued subordinate objects. The intent of this overwriting 145 operation is to ensure that the AIA pointers of indirect subordinate 146 products at lower levels in the PKI hierarchy remain correct, and 147 that CA rollover does not require any associated actions by any 148 subordinate CA. 150 There are four CA states described here: 152 CURRENT: 153 The CA is the active CA used to process certificate issuance and 154 revocation requests from subordinate entities. 156 NEW: 157 The CA is in the process of being created. The CA is unable to 158 process certificate issuance and revocation requests from 159 subordinate entities. The CA may issue a CRL and an EE 160 certificate in association with its Manifest, but has no other 161 subordinate products. 163 PENDING: 164 The CA is in the process of being set up. The CA is able to able 165 to issue certificates that were previously issued with the old 166 key, but is not able to process new certificate issuance and 167 revocation requests from subordinate entities. 169 OLD: 170 The CA is in the process of being removed. The CA is able to 171 unable to process any certificate issuance and revocation requests 172 from subordinate entities. The CA will continue to issue 173 regularly scheduled CRLs and be permitted to issue an EE 174 certificate as part of the process of updating its manifest to 175 reflect the updated CRL. 177 To perform a key rollover operation the entity MUST perform the 178 following steps in the order given here. Unless specified otherwise 179 each step SHOULD be performed without any intervening delay. The 180 process MUST be run through to completion. 182 1. Generate a NEW key pair. 184 2. Generate a certificate request with the NEW key pair and pass 185 the request to the entity's immediate superior CA as the CA 186 certificate Issuer. 188 3. Request the entity's Issuer to generate and publish a NEW CA 189 certificate, with an issuer-selected Subject Name that is 190 distinct from the Subject Name used in the CURRENT CA 191 certificate for this entity. 193 4. Wait for a "Staging Period" following the completion of the 194 NEW CA certificate request. This "Staging Period is selected 195 by the entity, and MUST be no less than 24 hours. 197 5. Upon expiration of the Staging Period, suspend the processing 198 of subordinate certificate issuance requests and revocation 199 requests. Mark the CURRENT CA as OLD and the NEW CA as 200 PENDING. Halt the operation of the OLD CA for all operations 201 except the further issuance of subsequent CRLs and EE 202 certificates for Manifests. 204 6. Use the PENDING CA to generate new certificates for all 205 existing subordinate CA and EE certificates, and publish 206 those products in the same repository publication point and 207 with the same repository publication point name as the 208 previous OLD subordinate CA and EE certificates. The keys in 209 these reissued certificates must not change. 211 7. Excluding manifests, where the signing structure uses a 212 packaging format that includes the EE certificate within the 213 signed data, signed objects that included OLD CA-issed EE 214 certificates in their signed data will need to be re-signed 215 using an EE certificate issued by the PENDING CA. In the 216 case where the OLD CA-issued EE certificate is a "single use" 217 EE certificate and the associated private key has been 218 previously destroyed, this will entail the generation of a 219 new key pair, the issuing of an EE certificate by the PENDING 220 CA, and the signing of the data by the newly generated 221 private key. In the case of a "multi-use" EE certificate, 222 the EE certificate should be issued using the PENDING CA. 223 The object, together with the issued EE certificate, should 224 be signed with the associated private key, and published in 225 the same repository publication point, using the same 226 repository publication point name, as the previously signed 227 object that it replaces (i.e. overwrite the old signed 228 object). 230 8. Use the OLD CA to issue a manifest that lists only the OLD 231 CA's CRL, and use the PENDING CA to issue a manifest that 232 lists all subordinate products that were issued by the 233 PENDING CA. 235 9. Mark the PENDING CA as CURRENT and resume processing 236 subordinate certificate issuance requests. 238 10. Generate a certificate revocation request for the OLD CA 239 certificate and pass it to the entity's Issuer. 241 11. Wait for completion of the OLD CA certificate revocation 242 request, then remove the OLD CA's CRL and Manifest and 243 destroy the OLD private key. 245 3. Relying Party Requirements 247 This procedure defines a "Staging Period" for CAs performing a key 248 rollover operation, which is defined as a period no shorter than 24 249 hours. 251 Relying Parties who maintain a local cache of the distributed RPKI 252 repository MUST perform a local cache synchronisation operation 253 against the distributed RPKI repository at regular intervals of no 254 longer than 24 hours. 256 4. Security Considerations 258 [To be added] 260 5. IANA Considerations 262 [Note to IANA, to be removed prior to publication: there are no IANA 263 considerations stated in this document.] 265 6. Acknowledgements 267 The authors would like to acknowledge the review comments of Tim 268 Bruijnzeels in preparing this document. 270 7. References 272 7.1. Normative References 274 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 275 Addresses and AS Identifiers", RFC 3779, June 2004. 277 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 278 Housley, R., and W. Polk, "Internet X.509 Public Key 279 Infrastructure Certificate and Certificate Revocation List 280 (CRL) Profile", RFC 5280, May 2008. 282 7.2. Informative References 284 [ID.ietf-sidr-arch] 285 Lepinski, M. and S. Kent, "An Infrastructure to Support 286 Secure Internet Routing", draft-ietf-sidr-arch-11 (work in 287 progress), September 2010. 289 [ID.ietf-sidr-res-certs] 290 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 291 X.509 PKIX Resource Certificates", Internet 292 Draft draft-ietf-sidr-res-certs-18.txt, May 2010. 294 Authors' Addresses 296 Geoff Huston 297 Asia Pacific Network Information Centre 299 Email: gih@apnic.net 300 URI: http://www.apnic.net 302 George Michaelson 304 Email: ggm@apnic.net 305 URI: http://www.apnic.net 307 Stephen Kent 308 BBN Technologies 309 10 Moulton St. 310 Cambridge, MA 02138 311 USA 313 Email: kent@bbn.com