idnits 2.17.1 draft-ietf-sidr-keyroll-04.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 (November 9, 2010) is 4910 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-04 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-11 == Outdated reference: A later version (-04) exists of draft-ietf-sidr-signed-object-01 Summary: 0 errors (**), 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: May 13, 2011 S. Kent 6 BBN 7 November 9, 2010 9 CA Key Rollover in the RPKI 10 draft-ietf-sidr-keyroll-04.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 May 13, 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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 9 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 There are several considerations regarding this procedure that MUST 112 be followed by a CA performing a key rollover operation. The 113 critical consideration is that the RPKI has potential application in 114 the area of control of routing integrity [ID.ietf-sidr-arch], and key 115 rollover should not cause any transient hiatus where a Relying Party 116 (RP) is led to incorrect conclusions regarding the authenticity of 117 attestations made in the context of the RPKI. A CA cannot assume 118 that all RPs will perform path validation and path discovery in the 119 same fashion, and therefore the key rollover procedure MUST preserve 120 the integrity of the CRL Distribution Points (CRLDP), Subject 121 Information Access (SIA) and Authority Information Access (AIA) 122 pointers in RPKI certificates. 124 In the procedure described here, the CA creates a "new" CA instance, 125 and has the associated new public key published in the form of a 126 "new" CA certificate. While the "current" and "new" CA instances 127 share a single repository publication point, each CA has its own CRL 128 and its own manifest. Initially, the "new" CA publishes an empty CRL 129 and a manifest that contains a single entry for the CRL. The 130 "current" CA also maintains its published CRL and manifest at this 131 Repository publication point. 133 The CA performing key rollover waits for a period of time to afford 134 every RP an opportunity to discover and retrieve this "new" CA 135 certificate, and store it in its local RPKI Repository cache 136 instance. This period of time is termed the "staging period". 137 During this period, the CA will have a "new" CA instance, with no 138 subordinate products, and a "current" CA instance that has issued all 139 subordinate products. At the expiration of the staging period the 140 "new" CA instance MUST replace all (valid) subordinate products of 141 the "current" CA instance, overwriting the "current" subordinate 142 products in the CA's repository publication point. When this process 143 is complete the "current" CA instance is retired, and the "new" CA 144 instance becomes the "current" CA. 146 During the transition of the "current" and "new" CA instances it is 147 necessary for the "new" CA instance to re-issue all subordinate 148 products of the "current" CA. The procedure described here requires 149 that, with the exception of manifests and CRLs, the re-issued 150 subordinate products be published using the same repository 151 publication point object names, effectively overwriting the old 152 objects with these re-issued objects. The intent of this overwriting 153 operation is to ensure that the AIA pointers of subordinate products 154 at lower tiers in the RPKI hierarchy remain correct, and that CA key 155 rollover does not require any associated actions by any subordinate 156 CA. 158 There are three CA states described here: 160 CURRENT: 161 The CURRENT CA is the active CA instance used to accept and 162 process certificate issuance and revocation requests The starting 163 point for this algorithm is that the key of the CURRENT CA is to 164 be rolled over. 166 NEW: 167 The NEW CA is the CA instance that is being created. The NEW CA 168 is not active, and thus does not accept nor process certificate 169 issuance and revocation requests. The NEW CA SHOULD issue a CRL 170 and an EE certificate in association with its manifest to provide 171 a trivial, complete, consistent instance of a CA. 173 OLD: 174 The CA instance is in the process of being removed. An OLD CA 175 instance is unable to process any certificate issuance and 176 revocation requests. An OLD CA instance will continue to issue 177 regularly scheduled CRLs and issue an EE certificate as part of 178 the process of updating its manifest to reflect the updated CRL. 180 To perform a key rollover operation the CA MUST perform the following 181 steps in the order given here. Unless specified otherwise each step 182 SHOULD be performed without any intervening delay. The process MUST 183 be run through to completion. 185 1. Generate a new key pair for use by the NEW CA. Because the 186 goal of this algorithm is key rollover, the key pair generated 187 in this step MUST be different from the pair in use by the 188 CURRENT CA. 190 2. Generate a certificate request with this key pair and pass the 191 request to the CA that issued the CURRENT CA certificate. 192 This request MUST include the same SIA extension that is 193 present in the CURRENT CA certificate. This request, when 194 satisfied, will result in the publication of the NEW CA 195 certificate. This (NEW) CA certificate will contain a Subject 196 Name selected by the issuer, which MUST be distinct from the 197 Subject Name used in the CURRENT CA certificate. The CPS for 198 the issuer of the NEW CA certificate will indicate the time 199 frame within which a certificate request is expected to be 200 processed. 202 3. Publish the NEW CA's CRL and manifest. 204 The steps involved here are: 206 - Wait for the issuer of the NEW CA to publish the NEW CA 207 certificate. 209 - As quickly as possible following the publication of the 210 NEW CA certificate, use the key pair associated with the 211 NEW CA to generate an initial, empty CRL, and publish 212 this CRL in the NEW CA's repository publication point. 214 It is RECOMMENDED that the CRL for the NEW CA have a 215 nextUpdate value that will cause the CRL to be replaced 216 at the end of the Staging Period (see in Step 4 below). 218 - Generate a new key pair, and generate an associated EE 219 certificate request with an AIA value of the NEW CA's 220 repository publication point. Pass this EE certificate 221 request to the NEW CA, and use the returned (single-use) 222 EE certificate as the NEW CA's manifest EE certificate. 224 - Generate a manifest containing the new CA's CRL as the 225 only entry, and sign it with the private key associated 226 with the manifest EE certificate. Publish the manifest 227 at the NEW CA's repository publication point. 229 - Destroy the private key associated with the manifest EE 230 certificate. 232 4. The NEW CA enters a Staging Period. This duration of the 233 Staging Period is determined by the CA, but it MUST be no less 234 than 24 hours. The Staging Period is intended to afford an 235 opportunity for all RPs to download the NEW CA certificate, 236 prior to publication of certificates, CRLs, and RPKI signed 237 objects under the NEW CA. During the Staging Period, the NEW 238 CA SHOULD re-issue, but not publish, all of the products that 239 were issued under the CURRENT CA. This includes all CA 240 certificates, EE certificates, and RPKI signed objects. 241 Section 4 describes how each re-issued product relates to the 242 product that it replaces. During the Staging Period, the 243 CURRENT CA SHOULD continue to accept and process certificate 244 issuance requests and MUST continue to accept and process 245 certificate revocation requests. If any certificates are 246 issued by the CURRENT CA during the staging period, they MUST 247 be re-issued under the NEW CA during the period. Any 248 certificates that are revoked under the CURRENT CA MUST NOT be 249 re-issued under the NEW CA. 251 5. Upon expiration of the Staging Period, the NEW CA MUST publish 252 the signed products that have been re-issued under the NEW CA, 253 replacing the corresponding products issued under the CURRENT 254 CA at the NEW CA's repository publication point. This 255 replacement is implied by the file naming requirements imposed 256 by [ID.ietf-sidr-repos-struct] for these signed products. The 257 trivial manifest for the NEW CA (which contained only one 258 entry, for the NEW CA's CRL) is replaced by a manifest listing 259 all of these re-issued, signed products. At this point the 260 CURRENT CA becomes the OLD CA, and the NEW CA becomes the 261 CURRENT CA. Use the OLD CA to issue a manifest that lists 262 only the OLD CA's CRL. It is anticipated that this step is 263 very brief, perhaps a few minutes in duration, because the CA 264 has re-issued all of the signed products during the Staging 265 Period. Nonetheless, it is desirable that the activities 266 performed in this step be viewed as atomic by RPs. 268 6. Generate a certificate revocation request for the OLD CA 269 certificate and submit it to the issuer of that certificate. 270 When the OLD CA certificate is revoked, the CRL for the OLD CA 271 is removed from the repository, along with the manifest for 272 the OLD CA. The private key for the OLD CA is destroyed. 274 3. Relying Party Requirements 276 This procedure defines a Staging Period for CAs performing a key 277 rollover operation. This period is defined as a period no shorter 278 than 24 hours. 280 RPs who maintain a local cache of the distributed RPKI repository 281 MUST perform a local cache synchronisation operation against the 282 distributed RPKI repository at regular intervals of no longer than 24 283 hours. 285 4. Re-issuing Certificates and RPKI Signed Objects 287 This section provides rules a CA MUST use when it re-issues 288 subordinate certificates and RPKI signed objects 289 [ID.ietf-sidr-signed-object] as part of the key rollover process. 290 Note that CRLs and manifests are not re-issued, per se. They are 291 generated for each CA instance. A manifest catalogues the contents 292 of a publication point relative to a CA instance. A CRL lists 293 revoked certificates, relative to a CA instance. Key rollover 294 processing for CRLs and manifests is described above, in Section 3. 296 4.1. CA Certificates 298 When a CA, as part of the key rollover process, re-issues a CA 299 certificate, it copies all of the field and extension values from the 300 old certificate into the new certificate. The only exceptions to 301 this rule are that the notBefore value MAY be set to the current date 302 and time, and the certificate serial number MAY change. Because the 303 re-issued CA certificate is issued by a different CA instance, it is 304 not a requirement that the certificate serial number change in the 305 re-issued certificate. Nonetheless, the CA MUST ensure that each 306 certificate issued under a specific CA instance (a distinct name and 307 key) contains a unique serial number. 309 4.2. RPKI Signed Objects 311 An RPKI signed object is a CMS signed-data object, containing an EE 312 certificate and a payload (content) [ID.ietf-sidr-signed-object]. 313 When a key rollover occurs, the EE certificate for the RPKI signed 314 object MUST be re-issued, under the key of the NEW CA. A CA MAY 315 choose to treat this EE certificate the same way that it deals with 316 CA certificates, i.e., to copy over all fields and extensions, and 317 MAY change only the notBefore date and the serial number. If the CA 318 adopts this approach, then the new EE certificate is inserted into 319 the CMS wrapper, but the signed context remains the same. (If the 320 signing time or binary signing time values in the CMS wrapper are 321 non-null, they MAY be updated to reflect the current time.) 322 Alternatively, the CA MAY elect to generate a new key pair for this 323 EE certificate. If it does so, the object content MUST be resigned 324 under the private key corresponding to the EE certificate. In this 325 case the EE certificate MUST contain a new public key and a new 326 notBefore value, it MAY contain a new notAfter value, but all other 327 field and extension values remain constant. If the signing time or 328 binary signing time values in the CMS wrapper are non-null, they MAY 329 be updated to reflect the current time. 331 5. Security Considerations 333 No key should be used forever. The longer a key is in use, the 334 greater the probability that it will have been compromised through 335 carelessness, accident, espionage, or cryptanalysis. Infrequent key 336 rollover increases the risk that the rollover procedures will not be 337 followed to the appropriate level of precision, increasing the risk 338 of operational failure of some form in the key rollover process. 339 Regular scheduling of key rollover is generally considered to be a 340 part of a prudent key management practice. However, key rollover 341 does impose additional operational burdens on both the CA and upon 342 the population of RPs. 344 These considerations imply that in choosing lifetimes for the keys it 345 manages, a CA should balance security and operational impact (on 346 RPs). A CA should perform key rollover at regularly scheduled 347 intervals. These intervals should be frequent enough to minimize the 348 risks associated with key compromise (noted above) and to maintain 349 local operational proficiency with respect to the key rollover 350 process. However, key lifetimes should be sufficiently long so that 351 the (system-wide) load associated with key rollover events (across 352 the entire RPKI) does not impose an excessive burden upon the 353 population of RPs. RPs are encouraged to maintain an accurate local 354 cache of the current state of the RPKI, which implies frequent 355 queries to the RPKI repository system to detect changes. When a CA 356 rekeys, it changes many signed objects, thus impacting all RPs. 358 6. IANA Considerations 360 [Note to IANA, to be removed prior to publication: there are no IANA 361 considerations stated in this document.] 363 7. Acknowledgements 365 The authors would like to acknowledge the review comments of Tim 366 Bruijnzeels and Sean Turner in preparing this document. 368 8. References 370 8.1. Normative References 372 [ID.ietf-sidr-repos-struct] 373 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 374 Resource Certificate Repository Structure", Internet 375 Draft draft-ietf-sidr-repos-struct-04.txt, May 2010. 377 [ID.ietf-sidr-res-certs] 378 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 379 X.509 PKIX Resource Certificates", Internet 380 Draft draft-ietf-sidr-res-certs-18.txt, May 2010. 382 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 383 Addresses and AS Identifiers", RFC 3779, June 2004. 385 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 386 Housley, R., and W. Polk, "Internet X.509 Public Key 387 Infrastructure Certificate and Certificate Revocation List 388 (CRL) Profile", RFC 5280, May 2008. 390 8.2. Informative References 392 [ID.ietf-sidr-arch] 393 Lepinski, M. and S. Kent, "An Infrastructure to Support 394 Secure Internet Routing", draft-ietf-sidr-arch-11 (work in 395 progress), September 2010. 397 [ID.ietf-sidr-signed-object] 398 Lepinski, M., Chi, A., and S. Kent, "Signed Object 399 Template for the Resource Public Key Infrastructure", 400 draft-ietf-sidr-signed-object-01.txt (work in progress), 401 October 2010. 403 Authors' Addresses 405 Geoff Huston 406 Asia Pacific Network Information Centre 408 Email: gih@apnic.net 409 URI: http://www.apnic.net 411 George Michaelson 413 Email: ggm@apnic.net 414 URI: http://www.apnic.net 416 Stephen Kent 417 BBN Technologies 418 10 Moulton St. 419 Cambridge, MA 02138 420 USA 422 Email: kent@bbn.com