idnits 2.17.1 draft-ietf-sidr-keyroll-06.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 (February 21, 2011) is 4812 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 (-09) exists of draft-ietf-sidr-repos-struct-07 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-21 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-12 == Outdated reference: A later version (-04) exists of draft-ietf-sidr-signed-object-03 Summary: 0 errors (**), 0 flaws (~~), 6 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: August 25, 2011 S. Kent 6 BBN 7 February 21, 2011 9 CA Key Rollover in the RPKI 10 draft-ietf-sidr-keyroll-06.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 are 18 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 June 6, 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 . . . . . . . . . . . . . . . . . . . . . 7 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 by 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". During 143 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 it is 153 necessary for the "new" CA instance to re-issue all subordinate 154 products of the "current" CA. The procedure described here requires 155 that, with the exception of manifests and CRLs, the re-issued 156 subordinate products be published using the same repository 157 publication point object names, effectively overwriting the old 158 objects with these re-issued objects. The intent of this overwriting 159 operation is to ensure that the AIA pointers of subordinate products 160 at lower tiers in the RPKI hierarchy remain correct, and that CA key 161 rollover does not require any associated actions by any subordinate 162 CA. 164 There are three CA states described here: 166 CURRENT: 167 The CURRENT CA is the active CA instance used to accept and 168 process certificate issuance and revocation requests The starting 169 point for this algorithm is that the key of the CURRENT CA is to 170 be rolled over. 172 NEW: 173 The NEW CA is the CA instance that is being created. The NEW CA 174 is not active, and thus does not accept nor process certificate 175 issuance and revocation requests. The NEW CA SHOULD issue a CRL 176 and an EE certificate in association with its manifest to provide 177 a trivial, complete, consistent instance of a CA. 179 OLD: 180 The CA instance is in the process of being removed. An OLD CA 181 instance is unable to process any certificate issuance and 182 revocation requests. An OLD CA instance will continue to issue 183 regularly scheduled CRLs and issue an EE certificate as part of 184 the process of updating its manifest to reflect the updated CRL. 186 To perform a key rollover operation the CA MUST perform the following 187 steps in the order given here. Unless specified otherwise each step 188 SHOULD be performed without any intervening delay. The process MUST 189 be run through to completion. 191 1. Generate a new key pair for use by the NEW CA. Because the 192 goal of this algorithm is key rollover, the key pair generated 193 in this step MUST be different from the pair in use by the 194 CURRENT CA. 196 2. Generate a certificate request with this key pair and pass the 197 request to the CA that issued the CURRENT CA certificate. This 198 request MUST include the same SIA extension that is present in 199 the CURRENT CA certificate. This request, when satisfied, 200 will result in the publication of the NEW CA certificate. 201 This (NEW) CA certificate will contain a Subject Name selected 202 by the issuer, which MUST be distinct from the Subject Name 203 used in the CURRENT CA certificate. The CPS for the issuer of 204 the NEW CA certificate will indicate the time frame within 205 which a 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. This 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 the 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.) 258 5. Upon expiration of the Staging Period, the NEW CA MUST publish 259 the signed products that have been re-issued under the NEW CA, 260 replacing the corresponding products issued under the CURRENT 261 CA at the NEW CA's repository publication point. This 262 replacement is implied by the file naming requirements imposed 263 by [ID.ietf-sidr-repos-struct] for these signed products. The 264 trivial manifest for the NEW CA (which contained only one 265 entry, for the NEW CA's CRL) is replaced by a manifest listing 266 all of these re-issued, signed products. At this point the 267 CURRENT CA becomes the OLD CA, and the NEW CA becomes the 268 CURRENT CA. Use the OLD CA to issue a manifest that lists 269 only the OLD CA's CRL. It is anticipated that this step is 270 very brief, perhaps a few minutes in duration, because the CA 271 has re-issued all of the signed products during the Staging 272 Period. Nonetheless, it is desirable that the activities 273 performed in this step be viewed as atomic by RPs. 275 6. Generate a certificate revocation request for the OLD CA 276 certificate and submit it to the issuer of that certificate. 277 When the OLD CA certificate is revoked, the CRL for the OLD CA 278 is removed from the repository, along with the manifest for 279 the OLD CA. The private key for the OLD CA is destroyed. 281 3. Relying Party Requirements 283 This procedure defines a Staging Period for CAs performing a key 284 rollover operation. This period is defined as a period no shorter 285 than 24 hours. 287 RPs who maintain a local cache of the distributed RPKI repository 288 MUST perform a local cache synchronisation operation against the 289 distributed RPKI repository at regular intervals of no longer than 24 290 hours. 292 4. Re-issuing Certificates and RPKI Signed Objects 294 This section provides rules a CA MUST use when it re-issues 295 subordinate certificates and RPKI signed objects 296 [ID.ietf-sidr-signed-object] as part of the key rollover process. 297 Note that CRLs and manifests are not re-issued, per se. They are 298 generated for each CA instance. A manifest catalogues the contents 299 of a publication point relative to a CA instance. A CRL lists 300 revoked certificates, relative to a CA instance. Key rollover 301 processing for CRLs and manifests is described above, in Section 3. 303 4.1. CA Certificates 304 When a CA, as part of the key rollover process, re-issues a CA 305 certificate, it copies all of the field and extension values from the 306 old certificate into the new certificate. The only exceptions to 307 this rule are that the notBefore value MAY be set to the current date 308 and time, and the certificate serial number MAY change. Because the 309 re-issued CA certificate is issued by a different CA instance, it is 310 not a requirement that the certificate serial number change in the 311 re-issued certificate. Nonetheless, the CA MUST ensure that each 312 certificate issued under a specific CA instance (a distinct name and 313 key) contains a unique serial number. 315 4.2. RPKI Signed Objects 317 An RPKI signed object is a CMS signed-data object, containing an EE 318 certificate and a payload (content) [ID.ietf-sidr-signed-object]. 319 When a key rollover occurs, the EE certificate for the RPKI signed 320 object MUST be re-issued, under the key of the NEW CA. A CA MAY 321 choose to treat this EE certificate the same way that it deals with 322 CA certificates, i.e., to copy over all fields and extensions, and 323 MAY change only the notBefore date and the serial number. If the CA 324 adopts this approach, then the new EE certificate is inserted into 325 the CMS wrapper, but the signed context remains the same. (If the 326 signing time or binary signing time values in the CMS wrapper are 327 non-null, they MAY be updated to reflect the current time.) 328 Alternatively, the CA MAY elect to generate a new key pair for this 329 EE certificate. If it does so, the object content MUST be resigned 330 under the private key corresponding to the EE certificate. In this 331 case the EE certificate MUST contain a new public key and a new 332 notBefore value, and it MAY contain a new notAfter value, but all 333 other field and extension values, other that those relating to the 334 digital signature and its associated certificate validation path, 335 remain unchanged. If the signing time or binary signing time values 336 in the CMS wrapper are non-null, they MAY be updated to reflect the 337 current time. 339 As noted in Section 2.1.6.4.3 and 2.1.6.4.4 of 340 [ID.ietf-sidr-signed-object], the presence or absence of the 341 SigningTime and/or the BinarySigningTime attribute MUST NOT affect 342 the validity of the RPKI signed object. 344 5. Security Considerations 346 No key should be used forever. The longer a key is in use, the 347 greater the probability that it will have been compromised through 348 carelessness, accident, espionage, or cryptanalysis. Infrequent key 349 rollover increases the risk that the rollover procedures will not be 350 followed to the appropriate level of precision, increasing the risk 351 of operational failure of some form in the key rollover process. 352 Regular scheduling of key rollover is generally considered to be a 353 part of a prudent key management practice. However, key rollover 354 does impose additional operational burdens on both the CA and upon 355 the population of RPs. 357 These considerations imply that in choosing lifetimes for the keys it 358 manages, a CA should balance security and operational impact (on 359 RPs). A CA should perform key rollover at regularly scheduled 360 intervals. These intervals should be frequent enough to minimize the 361 risks associated with key compromise (noted above) and to maintain 362 local operational proficiency with respect to the key rollover 363 process. However, key lifetimes should be sufficiently long so that 364 the (system-wide) load associated with key rollover events (across 365 the entire RPKI) does not impose an excessive burden upon the 366 population of RPs. RPs are encouraged to maintain an accurate local 367 cache of the current state of the RPKI, which implies frequent 368 queries to the RPKI repository system to detect changes. When a CA 369 rekeys, it changes many signed objects, thus impacting all RPs. 371 6. IANA Considerations 373 [Note to IANA, to be removed prior to publication: there are no IANA 374 considerations stated in this document.] 376 7. Acknowledgements 378 The authors would like to acknowledge the review comments of Tim 379 Bruijnzeels and Sean Turner in preparing this document. 381 8. References 383 8.1. Normative References 385 [ID.ietf-sidr-repos-struct] 386 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 387 Resource Certificate Repository Structure", Internet 388 Draft draft-ietf-sidr-repos-struct-07.txt, February, 2011. 390 [ID.ietf-sidr-res-certs] 391 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 392 X.509 PKIX Resource Certificates", Internet 393 Draft draft-ietf-sidr-res-certs-21.txt, December 2010. 395 8.2. Informative References 397 [RFC3779] 398 Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 399 Addresses and AS Identifiers", RFC 3779, June 2004. 401 [RFC5280] 402 Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 403 Housley, R.,and W. Polk, "Internet X.509 Public Key 404 Infrastructure Certificate and Certificate Revocation List 405 (CRL) Profile", RFC 5280, May 2008. 407 [ID.ietf-sidr-arch] 408 Lepinski, M. and S. Kent, "An Infrastructure to Support 409 Secure Internet Routing", draft-ietf-sidr-arch-12.txt (work 410 in progress), February 2011. 412 [ID.ietf-sidr-signed-object] 413 Lepinski, M., Chi, A., and S. Kent, "Signed Object 414 Template for the Resource Public Key Infrastructure", 415 draft-ietf-sidr-signed-object-03.txt (work in progress), 416 February 2011. 418 Authors' Addresses 420 Geoff Huston 421 Asia Pacific Network Information Centre 423 Email: gih@apnic.net 424 URI: http://www.apnic.net 426 George Michaelson 428 Email: ggm@apnic.net 429 URI: http://www.apnic.net 431 Stephen Kent 432 BBN Technologies 433 10 Moulton St. 434 Cambridge, MA 02138 435 USA 437 Email: kent@bbn.com