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