idnits 2.17.00 (12 Aug 2021) /tmp/idnits46649/draft-ietf-sidr-algorithm-agility-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 23 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: During this phase, all signed product sets MUST be issued using Algorithm Suite A (formerly B) and MAY be issued using Algorithm Suite C (formerly A). All signed products sets issued using Suite A MUST be published at their corresponding publication points, but signed products sets issued using Suite C MAY NOT be published at their corresponding publication points. Also, every RP MUST validate signed product sets using Suite A but also MAY validate signed product sets using Suite C. However, RPs SHOULD NOT assume the Suite C repository is complete. -- The document date (January 17, 2012) is 3776 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-sidr-res-certs' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC2560' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'RFC5781' is defined on line 811, but no explicit reference was found in the text == Outdated reference: draft-ietf-sidr-cp has been published as RFC 6484 == Outdated reference: draft-ietf-sidr-keyroll has been published as RFC 6489 == Outdated reference: draft-ietf-sidr-repos-struct has been published as RFC 6481 == Outdated reference: draft-ietf-sidr-res-certs has been published as RFC 6487 == Outdated reference: draft-ietf-sidr-rescerts-provisioning has been published as RFC 6492 == Outdated reference: draft-ietf-sidr-rpki-algs has been published as RFC 6485 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gagliano 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Kent 5 Expires: July 20, 2012 BBN Technologies 6 S. Turner 7 IECA, Inc. 8 January 17, 2012 10 Algorithm Agility Procedure for RPKI. 11 draft-ietf-sidr-algorithm-agility-05 13 Abstract 15 This document specifies the process that Certification Authorities 16 (CAs) and Relying Parties (RP) participating in the Resource Public 17 Key Infrastructure (RPKI) will need to follow to transition to a new 18 (and probably cryptographically stronger) algorithm set. The process 19 is expected to be completed in a time scale of months or years. 20 Consequently, no emergency transition is specified. The transition 21 procedure defined in this document supports only a top-down migration 22 (parent migrates before children). 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 20, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Key Rollover steps for algorithm migration . . . . . . . . . . 7 62 4.1. Milestones definition . . . . . . . . . . . . . . . . . . 7 63 4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 10 66 4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 15 71 5. Multi Algorithm support in the RPKI provisioning protocol . . 16 72 6. Validation of multiple instance of signed products . . . . . . 17 73 7. Revocations . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 9. Repository structure . . . . . . . . . . . . . . . . . . . . . 20 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 78 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 81 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 82 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 85 1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Introduction 93 The RPKI must accommodate transitions between the public keys used by 94 CAs. Transitions of this sort are usually termed "key rollover". 95 Planned key rollover will occur at regular intervals throughout the 96 life of the RPKI, as each CA changes its public keys, in a non- 97 coordinated fashion. (By non-coordinated we mean that the time at 98 which each CA elects to change its keys is locally determined, not 99 coordinated across the RPKI.) Moreover, because a key change might 100 be necessitated by suspected private key compromise, one can never 101 assume coordination of these events among all of the CAs in the RPKI. 102 In an emergency key rollover, the old certificate is revoked and a 103 new certificate with a new key is issued. The mechanisms to perform 104 a key rollover in RPKI (either planned or in an emergency), while 105 maintaining the same algorithm suite, are covered in 106 [I-D.ietf-sidr-keyroll]. 108 This document describes the mechanism to perform a key rollover in 109 RPKI due to the migration to a new signature algorithm suite. A 110 signature algorithm suite encompasses both a signature algorithm 111 (with a specified key size range) and a one-way hash algorithm. It 112 is anticipated that the RPKI will require the adoption of updated key 113 sizes and/or different algorithm suites over time. This document 114 treats the adoption of a new hash algorithm while retaining the 115 current signature algorithm as equivalent to an algorithm migration, 116 and requires the CA to change its key. Migration to a new algorithm 117 suite will be required in order to maintain an acceptable level of 118 cryptographic security and protect the integrity of certificates, 119 CRLs and signed objects in the RPKI. All of the data structures in 120 the RPKI explicitly identify the signature and hash algorithms being 121 used. However, experience has demonstrated that the ability to 122 represent algorithm IDs is not sufficient to enable migration to new 123 algorithm suites (algorithm agility). One also must ensure that 124 protocols, infrastructure elements, and operational procedures also 125 accommodate migration from one algorithm suite to another. Algorithm 126 migration is expected to be very infrequent, but it also will require 127 support of a "current" and "next" suite for a prolonged interval, 128 probably several years. 130 This document defines how entities in the RPKI execute (planned) CA 131 key rollover when the algorithm suite changes. The description 132 covers actions by CAs, repository operators, and RPs. It describes 133 the behavior required of both CAs and RPs to make such key changes 134 work in the RPKI context, including how the RPKI repository system is 135 used to support key rollover. 137 This document does not specify any algorithm suite per se. The RPKI 138 Certificate Policy (CP) [I-D.ietf-sidr-cp] mandates the use of the 139 algorithms defined in [I-D.ietf-sidr-rpki-algs] by CAs and RPs. When 140 an algorithm transition is initiated, [I-D.ietf-sidr-rpki-algs] will 141 be updated (as defined in Section 4.1 of this document) redefining 142 the required algorithm(s) for compliant RPKI CAs and RPs under the 143 CP. The CP will not change as a side effect of algorithm transition 144 (and thus the policy OID in RPKI certificates will not change.) 146 An additional document, the algorithm transition timetable, will be 147 published (as a BCP) to define the dates for each milestone defined 148 in this document. It will define dates for the phase transitions, 149 consistent with the descriptions provided in Section 4. It also will 150 describe how the RPKI community will measure the readiness of CAs and 151 RPs to transition to each phase. CAs publish certificates, CRLs, and 152 other signed objects under the new algorithm suite as the transition 153 progresses. This provides visibility into the deployment of the new 154 algorithm suite, enabling the community to evaluate deployment 155 progress. The transition procedure allows CAs to remove old 156 certificates, CRLs, and signed products, after the twilight date. 157 This provides an ability to observe and measure the withdrawal of the 158 old algorithm suite. Thus the phases defined in this document enable 159 the community to evaluate the progress of the transition. The 160 timetable document will also describe procedures to amend the 161 timetable if problems arise in implementing later phases of the 162 transition. It is RECOMMENDED that the timetable document be 163 developed by representatives of the RPKI community, e.g., IANA, 164 Internet Registries, and network operators. 166 3. Terminology 168 This document assumes that the reader is familiar with the terms and 169 concepts described in "Internet X.509 Public Key Infrastructure 170 Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], 171 "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 172 "A Profile for Resource Certificate Repository Structure" 173 [I-D.ietf-sidr-repos-struct]. Additional terms and conventions used 174 in examples are provided below. 176 Algorithm migration A planned transition from one signature and hash 177 algorithm to a new signature and hash algorithm. 179 Algorithm Suite A The "current" algorithm suite used for hashing and 180 signing, in examples in this document 182 Algorithm Suite B The "next" algorithm suite used for hashing and 183 signing, used in examples in this document 185 Algorithm Suite C The "old" algorithm suite used for hashing and 186 signing, used in examples in this document 188 CA X The CA that issued CA Y's certificate (i.e., CA Y's 189 parent), used in examples in this document. 191 CA Y The non-leaf CA used in examples this document 193 CA Z A CA that is a "child" of CA Y, used in examples this 194 document 196 Non-Leaf CA A CA that issues certificates to other CAs is a non-leaf 197 CA. 199 Leaf CA A leaf CA is a CA that issues only EE certs. 201 PoP (proof of possession) Execution of a protocol that demonstrates 202 to an issuer that a subject requesting a certificate 203 possesses the private key corresponding to the public key 204 in the certificate submitted by the subject. 206 Signed Product Set (or Set or Product Set) A collection of 207 certificates, signed objects, a CRL and a manifest that 208 are associated by virtue of being verifiable under the 209 same parent CA certificate 211 4. Key Rollover steps for algorithm migration 213 The "current" RPKI algorithm suite (Suite A) is defined in the RPKI 214 CP document, by reference to [I-D.ietf-sidr-rpki-algs]. When a 215 migration of the RPKI algorithm suite is needed, the first step MUST 216 be an update of the [I-D.ietf-sidr-rpki-algs] document to define the 217 new algorithm suite. The algorithm transition timeline document MUST 218 also be published (as a BCP), to inform the community of the dates 219 selected for milestones in the transition process, as described in 220 Section 4.1. 222 4.1. Milestones definition 224 CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST 225 be ready to process a request from a child CA to issue a 226 certificate under the Algorithm B suite. 228 CA Go Algorithm B Date - After this date, all (non-leaf) CAs MUST 229 have reissued all of their signed product sets under the 230 Algorithm B suite. 232 RP Ready Algorithm B Date - After this date, all RPs MUST be 233 prepared to process signed material issued under the 234 Algorithm B suite. 236 Twilight Algorithm B - After this date, a CA MAY cease issuing 237 signed products under the Algorithm A suite. Also, after 238 this date, a RP MAY cease to validate signed materials 239 issued under the Algorithm A suite. 241 End Of Life (EOL) Algorithm A - After this date every CA MUST NOT 242 generate certificates, CRLs, or other RPKI signed objects 243 under the Algorithm A suite. Also, after this date, no 244 RP SHOULD accept as valid any certificate, CRL or signed 245 object using the Algorithm A suite. 247 4.2. Process overview 249 The migration process described in this document involves a series of 250 steps that MUST be executed in chronological order by CAs and RPs. 251 The only milestone at which both CAs and RPs take action at the same 252 time is the "EOL Algorithm A" date. Due to the decentralized nature 253 of the RPKI infrastructure, it is expected that an algorithm 254 transition will span several years. 256 In order to facilitate the transition, CAs will start issuing 257 certificates using the Algorithm B in a hierarchical top-down 258 fashion. In our example, CA Y will issue certificates using the 259 Algorithm B suite only after CA X has started to do so (CA Y Ready 260 Algorithm B Date > CA X Ready Algorithm B Date). This ordered 261 transition avoids issuance of "mixed" suite certificates, e.g., a CA 262 certificate signed using Suite A, containing a key from Suite B. In 263 the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key 264 that corresponds to an algorithm suite that differs from the one used 265 to sign the certificate (X.509 accommodates such mixed algorithm 266 certificates, but this process avoids using that capability.) A not 267 top-down transition approach would require use of such mixed mode 268 certificates, but this would lead to exponential growth of the RPKI 269 repository. Also, because the RPKI CP mandates "proof of possession" 270 for certificate requests, it is not possible for a CA to request a 271 certificate for Algorithm Suite B, until its parent CA supports that 272 Suite. (See Section 5 for more details.) 274 The algorithm agility model described here does not prohibit a CA 275 from issuing an EE certificate with a subject public key from a 276 different algorithm suite, if that certificate is not used to verify 277 repository objects. This exception to the mixed algorithm suite 278 certificate rule is allowed because an EE certificate that is not 279 used to verify repository objects does not interfere with the ability 280 of RPs to download and verify repository content. As noted above, 281 every CA in the RPKI is required to perform a Proof of Possession 282 (PoP) check for the subject public key when issuing a certificate. 283 In general a subject cannot assume that a CA is capable of supporting 284 a different algorithm. However, if the subject is closely affiliated 285 with the CA, it is reasonable to assume that there are ways for the 286 subject to know whether the CA can support a request to issue an EE 287 certificate containing a specific, different public key algorithm. 288 This document does not specify how a subject can determine whether a 289 CA is capable of issuing a mixed suite EE certificate, because it 290 anticipates that such certificates will be issued only in contexts 291 where the subject and CA are sufficiently closely affiliated (for 292 example, an ISP issuing certificates to devices that it manages). 294 The following figure gives an overview of the process: 296 Process for RPKI CAs: 298 Phase 0 Phase 1 Phase 2 Phase 4 Phase 0 299 -----------x---------x-------------------x--------x----------- 300 ^ ^ ^ ^ ^ 301 | | | | | 302 (1) (2) (3) (5) (6) 304 Process for RPKI RPs: 306 Phase 0 Phase 3 Phase 4 Phase 0 307 -------------------------------x---------x--------x----- 308 ^ ^ ^ ^ 309 | | | | 310 (1) (4) (5) (6) 312 (1) RPKI algorithm document is updated and the algorithm transition timeline document is issued 313 (2) CA Ready Algorithm B Date 314 (3) CA Go Algorithm B Date 315 (4) RP Ready Algorithm B Date 316 (5) Twilight Date 317 (6) End Of Live (EOL) Date 319 Each of these milestones is discussed in the next section as part of 320 describing each phase of the transition process. 322 Two situations have been identified that motivate pausing or rolling 323 back the transition process. The first situation arises if the RPKI 324 community is not ready to make the transition. For example, many CAs 325 might not be prepared to issue signed products under Suite B, or many 326 RPs might not be ready to process Suite B product sets. Under these 327 circumstances, the timetable MUST be reissued, postponing the date 328 for the phase in question, and pushing back the dates for later 329 phases. The other situation arises if, during the transition, 330 serious concerns arise about the security of the Suite B algorithms. 331 Such concerns would motivate terminating the transition and rolling 332 back signed products, i.e., reverting to Suite A. In this case the 333 timetable MUST be republished, and the RPKI algorithm document MUST 334 be superseded. The phase descriptions below allude to these two 335 situations, as appropriate. 337 4.3. Phase 0 339 Phase 0 is the initial phase of the process, throughout this phase 340 the algorithm suite A is the only supported algorithm suite in RPKI. 341 This is also the steady state for the RPKI. 343 The following figure illustrates the format used to describe signed 344 objects in the repository. It reflects the algorithm suites in use, 345 and shows the relationship between three CAs (X, Y, and Z) that form 346 a chain. 348 During Phase 0, CAs X, Y and Z are required to generate signed 349 product sets using only the Algorithm Suite A. Also, RPs are required 350 to validate signed product sets issued using only Algorithm Suite A. 352 CA X-Certificate-Algorithm-Suite-A (Cert-XA) 353 | 354 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 355 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 356 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 357 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 358 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 359 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 360 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 361 |-> CA-X-Signed-Objects-Algorithm-Suite-A 363 Note: Cert-XA represent the certificate for CA X, that is signed 364 using the algorithm suite A. 366 4.3.1. Milestone 1 368 The first milestone initiates the migration process. It updates the 369 [I-D.ietf-sidr-rpki-algs] document with the following definitions for 370 the RPKI: 372 o Algorithm Suite A 374 o Algorithm Suite B 376 Additionally, the new algorithm transition timeline document will be 377 published with the following information: 379 o CA Ready Algorithm B Date 381 o CA Go Algorithm B Date 383 o RP Ready Algorithm B Date 385 o Twilight Date 387 o EOL Date 389 o Readiness metrics for CAs and RPs in each phase 391 All Dates MUST be represented using the local UTC date-time format 392 specified in [RFC3339]. 394 4.4. Phase 1 396 Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all 397 (non-leaf) CAs MUST be ready to process a request from a child CA to 398 issue or revoke a certificate using the Algorithm B suite. If it is 399 determined that a substantial number of CAs are not ready, the 400 algorithm transition timeline document will be reissued, as noted in 401 Section 4.2. However, CAs that are capable of issuing Suite B 402 certificates may continue to do so, if requested by their child CAs. 403 Since this phase does not require any RPs to process signed objects 404 under Suite B, and since Suite B product sets SHOULD be stored at 405 independent publication points, there is no adverse impact on RPs. 406 If the Suite B algorithm is deemed unsuitable, the algorithm 407 transition timeline and the algorithm specification documents MUST be 408 replaced, CAs MUST cease accepting requests for certificates under 409 Suite B, and Suite B certificates that have been issued MUST be 410 revoked. 412 As the transition will happen using a (hierarchic) top-down model, a 413 child CA will be able to issue certificates using the Algorithm B 414 suite only after its parent CA has issued its own. The RPKI 415 provisioning protocol can identify if a parent CA is capable of 416 issuing certificates using the Algorithm Suite B, and can identify 417 the corresponding algorithm suite in each Certificate Signing Request 418 (see Section 5). 420 The following figure shows the status of repository entries for the 421 three example CAs during this Phase. Two distinct certificate chains 422 are maintained and CA Z has not yet requested any material using the 423 Algorithm B suite. 425 CA X-Certificate-Algorithm-Suite-A (Cert-XA) 426 | 427 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 428 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 429 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 430 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 431 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 432 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 433 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 434 |-> CA-X-Signed-Objects-Algorithm-Suite-A 436 CA X-Certificate-Algorithm-Suite-B (Cert-XB) 437 | 438 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB) 439 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 440 |-> CA-Y-Signed-Objects-Algorithm-Suite-B 441 |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB) 442 |-> CA-X-Signed-Objects-Algorithm-Suite-B 444 4.5. Phase 2 446 Phase 2 starts at the CA Go Algorithm B Date. At the start of this 447 phase, each signed product set MUST be available using both Algorithm 448 Suite A and Algorithm Suite B. During this phase, RPs MUST be 449 prepared to validate sets issued using Algorithm Suite A and MAY be 450 prepared to validate sets issued using the Algorithm Suite B. 452 If it is determined that a substantial number of CAs are not ready, 453 the algorithm transition timeline document will be reissued, as noted 454 in Section 4.2. (Since the processing requirement for RPs here is a 455 MAY, if RPs have problems with Suite B products this does not require 456 pushing back the Phase 2 milestone, but it does motivate delaying the 457 start of Phase 3.) CAs that are capable of publishing products under 458 Suite B MAY continue to do so. Phase 2, like Phase 1, does not 459 require any RPs to process signed objects under Suite B. Also, Suite 460 B product SHOULD be stored at independent publication points, so 461 there is no adverse impact on RPs. If the Suite B algorithm is 462 deemed unsuitable, the algorithm transition timeline and the 463 algorithm specification documents MUST be replaced. CAs MUST cease 464 accepting requests for certificates under Suite B, and Suite B 465 certificates that have been issued MUST be revoked. 467 An RP that validates all signed product sets using both Algorithm 468 Suite A or Algorithm Suite B SHOULD expect the same results. 469 However, an object that validates using either Algorithm Suite A or 470 Algorithm Suite B MUST be considered valid. A detailed analysis on 471 the validation of multiple instances of signed objects is included in 472 Section 6 473 The following figure shows the status of the repository entries for 474 the three example CAs throughout this phase, where all signed objects 475 are available using both algorithm suites. 477 CA X-Certificate-Algorithm-Suite-A (Cert-XA) 478 | 479 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 480 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 481 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 482 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 483 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 484 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 485 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 486 |-> CA-X-Signed-Objects-Algorithm-Suite-A 488 CA X-Certificate-Algorithm-Suite-B (Cert-XB) 489 | 490 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB) 491 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB) 492 |-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB) 493 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 494 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 495 |-> CA-Y-Signed-Objects-Algorithm-Suite-B 496 |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB) 497 |-> CA-X-Signed-Objects-Algorithm-Suite-B 499 4.6. Phase 3 501 Phase 3 starts at the RP Ready Algorithm B Date. During this phase, 502 all signed product sets are available using both algorithm suites and 503 all RPs MUST be able to validate them using either suite. An object 504 that validates using either Algorithm Suite A or Algorithm Suite B 505 MUST be considered valid. It is RECOMMENDED that, in preparation for 506 Phase 4, RPs utilize Suite B as the first and preferred option for 507 validation throughout this phase. Thus, for example, an RP SHOULD 508 try to validate the sets of signed products retrieved from the 509 Algorithm Suite B repository first. If this effort fails (relative 510 to the local validation policy), the RP SHOULD revert to using the 511 Algorithm Suite A repository. 513 If a substantial number of RPs are unable to process product sets 514 signed with Suite B, the algorithm transition timeline document MUST 515 be reissued, pushing back the date for this and later milestones, as 516 discussed in Section 4.2. Since the Suite B products SHOULD be 517 published at distinct publication points, RPs that cannot process 518 Suite B products can be expected to revert to the Suite A products 519 that still exist. If the Suite B algorithm is deemed unsuitable, the 520 algorithm transition timeline and the algorithm specification 521 documents MUST be replaced. CAs MUST cease accepting requests for 522 certificates under Suite B, and Suite B certificates that have been 523 issued MUST be revoked. 525 There are no changes to the CA behavior throughout this phase. 527 4.7. Phase 4 529 Phase 4 starts at the Algorithm A Twilight Date. At that date, the 530 Algorithm A is labeled as "old" and the Algorithm B is labeled as 531 "current": 533 Before Twilight --> After Twilight 535 Algorithm Suite A ("current") --> Algorithm Suite C ("old") 536 Algorithm Suite B ("new") --> Algorithm Suite A ("current") 538 During this phase, all signed product sets MUST be issued using 539 Algorithm Suite A (formerly B) and MAY be issued using Algorithm 540 Suite C (formerly A). All signed products sets issued using Suite A 541 MUST be published at their corresponding publication points, but 542 signed products sets issued using Suite C MAY NOT be published at 543 their corresponding publication points. Also, every RP MUST 544 validate signed product sets using Suite A but also MAY validate 545 signed product sets using Suite C. However, RPs SHOULD NOT assume the 546 Suite C repository is complete. 548 If it is determined that many RPs are not capable of processing the 549 new algorithm suite, the algorithm transition timeline document MUST 550 be reissued pushing back the date for this and the next milestone. 551 The document MUST requires CA to not remove Suite C product sets if 552 this phase is delayed. If the Suite B algorithm is deemed 553 unsuitable, the algorithm transition timeline and the algorithm 554 specification documents MUST be replaced. CAs MUST cease accepting 555 requests for certificates under Suite A (formal Suite A), and Suite A 556 certificates that have been issued MUST be revoked. At this stage, 557 RPs are still capable of processing Suite C signed products. 559 The following figure describes a possible status for the repositories 560 of the example CAs. In this case, CA Z no longer issues signed 561 products using the Algorithm Suite C. 563 CA X-Certificate-Algorithm-Suite-C (Cert-XC) 564 | 565 |-> CA-Y-Certificate-Algorithm-Suite-C (Cert-YC) 566 |-> CA-Y-CRL-Algorithm-Suite-C (CRL-YC) 567 |-> CA-Y-Signed-Objects-Algorithm-Suite-C 568 |-> CA-X-CRL-Algorithm-Suite-C (CRL-XC) 569 |-> CA-X-Signed-Objects-Algorithm-Suite-C 571 CA X-Certificate-Algorithm-Suite-A (Cert-XA) 572 | 573 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 574 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 575 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 576 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 577 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 578 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 579 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 580 |-> CA-X-Signed-Objects-Algorithm-Suite-A 582 4.8. Return to Phase 0 584 The EOL Algorithm Date triggers a return to Phase 0 (steady state). 585 At this phase, ALL signed product sets using Algorithm Suite C MUST 586 be considered invalid. CAs MUST neither issue nor publish signed 587 products using Algorithm Suite C. 589 This phase closes the loop as Algorithm Suite A is the only required 590 algorithm suite in RPKI. 592 If it is determined that many RPs are not capable of processing the 593 new algorithm suite, the algorithm transition timeline document MUST 594 be reissued pushing back the date for this milestone. CAs MUST NOT 595 remove Suite C product sets if this phase is delayed. 597 5. Multi Algorithm support in the RPKI provisioning protocol 599 The migration described in this document is a top-down process, where 600 two synchronization issues need to be solved between child and parent 601 CAs: 603 o A child CA needs to identify which algorithm suites are supported 604 by its parent CA 606 o A child CA needs to identify which algorithm suite should be used 607 to sign a Certificate Signing Request (CSR) 609 The RPKI provisioning protocol [I-D.ietf-sidr-rescerts-provisioning] 610 supports multiple algorithms suites by implementing different 611 resource classes for each suite. Several different resource classes 612 also may use the same algorithm suite for different resource sets. 614 A child CA that wants to identify which algorithm suites are 615 supported by its parent CA MUST perform the following tasks: 617 1. Establish a provisioning protocol session with its parent CA 619 2. Perform a "list" command as described in Section 3.3.1 of 620 [I-D.ietf-sidr-rescerts-provisioning] 622 3. From the Payload in the "list response" resource class, extract 623 the "issuer's certificate" for each class. The Algorithm Suite 624 for each class will match the Algorithm Suite used to issue the 625 corresponding "issuer's certificate". 627 A child CA that wants to specify an Algorithm Suite to its parent CA 628 (e.g., in a certificate request) MUST perform the following tasks: 630 1. Perform the tasks to identify the resource class for each 631 Algorithm Suite supported by its parent CA (as above). 633 2. Identify the corresponding resource class in the appropriate 634 provisioning protocol command (e.g. "issue" or "revoke") 636 Upon receipt of a certificate request from a child CA, a parent CA 637 will verify the PoP of the private key. If a child CA requests 638 issuing a certificate using an algorithm suite that does not match a 639 resource class, the PoP validation will fail and the request will not 640 be performed. 642 6. Validation of multiple instance of signed products 644 During Phases 1,2,3 and 4, two algorithm suites will be valid 645 simultaneously in RPKI. In this section, we describe the RP behavior 646 when validating instances of the same signed product but signed with 647 different algorithm suites. As a general rule, the validation of 648 signed products using different algorithm suites are independent and 649 the RP MUST NOT keep any relationship between the different 650 hierarchies. 652 During Phase 1 two (corresponding) instances MAY be available for 653 each signed product, one signed under Algorithm Suite A and one under 654 Algorithm Suite B. When an RP validates these signed products, if 655 either instance of an object validates, the product is accepted. A 656 failure to validate one instance of a product, under either algorithm 657 Suite MUST NOT cause the RP to reject the other instance of the 658 product. Because both instances of such products MUST contain the 659 same resources, relying on either instance will yield the same 660 outcome. 662 During Phases 2 and 3 of this process, two (corresponding) instances 663 of all signed products MUST be available to RPs. As in Phase 1, when 664 an RP validates these signed products, if either instance validates, 665 the product is accepted. A failure to validate one instance of a 666 product, under either algorithm Suite MUST NOT cause the RP to reject 667 the other instance of the product. Also, as above, if only one 668 instance of a signed product can be validated, subordinate products 669 issued under the other (non-validated) algorithm suite cannot be 670 used, and thus SHOULD NOT be processed (or even retrieved). 672 During Phase 4 two (corresponding) files for an object MAY be 673 available for each signed product, one signed under Algorithm Suite A 674 and one under Algorithm Suite C. When an RP validates these signed 675 products, if either instance of an object validates, the product is 676 accepted. A failure to validate one instance of a product, under 677 either algorithm Suite MUST NOT cause the RP to reject the other 678 instance of the product. Because both instances of such products 679 MUST contain the same resources, relying on either instance will 680 yield the same outcome. 682 7. Revocations 684 As the algorithm migration process mandates the maintenance of two 685 parallel certificate hierarchies, revocations requests for each 686 algorithm suite MUST be handled independently. A Child CA MUST 687 request revocation of a certificate relative to a specific algorithm 688 suite. 690 During phase 2 and phase 3, the two parallel certificate hierarchies 691 are designed to carry identical information. When not performing a 692 key rollover operation (which process is described in Section 8), a 693 child CA requesting the revocation of a certificate during these two 694 phases MUST perform that request for both algorithm suites (A and B). 695 A non-leaf CA is NOT required to verify that its child CAs comply 696 with this requirement. 698 8. Key rollover 700 Key rollover (without algorithm changes) is effected independently 701 for each algorithm suite and MUST follow the process described in 702 [I-D.ietf-sidr-keyroll]. 704 9. Repository structure 706 The two parallel hierarchies that will exist during the transition 707 process SHOULD have independent publications points. The repository 708 structures for each algorithm suite are described in 709 [I-D.ietf-sidr-repos-struct]. 711 10. IANA Considerations 713 No IANA requirements 715 11. Security Considerations 717 An algorithm transition in RPKI should be a very infrequent event and 718 it requires wide community consensus. The events that may lead to an 719 algorithm transition may be related to a weakness of the 720 cryptographic strength of the algorithm suite in use by RPKI, which 721 is normal to happen over time. The procedure described in this 722 document will take years to complete an algorithm transition. During 723 that time, the RPKI system will be vulnerable to any cryptographic 724 weakness that may have triggered this procedure (i.e. downgrade 725 attack). 727 This document does not describe an emergency mechanism for algorithm 728 migration. Due to the distributed nature of RPKI, and the very large 729 number of CAs and RPs, the authors do not believe it is feasible to 730 effect an emergency algorithm migration procedure. 732 If a CA does not complete its migration to the new algorithm suite as 733 described in this document (after the EOL of the "old" algorithm 734 suite), its signed product set will no longer be valid. 735 Consequently, the RPKI may, at the end of Phase 4, have a smaller 736 number of valid signed products than before starting the process. 737 Conversely, a RP that does not follow this process will lose the 738 ability to validate signed products issued under the new algorithm 739 suite. The resulting incomplete view of routing info from the RPKI 740 (as a result of a failure by CAs or RPs to complete the transition) 741 could degrade routing in the public Internet. 743 12. Acknowledgements 745 The authors would like to acknowledge the work of the SIDR working 746 group co-chairs (Sandra Murphy and Chris Morrow) as well as the 747 contributions given by Geoff Huston, Arturo Servin, Brian Weis, Terry 748 Manderson, Brian Dickson and Danny McPherson. 750 13. References 752 13.1. Normative References 754 [I-D.ietf-sidr-cp] 755 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 756 Policy (CP) for the Resource PKI (RPKI", 757 draft-ietf-sidr-cp-17 (work in progress), April 2011. 759 [I-D.ietf-sidr-keyroll] 760 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 761 in the RPKI", draft-ietf-sidr-keyroll-05 (work in 762 progress), December 2010. 764 [I-D.ietf-sidr-repos-struct] 765 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 766 Resource Certificate Repository Structure", 767 draft-ietf-sidr-repos-struct-06 (work in progress), 768 November 2010. 770 [I-D.ietf-sidr-res-certs] 771 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 772 X.509 PKIX Resource Certificates", 773 draft-ietf-sidr-res-certs-21 (work in progress), 774 December 2010. 776 [I-D.ietf-sidr-rescerts-provisioning] 777 Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 778 Protocol for Provisioning Resource Certificates", 779 draft-ietf-sidr-rescerts-provisioning-10 (work in 780 progress), June 2011. 782 [I-D.ietf-sidr-rpki-algs] 783 Huston, G., "A Profile for Algorithms and Key Sizes for 784 use in the Resource Public Key Infrastructure", 785 draft-ietf-sidr-rpki-algs-04 (work in progress), 786 November 2010. 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, March 1997. 791 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 792 Adams, "X.509 Internet Public Key Infrastructure Online 793 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 795 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 796 Internet: Timestamps", RFC 3339, July 2002. 798 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 799 Addresses and AS Identifiers", RFC 3779, June 2004. 801 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 802 Addresses", RFC 4193, October 2005. 804 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 805 Housley, R., and W. Polk, "Internet X.509 Public Key 806 Infrastructure Certificate and Certificate Revocation List 807 (CRL) Profile", RFC 5280, May 2008. 809 13.2. Informative References 811 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 812 Scheme", RFC 5781, February 2010. 814 Appendix A. Change Log 816 Note to the RFC Editor: Please remove this section before 817 publication. 819 From 04 to 05: 821 1. WGLC nits 823 From 03 to 04: 825 1. Added text for "roll-over" capability in each phase 827 2. Added the requirement for splitting the milestone 1 in two 828 documents: the update of the alg document and a new document 829 specifying the particular timelines 831 3. WGLC nits 833 From 02 to 03: 835 1. Explicitely named than "mixed" certificates are not allowed for 836 CA certs but may be possible for EE certs that are not used to 837 validate repository objects. 839 From 01 to 02: 841 1. Add reference to Multi-Objects validation 843 2. EOL Data is the only milestone that RP and CA take actions "at 844 the same time". 846 3. Updated references 848 4. Editorial 850 From 00 to 01: 852 1. Include text to clarify former Suites 854 2. Include text that documents that an RP that validates an object 855 signed with either suites in Phase 2 MUST consider it as valid 857 From individual submission to WG item: 859 1. Change form "laisez faire" to "top-down" 860 2. Included Multi Algorithm support in the RPKI provisioning 861 protocol 863 3. Included Validation of multiple instance of signed products 865 4. Included Revocations 867 5. Included Key rollover 869 6. Included Repository structure 871 7. Included Security Considerations 873 8. Included Acknowledgements 875 Authors' Addresses 877 Roque Gagliano 878 Cisco Systems 879 Avenue des Uttins 5 880 Rolle, 1180 881 Switzerland 883 Email: rogaglia@cisco.com 885 Stephen Kent 886 BBN Technologies 887 10 Moulton St. 888 Cambridge, MA 02138 889 USA 891 Email: kent@bbn.com 893 Sean Turner 894 IECA, Inc. 895 3057 Nutley Street, Suite 106 896 Fairfax, VA 22031 897 USA 899 Email: turners@ieca.com