idnits 2.17.1 draft-ietf-sidr-keyroll-01.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 (October 1, 2010) is 4954 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 (-09) exists of draft-ietf-sidr-repos-struct-04 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 Summary: 0 errors (**), 0 flaws (~~), 4 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 4, 2011 S. Kent 6 BBN 7 October 1, 2010 9 CA Key Rollover in the RPKI 10 draft-ietf-sidr-keyroll-01.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 4, 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. Reissuing Certificates and RPKI Signed Objects . . . . . . . . 7 61 4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 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 RPKI is an entity that issues 100 certificates and CRLs. Over time, there will be many instances of a 101 CA. A CA instance is associated with a single key pair 102 ([ID.ietf-sidr-res-certs]). The implication in the context of key 103 rollover is that, strictly speaking, a CA does not perform a key 104 rollover per se. In order to perform the equivalent of a key 105 rollover, the CA creates a new instance of itself, with a new key 106 pair, and then substitutes this new CA instance into the RPKI 107 hierarchy in place of the old CA instance. 109 There are several considerations regarding this procedure that MUST 110 be followed by a CA performing a key rollover operation. The 111 critical consideration is that the RPKI has potential application in 112 the area of control of routing integrity [ID.ietf-sidr-arch], , and 113 key rollover should not cause any transient hiatus where a Relying 114 Party (RP) is led to incorrect conclusions regarding the authenticity 115 of attestations made in the context of the RPKI. A CA cannot assume 116 that all RPs will perform path validation and path discovery in the 117 same fashion, and therefore the key rollover procedure MUST preserve 118 the integrity of the CRLDP, SIA and AIA pointers in RPKI 119 certificates. 121 In the procedure described here, the CA creates a new CA instance, 122 and has the associated new public key published in the form of a new 123 CA certificate. While the current and new CA instances share a 124 single repository publication point, each CA has its own CRL and its 125 own manifest. Initially, the new CA publishes an empty CRL and a 126 manifest that contains a single entry for the CRL. The "current" CA 127 also maintains its published CRL and manifest at this Repository 128 publication point. 130 The CA performing key rollover waits for a period of time to afford 131 every RP an opportunity to discover and retrieve this new CA 132 certificate, and store it in its local RPKI Repository cache 133 instance. This period of time is termed the "staging period". 134 During this period, the CA will have a new CA instance, with no 135 subordinate products, and a current CA instance that has issued all 136 subordinate products. At the expiration of the staging period the 137 new CA instance MUST replace all (valid) subordinate products of the 138 current CA instance, overwriting the current subordinate products in 139 the CA's repository publication point. When this process is complete 140 the current CA instance is retired, and the new CA instance becomes 141 the current CA. 143 During the transition of the current and new CA instances it is 144 necessary for the new CA instance to re-issue all subordinate 145 products of the current CA. The procedure described here requires 146 that, with the exception of manifests and CRLs, the re-issued 147 subordinate products be published using the same repository 148 publication point object names, effectively overwriting the old 149 objects with these re-issued objects. The intent of this overwriting 150 operation is to ensure that the AIA pointers of subordinate products 151 at lower tiers in the RPKI hierarchy remain correct, and that CA key 152 rollover does not require any associated actions by any subordinate 153 CA. 155 There are three CA states described here: 157 CURRENT: 158 The CURRENT CA is the active CA instance used to accept and 159 process certificate issuance and revocation requests The starting 160 point for this algorithm is that the key of the CURRENT CA is to 161 be rolled over. 163 NEW: 164 The NEW CA is the CA instance that is being created. The NEW CA 165 is not active, and thus does not accept nor process certificate 166 issuance and revocation requests. The NEW CA SHOULD issue a CRL 167 and an EE certificate in association with its manifest to provide 168 a trivial, complete, consistent instance of a CA. 170 OLD: 171 The CA instance is in the process of being removed. An OLD CA 172 instance is unable to process any certificate issuance and 173 revocation requests. An OLD CA instance will continue to issue 174 regularly scheduled CRLs and issue an EE certificate as part of 175 the process of updating its manifest to reflect the updated CRL. 177 To perform a key rollover operation the CA MUST perform the following 178 steps in the order given here. Unless specified otherwise each step 179 SHOULD be performed without any intervening delay. The process MUST 180 be run through to completion. 182 1. Generate a new key pair for use by the NEW CA. Because the 183 goal of this algorithm is key rollover, the key pair generated 184 in this step MUST be different from the pair in use by the 185 CURRENT CA. 187 2. Generate a certificate request with this key pair and pass the 188 request to the CA that issued the CURRENT CA certificate. 189 This request MUST include the same SIA extension that is 190 present in the CURRENT CA certificate. This request, when 191 satisfied, will result in the publication of the NEW CA 192 certificate. This (NEW) CA certificate will contain an 193 Subject Name selected by the issuer, which MUST be distinct 194 from the Subject Name used in the CURRENT CA certificate. The 195 CPS for the issuer of the NEW CA certificate will indicate the 196 time frame within which a certificate request is expected to 197 be processed. 199 3. Publish the NEW CA's CRL and manifest. 201 The steps involved here are: 203 - Wait for the issuer of the NEW CA to publish the NEW CA 204 certificate. 206 - As quickly as possible following the publication of the 207 NEW CA certificate, use the key pair associated with the 208 NEW CA to generate an initial, empty CRL, and publish 209 this CRL in the NEW CA's repository publication point. 211 It is RECOMMENDED that the CRL for the NEW CA have a 212 nextUpdate value that will cause the CRL to be replaced 213 at the end of the Staging Period (see in Step 4 below). 215 - Generate a new key pair, and generate an associated EE 216 certificate request with an AIA value of the NEW CA's 217 repository publication point. Pass this EE certificate 218 request to the NEW CA, and use the returned (single-use) 219 EE certificate as the NEW CA's manifest EE certificate. 221 - Generate a manifest containing the new CA's CRL as the 222 only entry, and sign it with the private key associated 223 with the manifest EE certificate. Publish the manifest 224 at the NEW CA's repository publication point. 226 - Destroy the private key associated with the manifest EE 227 certificate. 229 4. The NEW CA enters a Staging Period. This duration of the 230 Staging Period is determined by the CA, but it MUST be no less 231 than 24 hours. The Staging Period is intended to afford an 232 opportunity for all RPs to download the NEW CA certificate, 233 prior to publication of certificates, CRLs, and RPKI signed 234 objects under the NEW CA. During the Staging Period, the NEW 235 CA SHOULD reissue, but not publish, all of the products that 236 were issued under the CURRENT CA. This includes all CA 237 certificates, EE certificates, and RPKI signed objects. 238 Section 4 describes how each reissued product relates to the 239 product that it replaces. During the Staging Period, the 240 CURRENT CA SHOULD continue to accept and process certificate 241 issuance requests and MUST continue to accept and process 242 certificate revocation requests. If any certificates are 243 issued by the CURRENT CA during the staging period, they MUST 244 be re-issued under the NEW CA during the period. Any 245 certificates that are revoked under the CURRENT CA MUST NOT be 246 re-issued under the NEW CA. 248 5. Upon expiration of the Staging Period, the NEW CA MUST publish 249 the signed products that have been re-issued under the NEW CA, 250 replacing the corresponding products issued under the CURRENT 251 CA at the NEW CA's repository publication point. This 252 replacement is implied by the file naming requirements imposed 253 by [ID.ietf-sidr-repos-struct] for these signed products. The 254 trivial manifest for the NEW CA (which contained only one 255 entry, for the NEW CA's CRL) is replaced by a manifest listing 256 all of these reissued, signed products. At this point the 257 CURENT CA becomes the OLD CA, and the NEW CA becomes the 258 CURRENT CA. Use the OLD CA to issue a manifest that lists 259 only the OLD CA's CRL. It is anticipated that this step is 260 very brief, perhaps a few minutes in duration, because the CA 261 has reissued all of the signed products during the Staging 262 Period. Nonetheless, it is desirable that the activities 263 performed in this step be viewed as atomic by RPs. 265 6. Generate a certificate revocation request for the OLD CA 266 certificate and submit it to the issuer of that certificate. 267 When the OLD CA certificate is revoked, the CRL for the OLD CA 268 is removed from the repository, along with the manifest for 269 the OLD CA. The private key for the OLD CA is destroyed. 271 3. Relying Party Requirements 273 This procedure defines a Staging Period for CAs performing a key 274 rollover operation. This period is defined as a period no shorter 275 than 24 hours. 277 RPs who maintain a local cache of the distributed RPKI repository 278 MUST perform a local cache synchronisation operation against the 279 distributed RPKI repository at regular intervals of no longer than 24 280 hours. 282 4. Reissuing Certificates and RPKI Signed Objects 284 This section provides rules a CA MUST use when it reissues 285 certificates and RPKI signed objects as part of the key rollover 286 process. Note that CRLs and manifests are not reissued, per se. 287 They are generated for each CA instance. A manifest catalogues the 288 contents of a publication point relative to a CA instance. A CRL 289 lists revoked certificates, relative to a CA instance. Key rollover 290 processing for CRLs and manifests is described above, in Section 3. 292 4.1. CA Certificates 294 When a CA, as part of the key rollover process, reissues a CA 295 certificate, it copies all of the field and extension values from the 296 old certificate into the new certificate. The only exceptions to 297 this rule is that the certificate serial number MUST change, and the 298 notBefore value MAY be set to the current date and time. 300 4.2. RPKI Signed Objects 302 An RPKI signed object is a CMS signed-data object, containing an EE 303 certificate and a payload (content). When a key rollover occurs, the 304 EE certificate for the RPKI signed object MUST be reissued, under the 305 key of the NEW CA. A CA may choose to treat this EE certificate the 306 same way that it deals with CA certificates, i.e., to copy over all 307 fields and extensions, and change only the serial number and the 308 notBefore date. If the CA adopts this approach, then the new EE 309 certificate is inserted into the CMS wrapper, but the signed context 310 remains the same. (If the signing time or binary signing time values 311 in the CMS wrapper are non-null, they MAY be updated to reflect the 312 current time.) Alternatively, the CA MAY elect to generate a new key 313 pair for this EE certificate. If it does so, the object content MUST 314 be resigned under the private key corresponding to the EE 315 certificate. In this case the EE certificate MUST contain a new 316 public key and a new notBefore value, it MAY contain a new notAfter 317 value, but all other field and extension values remain constant. (If 318 the signing time or binary signing time values in the CMS wrapper are 319 non-null, they MAY be updated to reflect the current time.) 321 5. Security Considerations 323 [To be added] 325 6. IANA Considerations 327 [Note to IANA, to be removed prior to publication: there are no IANA 328 considerations stated in this document.] 330 7. Acknowledgements 332 The authors would like to acknowledge the review comments of Tim 333 Bruijnzeels in preparing this document. 335 8. References 337 8.1. Normative References 339 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 340 Addresses and AS Identifiers", RFC 3779, June 2004. 342 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 343 Housley, R., and W. Polk, "Internet X.509 Public Key 344 Infrastructure Certificate and Certificate Revocation List 345 (CRL) Profile", RFC 5280, May 2008. 347 8.2. Informative References 349 [ID.ietf-sidr-arch] 350 Lepinski, M. and S. Kent, "An Infrastructure to Support 351 Secure Internet Routing", draft-ietf-sidr-arch-11 (work in 352 progress), September 2010. 354 [ID.ietf-sidr-repos-struct] 355 Huston, G., Loomans, R., and G. Michaleson, "A Profile for 356 Resource Certificate Repository Structure", Internet 357 Draft draft-ietf-sidr-repos-struct-04.txt, May 2010. 359 [ID.ietf-sidr-res-certs] 360 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 361 X.509 PKIX Resource Certificates", Internet 362 Draft draft-ietf-sidr-res-certs-18.txt, May 2010. 364 Authors' Addresses 366 Geoff Huston 367 Asia Pacific Network Information Centre 369 Email: gih@apnic.net 370 URI: http://www.apnic.net 372 George Michaelson 374 Email: ggm@apnic.net 375 URI: http://www.apnic.net 377 Stephen Kent 378 BBN Technologies 379 10 Moulton St. 380 Cambridge, MA 02138 381 USA 383 Email: kent@bbn.com