idnits 2.17.1 draft-ietf-sidr-keyroll-08.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 (July 11, 2011) is 4644 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-12 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'ID.ietf-sidr-arch') == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-07 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 == Outdated reference: A later version (-04) exists of draft-ietf-sidr-signed-object-03 Summary: 1 error (**), 0 flaws (~~), 5 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: January 12, 2012 S. Kent 6 BBN 7 July 11, 2011 9 CA Key Rollover in the RPKI 10 draft-ietf-sidr-keyroll-08.txt 12 Abstract 14 This document describes how a Certification Authority (CA) in the 15 Resource Public Key Infrastructure (RPKI) performs a planned rollover 16 of its key pair. This document also notes the implications of this 17 key rollover procedure for Relying Parties (RPs). In general, RPs 18 are expected to maintain a local cache of the objects that have been 19 published in the RPKI repository, and thus the way in which a CA 20 performs key rollover impacts RPs. 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 January 12, 2012. 39 Copyright Notice 41 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . 7 60 4. Re-issuing Certificates and RPKI Signed Objects . . . . . . . 7 61 4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 8 62 4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 This document describes an algorithm to be employed by a 74 Certification Authority (CA) in the Resource Public Key 75 Infrastructure (RPKI) [ID.ietf-sidr-arch] to perform a rollover of 76 its key pair. 78 This document defines a conservative procedure for such entities to 79 follow when performing a key rollover. This procedure is 80 "conservative" in that the CA's actions in key rollover are not 81 intended to disrupt the normal operation of Relying Parties (RPs) in 82 maintaining a local cached version of the RPKI distributed 83 repository. Using this procedure, RPs are in a position to be able 84 to validate all authentic objects in the RPKI using the validation 85 procedure described in [ID.ietf-sidr-arch] at all times. 87 1.1. Terminology and Concepts 89 It is assumed that the reader is familiar with the terms and concepts 90 described in "Internet X.509 Public Key Infrastructure Certificate 91 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 92 Extensions for IP Addresses and AS Identifiers" [RFC3779], the 93 profile for RPKI Certificates [ID.ietf-sidr-res-certs], and the RPKI 94 repository structure [ID.ietf-sidr-repos-struct] . 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119. 100 2. CA Key Rollover Procedure 102 A Certification Authority (CA) in the Resource Public Key 103 Infrastructure (RPKI) is an entity that issues CA and End Entity (EE) 104 certificates and Certificate Revocation Lists (CRLs). A CA instance 105 is associated with a single key pair ([ID.ietf-sidr-res-certs]), 106 implying that if key rollover is a regularly scheduled event then, 107 over time, there will be many instances of a CA. The implication in 108 the context of key rollover is that, strictly speaking, a CA does not 109 perform a key rollover per se. In order to perform the equivalent of 110 a key rollover, the CA creates a "new" instance of itself, with a new 111 key pair, and then effectively substitutes this "new" CA instance 112 into the RPKI hierarchy in place of the old CA instance. 114 Note that focus of this procedure is planned key rollover, not an 115 "emergency" key rollover, e.g., promoted by a suspected or detected 116 private key compromise. However, the procedure described here is 117 applicable in emergency key rollover situations, with the exception 118 of the Staging Period duration. 120 There are several considerations regarding this procedure that MUST 121 be followed by a CA performing a key rollover operation. The 122 critical consideration is that the RPKI has potential application in 123 the area of control of routing integrity [ID.ietf-sidr-arch], and key 124 rollover should not cause any transient hiatus in which a Relying 125 Party (RP) is led to incorrect conclusions regarding the authenticity 126 of attestations made in the context of the RPKI. A CA cannot assume 127 that all RPs will perform path validation and path discovery in the 128 same fashion, and therefore the key rollover procedure MUST preserve 129 the integrity of the CRL Distribution Points (CRLDP), Subject 130 Information Access (SIA) and Authority Information Access (AIA) 131 pointers in RPKI certificates. 133 In the procedure described here, the CA creates a "new" CA instance, 134 and has the associated new public key published in the form of a 135 "new" CA certificate. While the "current" and "new" CA instances 136 share a single repository publication point, each CA has its own CRL 137 and its own manifest. Initially, the "new" CA publishes an empty CRL 138 and a manifest that contains a single entry for the CRL. The 139 "current" CA also maintains its published CRL and manifest at this 140 Repository publication point. 142 The CA performing key rollover waits for a period of time to afford 143 every RP an opportunity to discover and retrieve this "new" CA 144 certificate, and store it in its local RPKI Repository cache 145 instance. This period of time is termed the "staging period". 146 During this period, the CA will have a "new" CA instance, with no 147 subordinate products, and a "current" CA instance that has issued all 148 subordinate products. At the expiration of the staging period the 149 "new" CA instance MUST replace all (valid) subordinate products of 150 the "current" CA instance, overwriting the "current" subordinate 151 products in the CA's repository publication point. When this process 152 is complete the "current" CA instance is retired, and the "new" CA 153 instance becomes the "current" CA. 155 During the transition of the "current" and "new" CA instances the 156 "new" CA instance MUST re-issue all subordinate products of the 157 "current" CA. The procedure described here requires that, with the 158 exception of manifests and CRLs, the re-issued subordinate products 159 be published using the same repository publication point object 160 names, effectively overwriting the old objects with these re-issued 161 objects. The intent of this overwriting operation is to ensure that 162 the AIA pointers of subordinate products at lower tiers in the RPKI 163 hierarchy remain correct, and that CA key rollover does not require 164 any associated actions by any subordinate CA. 166 There are three CA states described here: 168 CURRENT: 169 The CURRENT CA is the active CA instance used to accept and 170 process certificate issuance and revocation requests. The 171 starting point for this algorithm is that the key of the CURRENT 172 CA is to be rolled over. 174 NEW: 175 The NEW CA is the CA instance that is being created. The NEW CA 176 is not active, and thus does not accept nor process certificate 177 issuance and revocation requests. The NEW CA SHOULD issue a CRL 178 and an EE certificate in association with its manifest to provide 179 a trivial, complete, consistent instance of a CA. 181 OLD: 182 The CA instance is in the process of being removed. An OLD CA 183 instance is unable to process any certificate issuance and 184 revocation requests. An OLD CA instance will continue to issue 185 regularly scheduled CRLs and issue an EE certificate as part of 186 the process of updating its manifest to reflect the updated CRL. 188 To perform a key rollover operation the CA MUST perform the following 189 steps in the order given here. Unless specified otherwise each step 190 SHOULD be performed without any intervening delay. The process MUST 191 be run through to completion. 193 1. Generate a new key pair for use by the NEW CA. Because the 194 goal of this algorithm is key rollover, the key pair generated 195 in this step MUST be different from the pair in use by the 196 CURRENT CA. 198 2. Generate a certificate request with this key pair and pass the 199 request to the CA that issued the CURRENT CA certificate. 200 This request MUST include the same SIA extension that is 201 present in the CURRENT CA certificate. This request, when 202 satisfied, will result in the publication of the NEW CA 203 certificate. This (NEW) CA certificate will contain a Subject 204 Name selected by the issuer, which MUST be distinct from the 205 Subject Name used in the CURRENT CA certificate. The 206 Certificate Practice Statement (CPS) for the issuer of the NEW 207 CA certificate will indicate the time frame within which a 208 certificate request is expected to be processed. 210 3. Publish the NEW CA's CRL and manifest. 212 The steps involved here are: 214 - Wait for the issuer of the NEW CA to publish the NEW CA 215 certificate. 217 - As quickly as possible following the publication of the 218 NEW CA certificate, use the key pair associated with the 219 NEW CA to generate an initial, empty CRL, and publish 220 this CRL in the NEW CA's repository publication point. 221 It is RECOMMENDED that the CRL for the NEW CA have a 222 nextUpdate value that will cause the CRL to be replaced 223 at the end of the Staging Period (see in Step 4 below). 225 - Generate a new key pair, and generate an associated EE 226 certificate request with an AIA value of the NEW CA's 227 repository publication point. Pass this EE certificate 228 request to the NEW CA, and use the returned (single-use) 229 EE certificate as the NEW CA's manifest EE certificate. 231 - Generate a manifest containing the new CA's CRL as the 232 only entry, and sign it with the private key associated 233 with the manifest EE certificate. Publish the manifest 234 at the NEW CA's repository publication point. 236 - Destroy the private key associated with the manifest EE 237 certificate. 239 4. The NEW CA enters a Staging Period. The duration of the 240 Staging Period is determined by the CA, but it SHOULD be no 241 less than 24 hours. The Staging Period is intended to afford 242 an opportunity for all RPs to download the NEW CA certificate, 243 prior to publication of certificates, CRLs, and RPKI signed 244 objects under the NEW CA. During the Staging Period, the NEW 245 CA SHOULD re-issue, but not publish, all of the products that 246 were issued under the CURRENT CA. This includes all CA 247 certificates, EE certificates, and RPKI signed objects. 248 Section 4 describes how each re-issued product relates to the 249 product that it replaces. During the Staging Period, the 250 CURRENT CA SHOULD continue to accept and process certificate 251 issuance requests and MUST continue to accept and process 252 certificate revocation requests. If any certificates are 253 issued by the CURRENT CA during the Staging Period, they MUST 254 be re-issued under the NEW CA during this period. Any 255 certificates that are revoked under the CURRENT CA MUST NOT be 256 re-issued under the NEW CA. As noted above, in the case of an 257 emergency key rollover, a CA will decide whether the 24 hour 258 minimal Staging Period interval is appropriate, or if a 259 shorter Staging Period is needed. As the Staging Period 260 imposes no additional burden on Relying Parties, there is no 261 stipulated or recommended maximum Staging Period. 263 5. Upon expiration of the Staging Period, the NEW CA MUST publish 264 the signed products that have been re-issued under the NEW CA, 265 replacing the corresponding products issued under the CURRENT 266 CA at the NEW CA's repository publication point. This 267 replacement is implied by the file naming requirements imposed 268 by [ID.ietf-sidr-repos-struct] for these signed products. The 269 trivial manifest for the NEW CA (which contained only one 270 entry, for the NEW CA's CRL) is replaced by a manifest listing 271 all of these re-issued, signed products. At this point the 272 CURRENT CA becomes the OLD CA, and the NEW CA becomes the 273 CURRENT CA. Use the OLD CA to issue a manifest that lists 274 only the OLD CA's CRL. It is anticipated that this step is 275 very brief, perhaps a few minutes in duration, because the CA 276 has re-issued all of the signed products during the Staging 277 Period. Nonetheless, it is desirable that the activities 278 performed in this step be viewed as atomic by RPs. 280 6. Generate a certificate revocation request for the OLD CA 281 certificate and submit it to the issuer of that certificate. 282 When the OLD CA certificate is revoked, the CRL for the OLD CA 283 is removed from the repository, along with the manifest for 284 the OLD CA. The private key for the OLD CA is destroyed. 286 3. Relying Party Requirements 288 This procedure defines a Staging Period for CAs performing a key 289 rollover operation. This period is defined as a period no shorter 290 than 24 hours. 292 RPs who maintain a local cache of the distributed RPKI repository 293 MUST perform a local cache synchronisation operation against the 294 distributed RPKI repository at regular intervals of no longer than 24 295 hours. 297 4. Re-issuing Certificates and RPKI Signed Objects 299 This section provides rules a CA MUST use when it re-issues 300 subordinate certificates and RPKI signed objects 301 [ID.ietf-sidr-signed-object] as part of the key rollover process. 302 Note that CRLs and manifests are not re-issued, per se. They are 303 generated for each CA instance. A manifest catalogues the contents 304 of a publication point relative to a CA instance. A CRL lists 305 revoked certificates, relative to a CA instance. Key rollover 306 processing for CRLs and manifests is described above, in Section 3. 308 4.1. CA Certificates 310 When a CA, as part of the key rollover process, re-issues a CA 311 certificate, it copies all of the field and extension values from the 312 old certificate into the new certificate. The only exceptions to 313 this rule are that the notBefore value MAY be set to the current date 314 and time, and the certificate serial number MAY change. Because the 315 re-issued CA certificate is issued by a different CA instance, it is 316 not a requirement that the certificate serial number change in the 317 re-issued certificate. Nonetheless, the CA MUST ensure that each 318 certificate issued under a specific CA instance (a distinct name and 319 key) contains a unique serial number. 321 4.2. RPKI Signed Objects 323 An RPKI signed object is a Cryptographic Message Syntax (CMS) signed- 324 data object, containing an EE certificate and a payload (content) 325 [ID.ietf-sidr-signed-object]. When a key rollover occurs, the EE 326 certificate for the RPKI signed object MUST be re-issued, under the 327 key of the NEW CA. A CA MAY choose to treat this EE certificate the 328 same way that it deals with CA certificates, i.e., to copy over all 329 fields and extensions, and MAY change only the notBefore date and the 330 serial number. If the CA adopts this approach, then the new EE 331 certificate is inserted into the CMS wrapper, but the signed context 332 remains the same. (If the signing time or binary signing time values 333 in the CMS wrapper are non-null, they MAY be updated to reflect the 334 current time.) Alternatively, the CA MAY elect to generate a new key 335 pair for this EE certificate. If it does so, the object content MUST 336 be resigned under the private key corresponding to the EE 337 certificate. In this case the EE certificate MUST contain a new 338 public key and a new notBefore value, and it MAY contain a new 339 notAfter value, but all other field and extension values, other that 340 those relating to the digital signature and its associated 341 certificate validation path, remain unchanged. If the signing time 342 or binary signing time values in the CMS wrapper are non-null, they 343 MAY be updated to reflect the current time. 345 As noted in Section 2.1.6.4.3 and 2.1.6.4.4 of 346 [ID.ietf-sidr-signed-object], the presence or absence of the 347 SigningTime and/or the BinarySigningTime attribute MUST NOT affect 348 the validity of the RPKI signed object. 350 5. Security Considerations 352 No key should be used forever. The longer a key is in use, the 353 greater the probability that it will have been compromised through 354 carelessness, accident, espionage, or cryptanalysis. Infrequent key 355 rollover increases the risk that the rollover procedures will not be 356 followed to the appropriate level of precision, increasing the risk 357 of operational failure of some form in the key rollover process. 358 Regular scheduling of key rollover is generally considered to be a 359 part of a prudent key management practice. However, key rollover 360 does impose additional operational burdens on both the CA and upon 361 the population of RPs. 363 These considerations imply that in choosing lifetimes for the keys it 364 manages, a CA should balance security and operational impact (on 365 RPs). A CA should perform key rollover at regularly scheduled 366 intervals. These intervals should be frequent enough to minimize the 367 risks associated with key compromise (noted above) and to maintain 368 local operational proficiency with respect to the key rollover 369 process. However, key lifetimes should be sufficiently long so that 370 the (system-wide) load associated with key rollover events (across 371 the entire RPKI) does not impose an excessive burden upon the 372 population of RPs. RPs are encouraged to maintain an accurate local 373 cache of the current state of the RPKI, which implies frequent 374 queries to the RPKI repository system to detect changes. When a CA 375 rekeys, it changes many signed objects, thus impacting all RPs. 377 6. IANA Considerations 379 [Note to RFC Editor, to be removed prior to publication: there are no 380 IANA considerations stated in this document.] 382 7. Acknowledgements 384 The authors would like to acknowledge the review comments of Tim 385 Bruijnzeels and Sean Turner in preparing this document. 387 8. References 389 8.1. Normative References 391 [ID.ietf-sidr-arch] 392 Lepinski, M. and S. Kent, "An Infrastructure to Support 393 Secure Internet Routing", draft-ietf-sidr-arch-12 (work in 394 progress), February 2011. 396 [ID.ietf-sidr-repos-struct] 397 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 398 Resource Certificate Repository Structure", Internet 399 Draft draft-ietf-sidr-repos-struct-07.txt, February 2010. 401 [ID.ietf-sidr-res-certs] 402 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 403 X.509 PKIX Resource Certificates", Internet 404 Draft draft-ietf-sidr-res-certs-18.txt, May 2010. 406 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 407 Addresses and AS Identifiers", RFC 3779, June 2004. 409 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 410 Housley, R., and W. Polk, "Internet X.509 Public Key 411 Infrastructure Certificate and Certificate Revocation List 412 (CRL) Profile", RFC 5280, May 2008. 414 8.2. Informative References 416 [ID.ietf-sidr-signed-object] 417 Lepinski, M., Chi, A., and S. Kent, "Signed Object 418 Template for the Resource Public Key Infrastructure", 419 draft-ietf-sidr-signed-object-03.txt (work in progress), 420 February 2011. 422 Authors' Addresses 424 Geoff Huston 425 Asia Pacific Network Information Centre 427 Email: gih@apnic.net 428 URI: http://www.apnic.net 430 George Michaelson 432 Email: ggm@apnic.net 433 URI: http://www.apnic.net 434 Stephen Kent 435 BBN Technologies 436 10 Moulton St. 437 Cambridge, MA 02138 438 USA 440 Email: kent@bbn.com