idnits 2.17.00 (12 Aug 2021) /tmp/idnits46319/draft-ietf-sidr-algorithm-agility-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: ---------------------------------------------------------------------------- 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 document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (June 26, 2012) is 3615 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) == Missing Reference: 'RFC6493' is mentioned on line 675, but not defined ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6490 (Obsoleted by RFC 7730) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: December 28, 2012 BBN Technologies 6 S. Turner 7 IECA, Inc. 8 June 26, 2012 10 Algorithm Agility Procedure for RPKI. 11 draft-ietf-sidr-algorithm-agility-06 13 Abstract 15 This document specifies the process that Certification Authorities 16 (CAs) and Relying Parties (RPs) 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 December 28, 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. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 9. Repository structure . . . . . . . . . . . . . . . . . . . . . 20 76 10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 21 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 79 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 80 14. Normative References . . . . . . . . . . . . . . . . . . . . . 26 81 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 84 1. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Introduction 92 The RPKI must accommodate transitions between the public keys used by 93 CAs. Transitions of this sort are usually termed "key rollover". 94 Planned key rollover will occur at regular intervals throughout the 95 life of the RPKI, as each CA changes its public keys, in a non- 96 coordinated fashion. (By non-coordinated we mean that the time at 97 which each CA elects to change its keys is locally determined, not 98 coordinated across the RPKI.) Moreover, because a key change might 99 be necessitated by suspected private key compromise, one can never 100 assume coordination of these events among all of the CAs in the RPKI. 101 In an emergency key rollover, the old certificate is revoked and a 102 new certificate with a new key is issued. The mechanisms to perform 103 a key rollover in RPKI (either planned or in an emergency), while 104 maintaining the same algorithm suite, are covered in [RFC6489]. 106 This document describes the mechanism to perform a key rollover in 107 RPKI due to the migration to a new signature algorithm suite. A 108 signature algorithm suite encompasses both a signature algorithm 109 (with a specified key size range) and a one-way hash algorithm. It 110 is anticipated that the RPKI will require the adoption of updated key 111 sizes and/or different algorithm suites over time. This document 112 treats the adoption of a new hash algorithm while retaining the 113 current signature algorithm as equivalent to an algorithm migration, 114 and requires the CA to change its key. Migration to a new algorithm 115 suite will be required in order to maintain an acceptable level of 116 cryptographic security and protect the integrity of certificates, 117 CRLs and signed objects in the RPKI. All of the data structures in 118 the RPKI explicitly identify the signature and hash algorithms being 119 used. However, experience has demonstrated that the ability to 120 represent algorithm IDs is not sufficient to enable migration to new 121 algorithm suites (algorithm agility). One also must ensure that 122 protocols, infrastructure elements, and operational procedures also 123 accommodate the migration from one algorithm suite to another. 124 Algorithm migration is expected to be very infrequent and it will 125 require support of a "current" and "next" suite for a prolonged 126 interval, probably several years. 128 This document defines how entities in the RPKI execute (planned) CA 129 key rollover when the algorithm suite changes. The description 130 covers actions by CAs, repository operators, and RPs. It describes 131 the behavior required of both CAs and RPs to make such key changes 132 work in the RPKI context, including how the RPKI repository system is 133 used to support key rollover. 135 This document does not specify any algorithm suite per se. The RPKI 136 Certificate Policy (CP) [RFC6484] mandates the use of the algorithms 137 defined in [RFC6485] by CAs and RPs. When an algorithm transition is 138 initiated, [RFC6485] will be updated (as defined in Section 4.1 of 139 this document) redefining the required algorithm(s) for compliant 140 RPKI CAs and RPs under the CP. The CP will not change as a side 141 effect of algorithm transition (and thus the policy OID in RPKI 142 certificates will not change.) 144 An additional document, the algorithm transition timetable, will be 145 published (as an IETF BCP) to define the dates for each milestone 146 defined in this document. It will define dates for the phase 147 transitions, consistent with the descriptions provided in Section 4. 148 It also will describe how the RPKI community will measure the 149 readiness of CAs and RPs to transition to each phase. CAs publish 150 certificates, CRLs, and other signed objects under the new algorithm 151 suite as the transition progresses. This provides visibility into 152 the deployment of the new algorithm suite, enabling the community to 153 evaluate deployment progress. The transition procedure allows CAs to 154 remove old certificates, CRLs, and signed products, after the 155 twilight date. This provides an ability to observe and measure the 156 withdrawal of the old algorithm suite. Thus the phases defined in 157 this document enable the community to evaluate the progress of the 158 transition. The timetable document will also describe procedures to 159 amend the timetable if problems arise in implementing later phases of 160 the transition. It is RECOMMENDED that the timetable document be 161 developed by representatives of the RPKI community, e.g., IANA, 162 Internet Registries, and network operators. 164 3. Terminology 166 This document assumes that the reader is familiar with the terms and 167 concepts described in "Internet X.509 Public Key Infrastructure 168 Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], 169 "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 170 "A Profile for Resource Certificate Repository Structure" [RFC6481]. 171 Additional terms and conventions used in examples are provided below. 173 Algorithm migration: A planned transition from one signature and 174 hash algorithm to a new signature and hash algorithm. 176 Algorithm Suite A: The "current" algorithm suite used for hashing 177 and signing, in examples in this document 179 Algorithm Suite B: The "next" algorithm suite used for hashing and 180 signing, used in examples in this document 182 Algorithm Suite C: The "old" algorithm suite used for hashing and 183 signing, used in examples in this document 185 CA X: The CA that issued CA Y's certificate (i.e., CA Y's 186 parent), used in examples in this document. 188 CA Y: The non-leaf CA used in examples this document 190 CA Z: A CA that is a "child" of CA Y, used in examples this 191 document 193 Non-Leaf CA: A CA that issues certificates to other CAs is a non- 194 leaf CA. 196 Leaf CA: A leaf CA is a CA that issues only EE certs. 198 PoP (proof of possession): Execution of a protocol that demonstrates 199 to an issuer that a subject requesting a certificate 200 possesses the private key corresponding to the public key 201 in the certificate request submitted by the subject. 203 Signed Product Set (or Set or Product Set): A collection of 204 certificates, signed objects, a CRL and a manifest that 205 are associated by virtue of being verifiable under the 206 same parent CA certificate 208 4. Key Rollover steps for algorithm migration 210 The "current" RPKI algorithm suite (Suite A) is defined in the RPKI 211 CP document, by reference to [RFC6485]. When a migration of the RPKI 212 algorithm suite is needed, the first step MUST be an update of 213 [RFC6485] to define the new algorithm suite. The algorithm 214 transition timeline document MUST also be published (as a BCP), to 215 inform the community of the dates selected for milestones in the 216 transition process, as described in Section 4.1. 218 4.1. Milestones definition 220 CA Ready Algorithm B Date: After this date, all (non-leaf) CAs MUST 221 be ready to process a request from a child CA to issue a 222 certificate under the Algorithm Suite B. All CAs 223 publishing an [RFC6490] Trust Anchor Locator (TAL) for 224 Algorithm Suite A, MUST also publish the correspondent 225 TAL for Algorithm Suite B. 227 CA Go Algorithm B Date: After this date, all CAs MUST have reissued 228 all of their signed product sets under the Algorithm 229 Suite B. 231 RP Ready Algorithm B Date: After this date, all RPs MUST be prepared 232 to process signed material issued under the Algorithm 233 Suite B. 235 Twilight Date: After this date, a CA MAY cease issuing signed 236 products under the Algorithm Suite A. Also, after this 237 date, a RP MAY cease to validate signed materials issued 238 under the Algorithm Suite A. 240 End Of Life (EOL) Date: After this date, the Algorithm Suite C is 241 MUST be deprecated using the process in Section 10 and 242 all Algorithm Suite C TALs MUST be removed from their 243 publication points. 245 4.2. Process overview 247 The migration process described in this document involves a series of 248 steps that MUST be executed in chronological order by CAs and RPs. 249 The only milestone at which both CAs and RPs take action at the same 250 time is the EOL Date. Due to the decentralized nature of the RPKI 251 infrastructure, it is expected that an algorithm transition will span 252 several years. 254 In order to facilitate the transition, CAs will start issuing 255 certificates using the Algorithm B in a hierarchical top-down 256 fashion. In our example, CA Y will issue certificates using the 257 Algorithm Suite B only after CA X has started to do so (CA Y Ready 258 Algorithm B Date > CA X Ready Algorithm B Date). This ordered 259 transition avoids issuance of "mixed" suite CA certificates, e.g., a 260 CA certificate signed using Suite A, containing a key from Suite B. 261 In the RPKI, a CA MUST NOT sign a CA certificate carrying a subject 262 key that corresponds to an algorithm suite that differs from the one 263 used to sign the certificate. (X.509 accommodates such mixed 264 algorithm certificates, but this process avoids using that 265 capability.) A not top-down transition approach would require use of 266 such mixed mode certificates, and would lead to exponential growth of 267 the RPKI repository. Also, because the RPKI CP mandates Proof of 268 Possession (PoP) for certificate requests, it is not possible for a 269 CA to request a certificate for Algorithm Suite B, until its parent 270 CA supports that Suite. (See Section 5 for more details.) 272 The algorithm agility model described here does not prohibit a CA 273 from issuing an EE certificate with a subject public key from a 274 different algorithm suite, if that certificate is not used to verify 275 repository objects. This exception to the mixed algorithm suite 276 certificate rule is allowed because an EE certificate that is not 277 used to verify repository objects does not interfere with the ability 278 of RPs to download and verify repository content. As noted above, 279 every CA in the RPKI is required to perform a PoP check for the 280 subject public key when issuing a certificate. In general a subject 281 cannot assume that a CA is capable of supporting a different 282 algorithm. However, if the subject is closely affiliated with the 283 CA, it is reasonable to assume that there are ways for the subject to 284 know whether the CA can support a request to issue an EE certificate 285 containing a specific, different public key algorithm. This document 286 does not specify how a subject can determine whether a CA is capable 287 of issuing a mixed suite EE certificate, because it anticipates that 288 such certificates will be issued only in contexts where the subject 289 and CA are sufficiently closely affiliated (for example, an ISP 290 issuing certificates to devices that it manages). 292 The following figure gives an overview of the process: 294 Process for RPKI CAs: 296 Phase 0 Phase 1 Phase 2 Phase 4 Phase 0 297 -----------x---------x-------------------x--------x----------- 298 ^ ^ ^ ^ ^ 299 | | | | | 300 (1) (2) (3) (5) (6) 302 Process for RPKI RPs: 304 Phase 0 Phase 3 Phase 4 Phase 0 305 -------------------------------x---------x--------x----- 306 ^ ^ ^ ^ 307 | | | | 308 (1) (4) (5) (6) 310 (1) RPKI algorithm document is updated and the algorithm transition timeline document is issued 311 (2) CA Ready Algorithm B Date 312 (3) CA Go Algorithm B Date 313 (4) RP Ready Algorithm B Date 314 (5) Twilight Date 315 (6) End Of Live (EOL) Date 317 Each of these milestones is discussed in the next section when 318 describing each phase of the transition process. 320 Two situations have been identified that motivate pausing or rolling 321 back the transition process. The first situation arises if the RPKI 322 community is not ready to make the transition. For example, many CAs 323 might not be prepared to issue signed products under Suite B, or many 324 RPs might not be ready to process Suite B products. Under these 325 circumstances, the timetable MUST be reissued, postponing the date 326 for the phase in question, and pushing back the dates for later 327 phases. The other situation arises if, during the transition, 328 serious concerns arise about the security of the Suite B algorithms. 329 Such concerns would motivate terminating the transition and rolling 330 back signed products, i.e., reverting to Suite A. In this case the 331 timetable MUST be republished, and the RPKI algorithm document MUST 332 be superseded. The phase descriptions below allude to these two 333 situations, as appropriate. 335 4.3. Phase 0 337 Phase 0 is the initial phase of the process, throughout this phase 338 the algorithm suite A is the only supported algorithm suite in RPKI. 339 This is also the steady state for the RPKI. 341 The following figure illustrates the format used to describe signed 342 objects in the repository. It reflects the algorithm suites in use, 343 and shows the relationship between three CAs (X, Y, and Z) that form 344 a chain. 346 During Phase 0, CAs X, Y and Z are required to generate signed 347 product sets using only the Algorithm Suite A. Also, RPs are required 348 to validate signed product sets issued using only Algorithm Suite A. 350 CA X-Certificate-Algorithm-Suite-A (Cert-XA) 351 | 352 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 353 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 354 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 355 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 356 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 357 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 358 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 359 |-> CA-X-Signed-Objects-Algorithm-Suite-A 361 Note: Cert-XA represent the certificate for CA X, that is signed 362 using the algorithm suite A. 364 4.3.1. Milestone 1 366 The first milestone initiates the migration process. It updates 367 [RFC6485] with the following definitions for the RPKI: 369 o Algorithm Suite A 371 o Algorithm Suite B 373 Additionally, the new algorithm transition timeline document will be 374 published with the following information: 376 o CA Ready Algorithm B Date 378 o CA Go Algorithm B Date 380 o RP Ready Algorithm B Date 382 o Twilight Date 384 o EOL Date 386 o Readiness metrics for CAs and RPs in each phase 388 Each date specified here is assumed at one minute after midnight, 389 UTC. No finer granularity time specification is required or 390 supported. 392 4.4. Phase 1 394 Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all 395 (non-leaf) CAs MUST be ready to process a request from a child CA to 396 issue or revoke a certificate using the Algorithm Suite B. If it is 397 determined that a substantial number of CAs are not ready, the 398 algorithm transition timeline document will be reissued, as noted in 399 Section 4.2. However, CAs that are capable of issuing Suite B 400 certificates may continue to do so, if requested by their child CAs. 401 Since this phase does not require any RPs to process signed objects 402 under Suite B, and since Suite B product sets SHOULD be stored at 403 independent publication points, there is no adverse impact on RPs. 404 If the Suite B algorithm is deemed unsuitable, the algorithm 405 transition timeline and the algorithm specification documents MUST be 406 replaced, the Algorithm Suite B MUST be deprecated using the process 407 described in Section 10. 409 As the transition will happen using a (hierarchic) top-down model, a 410 child CA will be able to issue certificates using the Algorithm Suite 411 B only after its parent CA has issued its own. The RPKI provisioning 412 protocol can identify if a parent CA is capable of issuing 413 certificates using the Algorithm Suite B, and can identify the 414 corresponding algorithm suite in each Certificate Signing Request 415 (see Section 5). During much of this phase the Suite B product tree 416 will be incomplete, i.e., not all CAs will have issued products under 417 Suite B. Thus for production purposes, RPs MUST fetch and validate 418 only Suite A products. Suite B products should be fetched and 419 processed only for testing purposes. 421 The following figure shows the status of repository entries for the 422 three example CAs during this Phase. Two distinct certificate chains 423 are maintained and CA Z has not yet requested any material using the 424 Algorithm Suite B. 426 CA X-Certificate-Algorithm-Suite-A (Cert-XA) 427 | 428 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 429 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 430 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 431 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 432 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 433 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 434 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 435 |-> CA-X-Signed-Objects-Algorithm-Suite-A 437 CA X-Certificate-Algorithm-Suite-B (Cert-XB) 438 | 439 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB) 440 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 441 |-> CA-Y-Signed-Objects-Algorithm-Suite-B 442 |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB) 443 |-> CA-X-Signed-Objects-Algorithm-Suite-B 445 4.5. Phase 2 447 Phase 2 starts at the CA Go Algorithm B Date. At the start of this 448 phase, each signed product set MUST be available using both Algorithm 449 Suite A and Algorithm Suite B. During this phase, RPs MUST be 450 prepared to validate sets issued using Algorithm Suite A and MAY be 451 prepared to validate sets issued using the Algorithm Suite B. 453 If it is determined that a substantial number of CAs are not ready, 454 the algorithm transition timeline document will be reissued, as noted 455 in Section 4.2. (Since the processing requirement for RPs here is a 456 MAY, if RPs have problems with Suite B products this does not require 457 pushing back the Phase 2 milestone, but it does motivate delaying the 458 start of Phase 3.) CAs that are capable of publishing products under 459 Suite B MAY continue to do so. Phase 2, like Phase 1, does not 460 require any RPs to process signed objects under Suite B. Also, Suite 461 B product SHOULD be stored at independent publication points, so 462 there is no adverse impact on RPs that are not prepared to process 463 suite B products. If the Suite B algorithm is deemed unsuitable, the 464 algorithm transition timeline and the algorithm specification 465 documents MUST be replaced and the Algorithm Suite B MUST be 466 deprecated using the process described in Section 10. 468 It is RECOMMENDED that RPs that can process Algorithm Suite B fetch 469 and validate Suite B products. RPs that are not ready to process 470 Suite B products MUST continue to make use of Suite A products. An 471 RP that elects to validate signed product sets using both Algorithm 472 Suite A or Algorithm Suite B should expect the same results. If 473 there are discrepancies when evaluating corresponding signed product 474 sets, successful validation of either product set is acceptable. A 475 detailed analysis of the validation of multiple instances of signed 476 objects is included in Section 6. 478 The following figure shows the status of the repository entries for 479 the three example CAs throughout this phase, where all signed objects 480 are available using both algorithm suites. 482 CA X-Certificate-Algorithm-Suite-A (Cert-XA) 483 | 484 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 485 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 486 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 487 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 488 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 489 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 490 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 491 |-> CA-X-Signed-Objects-Algorithm-Suite-A 493 CA X-Certificate-Algorithm-Suite-B (Cert-XB) 494 | 495 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB) 496 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB) 497 |-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB) 498 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 499 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 500 |-> CA-Y-Signed-Objects-Algorithm-Suite-B 501 |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB) 502 |-> CA-X-Signed-Objects-Algorithm-Suite-B 504 4.6. Phase 3 506 Phase 3 starts at the RP Ready Algorithm B Date. During this phase, 507 all signed product sets are available using both algorithm suites and 508 all RPs MUST be able to validate them. It is RECOMMENDED that, in 509 preparation for Phase 4, RPs retrieve and process Suite B product 510 sets first, and treat them as the preferred product sets for 511 validation throughout this phase. Thus an RP SHOULD try to validate 512 the sets of signed products retrieved from the Algorithm Suite B 513 repository first. 515 If a substantial number of RPs are unable to process product sets 516 signed with Suite B, the algorithm transition timeline document MUST 517 be reissued, pushing back the date for this and later milestones, as 518 discussed in Section 4.2. Since the Suite B products SHOULD be 519 published at distinct publication points, RPs that cannot process 520 Suite B products can be expected to revert to the Suite A products 521 that still exist. If the Suite B algorithm is deemed unsuitable, the 522 algorithm transition timeline and the algorithm specification 523 documents MUST be replaced and the Algorithm Suite B MUST be 524 deprecated using the process described in Section 10. 526 There are no changes to the CA behavior throughout this phase. 528 4.7. Phase 4 530 Phase 4 starts at the Twilight Date. At that date, the Algorithm A 531 is labeled as "old" and the Algorithm B is labeled as "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. Signed 542 products sets issued using Suite C might not be available at their 543 corresponding publication points. Every RP MUST validate signed 544 product sets using Suite A. RPs MAY validate signed product sets 545 using Suite C. However, RPs SHOULD NOT assume that the collection of 546 Suite C product sets is complete. Thus RPs SHOULD make use of only 547 Suite A products sets. (See Section 6 for further details.) 549 If it is determined that many RPs are not capable of processing the 550 new algorithm suite, the algorithm transition timeline document MUST 551 be reissued pushing back the date for this and the next milestone. 552 The document MUST require CA to not remove Suite C product sets if 553 this phase is delayed. If the Algorithm Suite A (former Algorithm 554 Suite B) is deemed unsuitable, the algorithm transition timeline and 555 the algorithm specification documents MUST be replaced and the 556 Algorithm Suite A MUST be deprecated using the process described in 557 Section 10. At this stage, RPs are still capable of processing Suite 558 C signed products, so the RPKI is still viable. 560 The following figure describes a possible status for the repositories 561 of the example CAs. 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 Date triggers the return to Phase 0 (steady state). At this 585 point, the Algorithm Suite C MUST be deprecated using the process 586 described in Section 10. 588 This phase closes the loop as Algorithm Suite A is the only required 589 algorithm suite in RPKI. 591 If it is determined that many RPs are not capable of processing the 592 new algorithm suite, the algorithm transition timeline document MUST 593 be reissued pushing back the date for this milestone. 595 5. Multi Algorithm support in the RPKI provisioning protocol 597 The migration described in this document is a top-down process, where 598 two synchronization issues need to be solved between child and parent 599 CAs: 601 o A child CA needs to identify which algorithm suites are supported 602 by its parent CA 604 o A child CA needs to signal which algorithm suite should be used by 605 its parent CA to sign a Certificate Signing Request (CSR) 607 The RPKI provisioning protocol [RFC6492] supports multiple algorithms 608 suites by implementing different resource classes for each suite. 609 Several different resource classes also may use the same algorithm 610 suite for different resource sets. 612 A child CA that wants to identify which algorithm suites are 613 supported by its parent CA MUST perform the following tasks: 615 1. Establish a provisioning protocol session with its parent CA 617 2. Perform a "list" command as described in Section 3.3.1 of 618 [RFC6492] 620 3. From the Payload in the "list response" resource class, extract 621 the "issuer's certificate" for each class. The Algorithm Suite 622 for each class will match the Algorithm Suite used to issue the 623 corresponding "issuer's certificate" (as specified in the 624 SubjectPublicKeyInfo field of that certificate) 626 A child CA that wants to specify an Algorithm Suite to its parent CA 627 (e.g., in a certificate request) MUST perform the following tasks: 629 1. Perform the tasks described above to identify the algorithm 630 suites supported by its parent CA, and the resource class 631 corresponding to each suite 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 corresponding instances of the same signed product 647 signed with different algorithm suites. 649 During Phase 1 two (corresponding) instances MAY be available for 650 each signed product, one signed under Algorithm Suite A and one under 651 Algorithm Suite B. As noted in Section 4.4, in this phase there is a 652 preference for Suite A product sets. All products are available 653 under Suite A, while only some products may be available under Suite 654 B. For production purposes an RP MAY fetch and validate only Suite A 655 products. Suite B products SHOULD be fetched and validated only for 656 test purposes. When product sets exist under both Suites, they 657 should yield equivalent results, which facilitates testing. (It is 658 not possible to directly compare Suite A and Suite B product sets, as 659 certs, CRLs, and manifests will appear syntactically different. 660 However, the output of the process, i.e., the ROA payloads (ASN and 661 prefix data), SHOULD match, modulo timing issues.) 663 During Phases 2 and 3 of this process, two (corresponding) instances 664 of all signed products MUST be available to RPs. As noted in Section 665 4.5, it is RECOMMENDED that Suite B capable RPs fetch and validate 666 Suite B products sets, during Phase 2. If an RP encounters 667 validation problems with the Suite B products, it SHOULD revert to 668 using Suite A products. RPs that are Suite B capable MAY fetch both 669 product sets and compare the results (e.g., ROA outputs) for testing. 671 In Phase 3 all RPs MUST be Suite B capable, and MUST fetch Suite B 672 product sets. If an RP encounters problems with Suite B product 673 sets, it can revert to Suite A products. RPs encountering such 674 problems SHOULD contact the relevant repository maintainers (e.g., 675 using the mechanism defined in [RFC6493] to report problems.) 677 During Phase 4 only Suite A (previously Suite B) product sets are 678 required to be present for all RPKI entities, as per Section 4.7. 679 Thus RPs SHOULD retrieve and validate only these product sets. 680 Retrieval of Suite C (old Suite A) products sets may yield an 681 incomplete set of signed products and is NOT RECOMMENDED. 683 7. Revocation 685 The algorithm migration process mandates the maintenance of two 686 parallel but equivalent certification hierarchies during Phases 2 and 687 3 of the process. During these phases, a CA MUST revoke certificates 688 consistently under both algorithm Suites. When not performing a key 689 rollover operation (as described in Section 8), a CA requesting the 690 revocation of its certificate during these two phases MUST perform 691 that request for both algorithm suites (A and B). A non-leaf CA 692 SHOULD NOT verify that its child CAs comply with this requirement. 693 Note that a CA MUST request revocation of its certificate relative to 694 a specific algorithm suite using the mechanism described in Section 5 696 During Phase 1, a CA that revokes a certificate under Suite A SHOULD 697 revoke the corresponding certificate under Suite B, if that 698 certificate exists. During Phase 4, a CA that revokes a certificate 699 under Suite A SHOULD revoke the corresponding certificate under Suite 700 C, if that certificate exists. 702 During Phase 1, a CA may revoke certificates under Suite B without 703 revoking them under Suite A, since the Suite B products are for test 704 purposes. During Phase 4 a CA may revoke certificates issued under 705 Suite C without revoking them under Suite A, since Suite C products 706 are being deprecated. 708 8. Key rollover 710 Key rollover (without algorithm changes) is effected independently 711 for each algorithm suite and MUST follow the process described in 712 [RFC6489]. 714 9. Repository structure 716 The two parallel hierarchies that will exist during the transition 717 process SHOULD have independent publications points. The repository 718 structures for each algorithm suite are described in [RFC6481]. 720 10. Deprecating an Algorithm Suite 722 To deprecate an algorithm suite, the following process MUST be 723 executed by every CA in the RPKI: 725 1. Each CA MUST cease issuing certificates under the suite. This 726 means that any request for a (CA) certificate from a child will 727 be rejected, e.g., sending an error_response message with error 728 code:"request - no such resource class" as defined in [RFC6492]. 730 2. Each CA MUST cease generating signed products, except the CRL and 731 Manifest, under the deprecated Algorithm Suite. 733 3. Each CA MUST revoke the EE certificates for all signed products 734 that it has issued under the deprecated Algorithm Suite. The CA 735 SHOULD delete these products from its publication point, to avoid 736 burdening RPs with downloading and processing these products. 738 4. Each CA MUST revoke all CA certificates that it has issued under 739 the deprecated Algorithm Suite. 741 5. Each CA SHOULD remove all CA certificates that it has issued 742 under the deprecated Algorithm Suite. 744 6. Each CA that publishes a TAL under the deprecated Algorithm Suite 745 MUST removed it from the TAL's publication point. 747 7. Each CA SHOULD continue to maintain the publication point for the 748 deprecated Algorithm Suite, maintained at least until the CRL 749 nextUpdate. This publication point MUST contain only he CRL and 750 a Manifest for that publication point. This behavior provides a 751 window in which RPs may be able to become aware of the revoked 752 status of the signed products that have been deleted. 754 8. Each RP MUST remove any TALs that is has published under the 755 deprecated Algorithm Suite. 757 CAs in the RPKI hierarchy may become aware of the deprecation of the 758 algorithm suite at different times, and may execute the procedure 759 above in an asynchronous fashion relative to one another. Thus, for 760 example, a CA may request revocation of its CA certificate only to 761 learn that the certificate has already been revoked by the issuing 762 CA. The revocation of a CA certificate makes the CRL and manifest 763 issued under it incapable of validation. The asynchronous execution 764 of this procedure likely will result in transient "inconsistencies" 765 among the publication points associated with the deprecated algorithm 766 suite. However, these inconsistencies should yield "fail safe" 767 results, i.e., the objects signed under the deprecated suite should 768 be rejected by RPs. 770 11. IANA Considerations 772 No IANA requirements 774 12. Security Considerations 776 An algorithm transition in RPKI should be a very infrequent event and 777 it requires wide community consensus. The events that may lead to an 778 algorithm transition may be related to a weakness of the 779 cryptographic strength of the algorithm suite in use by RPKI, which 780 is normal to happen over time. The procedure described in this 781 document will take years to complete an algorithm transition. During 782 that time, the RPKI system will be vulnerable to any cryptographic 783 weakness that may have triggered this procedure (i.e. downgrade 784 attack). 786 This document does not describe an emergency mechanism for algorithm 787 migration. Due to the distributed nature of RPKI, and the very large 788 number of CAs and RPs, the authors do not believe it is feasible to 789 effect an emergency algorithm migration procedure. 791 If a CA does not complete its migration to the new algorithm suite as 792 described in this document (after the EOL of the "old" algorithm 793 suite), its signed product set will no longer be valid. 794 Consequently, the RPKI may, at the end of Phase 4, have a smaller 795 number of valid signed products than before starting the process. 796 Conversely, a RP that does not follow this process will lose the 797 ability to validate signed products issued under the new algorithm 798 suite. The resulting incomplete view of routing info from the RPKI 799 (as a result of a failure by CAs or RPs to complete the transition) 800 could degrade routing in the public Internet. 802 13. Acknowledgements 804 The authors would like to acknowledge the work of the SIDR working 805 group co-chairs (Sandra Murphy and Chris Morrow) as well as the 806 contributions given by Geoff Huston, Arturo Servin, Brian Weis, Terry 807 Manderson, Brian Dickson and Danny McPherson. 809 14. Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 815 Addresses and AS Identifiers", RFC 3779, June 2004. 817 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 818 Housley, R., and W. Polk, "Internet X.509 Public Key 819 Infrastructure Certificate and Certificate Revocation List 820 (CRL) Profile", RFC 5280, May 2008. 822 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 823 Resource Certificate Repository Structure", RFC 6481, 824 February 2012. 826 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 827 Policy (CP) for the Resource Public Key Infrastructure 828 (RPKI)", BCP 173, RFC 6484, February 2012. 830 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 831 Use in the Resource Public Key Infrastructure (RPKI)", 832 RFC 6485, February 2012. 834 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 835 Authority (CA) Key Rollover in the Resource Public Key 836 Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012. 838 [RFC6490] "". 840 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 841 Protocol for Provisioning Resource Certificates", 842 RFC 6492, February 2012. 844 Appendix A. Change Log 846 Note to the RFC Editor: Please remove this section before 847 publication. 849 From 05 to 06: 851 1. Added reference to published RFCs 853 2. Removed requirement on dates format 855 3. Changed revocation section to emphasize the differences between 856 phase 1,2,3 and 4. 858 4. Added Section 10: Deprecating an Algorithm Suite 860 5. Typos and editoral changes 862 From 04 to 05: 864 1. WGLC nits 866 From 03 to 04: 868 1. Added text for "roll-over" capability in each phase 870 2. Added the requirement for splitting the milestone 1 in two 871 documents: the update of the alg document and a new document 872 specifying the particular timelines 874 3. WGLC nits 876 From 02 to 03: 878 1. Explicitely named than "mixed" certificates are not allowed for 879 CA certs but may be possible for EE certs that are not used to 880 validate repository objects. 882 From 01 to 02: 884 1. Add reference to Multi-Objects validation 886 2. EOL Date is the only milestone that RP and CA take actions "at 887 the same time". 889 3. Updated references 890 4. Editorial 892 From 00 to 01: 894 1. Include text to clarify former Suites 896 2. Include text that documents that an RP that validates an object 897 signed with either suites in Phase 2 MUST consider it as valid 899 From individual submission to WG item: 901 1. Change form "laisez faire" to "top-down" 903 2. Included Multi Algorithm support in the RPKI provisioning 904 protocol 906 3. Included Validation of multiple instance of signed products 908 4. Included Revocations 910 5. Included Key rollover 912 6. Included Repository structure 914 7. Included Security Considerations 916 8. Included Acknowledgements 918 Authors' Addresses 920 Roque Gagliano 921 Cisco Systems 922 Avenue des Uttins 5 923 Rolle, 1180 924 Switzerland 926 Email: rogaglia@cisco.com 928 Stephen Kent 929 BBN Technologies 930 10 Moulton St. 931 Cambridge, MA 02138 932 USA 934 Email: kent@bbn.com 936 Sean Turner 937 IECA, Inc. 938 3057 Nutley Street, Suite 106 939 Fairfax, VA 22031 940 USA 942 Email: turners@ieca.com