idnits 2.17.1 draft-ietf-sidr-algorithm-agility-12.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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 8, 2013) is 4096 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) ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6490 (Obsoleted by RFC 7730) Summary: 3 errors (**), 0 flaws (~~), 2 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: BCP S. Kent 5 Expires: August 12, 2013 BBN Technologies 6 S. Turner 7 IECA, Inc. 8 February 8, 2013 10 Algorithm Agility Procedure for RPKI. 11 draft-ietf-sidr-algorithm-agility-12 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 several 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 August 12, 2013. 41 Copyright Notice 43 Copyright (c) 2013 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 . . . . . . . . . . 8 62 4.1. Milestones definition . . . . . . . . . . . . . . . . . . 8 63 4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 8 64 4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 11 66 4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 16 71 5. Multi Algorithm support in the RPKI provisioning protocol . . 17 72 6. Validation of multiple instance of signed products . . . . . . 18 73 7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 9. Repository structure . . . . . . . . . . . . . . . . . . . . . 21 76 10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 22 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 79 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 80 14. Normative References . . . . . . . . . . . . . . . . . . . . . 27 81 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 84 1. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "NOT RECOMMENDED" and 88 "OPTIONAL" in this document are to be interpreted as described in 89 [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 regularly throughout the life of the 96 RPKI, as each CA changes its public keys, in a non-coordinated 97 fashion. (By non-coordinated we mean that the time at which each CA 98 elects to change its keys is locally determined, not coordinated 99 across the RPKI.) Moreover, because a key change might be 100 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 [RFC6489]. 107 This document describes the mechanism to perform a key rollover in 108 the RPKI due to the migration to a new signature algorithm suite. It 109 specifies the process that Certification Authorities (CAs) and 110 Relying Parties (RPs) participating in the Resource Public Key 111 Infrastructure (RPKI) will need to follow to transition to a new (and 112 probably cryptographically stronger) algorithm set. The process is 113 expected to be completed in a time scale of months or years. 114 Consequently, no emergency transition is specified. The transition 115 procedure defined in this document supports only a top-down migration 116 (parent migrates before children). 118 A signature algorithm suite encompasses both a signature algorithm 119 (with a specified key size range) and a one-way hash algorithm. It 120 is anticipated that the RPKI will require the adoption of updated key 121 sizes and/or different algorithm suites over time. This document 122 treats the adoption of a new hash algorithm while retaining the 123 current signature algorithm as equivalent to an algorithm migration, 124 and requires the CA to change its key. Migration to a new algorithm 125 suite will be required in order to maintain an acceptable level of 126 cryptographic security and protect the integrity of certificates, 127 CRLs and signed objects in the RPKI. All of the data structures in 128 the RPKI explicitly identify the signature and hash algorithms being 129 used. However, experience has demonstrated that the ability to 130 represent algorithm IDs is not sufficient to enable migration to new 131 algorithm suites (algorithm agility). One also must ensure that 132 protocols, infrastructure elements, and operational procedures also 133 accommodate the migration from one algorithm suite to another. 134 Algorithm migration is expected to be very infrequent and it will 135 require support of a "current" and "next" suite for a prolonged 136 interval, probably several years. 138 This document defines how entities in the RPKI execute (planned) CA 139 key rollover when the algorithm suite changes. The description 140 covers actions by CAs, repository operators, and RPs. It describes 141 the behavior required of both CAs and RPs to make such key changes 142 work in the RPKI context, including how the RPKI repository system is 143 used to support key rollover. 145 This document does not specify any algorithm suite per se. The RPKI 146 Certificate Policy (CP) [RFC6484] mandates the use of the algorithms 147 defined in [RFC6485] by CAs and RPs. When an algorithm transition is 148 initiated, [RFC6485] MUST be updated (as defined in Section 4.1 of 149 this document) redefining the required algorithm(s) for compliant 150 RPKI CAs and RPs under the CP. The CP will not change as a side 151 effect of algorithm transition (and thus the policy OID in RPKI 152 certificates will not change.) 154 For each algorithm transition, an additional document (the algorithm 155 transition timetable) MUST be published (as an IETF BCP) to define 156 the dates for each milestone defined in this document. It will 157 define dates for the phase transitions, consistent with the 158 descriptions provided in Section 4. It also will describe how the 159 RPKI community will measure the readiness of CAs and RPs to 160 transition to each phase. CAs publish certificates, CRLs, and other 161 signed objects under the new algorithm suite as the transition 162 progresses. This provides visibility into the deployment of the new 163 algorithm suite, enabling the community to evaluate deployment 164 progress. The transition procedure allows CAs to remove old 165 certificates, CRLs, and signed products, after the twilight date. 166 This provides an ability to observe and measure the withdrawal of the 167 old algorithm suite. Thus the phases defined in this document enable 168 the community to evaluate the progress of the transition. The 169 timetable document will also describe procedures to amend the 170 timetable if problems arise in implementing later phases of the 171 transition. It is RECOMMENDED that the timetable document be 172 developed by representatives of the RPKI community, e.g., IANA, 173 Internet Registries, and network operators. 175 3. Terminology 177 This document assumes that the reader is familiar with the terms and 178 concepts described in "Internet X.509 Public Key Infrastructure 179 Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], 180 "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 181 "A Profile for Resource Certificate Repository Structure" [RFC6481]. 182 Additional terms and conventions used in examples are provided below. 184 Algorithm migration: A planned transition from one signature and 185 hash algorithm to a new signature and hash algorithm. 187 Algorithm Suite A: The "current" algorithm suite used for hashing 188 and signing, in examples in this document 190 Algorithm Suite B: The "next" algorithm suite used for hashing and 191 signing, used in examples in this document 193 CA X: The CA that issued CA Y's certificate (i.e., CA Y's 194 parent), used in examples in this document. 196 CA Y: The non-leaf CA used in examples this document 198 CA Z: A CA that is a "child" of CA Y, used in examples this 199 document 201 Non-Leaf CA: A CA that issues certificates to other CAs is a non- 202 leaf CA. 204 Leaf CA: A leaf CA is a CA that issues only EE certs. 206 PoP (proof of possession): Execution of a protocol that demonstrates 207 to an issuer that a subject requesting a certificate 208 possesses the private key corresponding to the public key 209 in the certificate request submitted by the subject. 211 Signed Product Set (or Set or Product Set): A collection of 212 certificates, signed objects, a CRL and a manifest that 213 are associated by virtue of being verifiable under the 214 same parent CA certificate 216 Correspond: Two certificates, issued under different Algorithm Suites 217 correspond to one another if they are issued to the same 218 entity by the same CA and bind identical Internet Number 219 Resources (INRs) to that entity. Two CRLs correspond if 220 they are issued by the same CA and enumerate 221 corresponding certificates. Two signed objects (other 222 than manifests) correspond if they are verified using 223 corresponding EE certificates and they contain the same 224 encapsulated Context Info field. Two manifests 225 correspond if they encompass corresponding certificates, 226 ROAs, CRLs, and (other) signed objects (the term 227 "equivalent" is used synonymously when referring to such 228 RPKI signed products.) 230 ROA: Route Origination Authorisation, as defined in [RFC6482]. 232 4. Key Rollover steps for algorithm migration 234 The "current" RPKI algorithm suite (Suite A) is defined in the RPKI 235 CP document, by reference to [RFC6485]. When a migration of the RPKI 236 algorithm suite is needed, the first step MUST be an update of 237 [RFC6485] to define the new algorithm suite. The algorithm 238 transition timeline document MUST also be published (as a BCP), to 239 inform the community of the dates selected for milestones in the 240 transition process, as described in Section 4.1. 242 4.1. Milestones definition 244 CA Ready Algorithm B Date: After this date, all (non-leaf) CAs MUST 245 be ready to process a request from a child CA to issue a 246 certificate under the Algorithm Suite B. All CAs 247 publishing an [RFC6490] Trust Anchor Locator (TAL) for 248 Algorithm Suite A, MUST also publish the correspondent 249 TAL for Algorithm Suite B. 251 CA Go Algorithm B Date: After this date, all CAs MUST have reissued 252 all of their signed product sets under the Algorithm 253 Suite B. 255 RP Ready Algorithm B Date: After this date, all RPs MUST be prepared 256 to process signed material issued under the Algorithm 257 Suite B. 259 Twilight Date: After this date, a CA MAY cease issuing signed 260 products under the Algorithm Suite A. Also, after this 261 date, a RP MAY cease to validate signed materials issued 262 under the Algorithm Suite A. 264 End Of Life (EOL) Date: After this date, the Algorithm Suite A MUST 265 be deprecated using the process in Section 10 and all 266 Algorithm Suite A TALs MUST be removed from their 267 publication points. 269 4.2. Process overview 271 The migration process described in this document involves a series of 272 steps that MUST be executed in chronological order by CAs and RPs. 273 The only milestone at which both CAs and RPs take action at the same 274 time is the EOL Date. Due to the decentralized nature of the RPKI 275 infrastructure, it is expected that an algorithm transition will span 276 several years. 278 In order to facilitate the transition, CAs will start issuing 279 certificates using the Algorithm B in a hierarchical top-down 280 fashion. In our example, CA Y will issue certificates using the 281 Algorithm Suite B only after CA X has started to do so (CA Y Ready 282 Algorithm B Date > CA X Ready Algorithm B Date). This ordered 283 transition avoids issuance of "mixed" suite CA certificates, e.g., a 284 CA certificate signed using Suite A, containing a key from Suite B. 285 In the RPKI, a CA MUST NOT sign a CA certificate carrying a subject 286 key that corresponds to an algorithm suite that differs from the one 287 used to sign the certificate. (X.509 accommodates such mixed 288 algorithm certificates, but this process avoids using that 289 capability.) A not top-down transition approach would require use of 290 such mixed mode certificates, and would lead to exponential growth of 291 the RPKI repository. Also, because the RPKI CP mandates Proof of 292 Possession (PoP) for certificate requests, it is not possible for a 293 CA to request a certificate for Algorithm Suite B, until its parent 294 CA supports that Suite. (See Section 5 for more details.) 296 The algorithm agility model described here does not prohibit a CA 297 from issuing an EE certificate with a subject public key from a 298 different algorithm suite, if that certificate is not used to verify 299 repository objects. This exception to the mixed algorithm suite 300 certificate rule is allowed because an EE certificate that is not 301 used to verify repository objects does not interfere with the ability 302 of RPs to download and verify repository content. As noted above, 303 every CA in the RPKI is required to perform a PoP check for the 304 subject public key when issuing a certificate. In general a subject 305 cannot assume that a CA is capable of supporting a different 306 algorithm. However, if the subject is closely affiliated with the 307 CA, it is reasonable to assume that there are ways for the subject to 308 know whether the CA can support a request to issue an EE certificate 309 containing a specific, different public key algorithm. This document 310 does not specify how a subject can determine whether a CA is capable 311 of issuing a mixed suite EE certificate, because it anticipates that 312 such certificates will be issued only in contexts where the subject 313 and CA are sufficiently closely affiliated (for example, an ISP 314 issuing certificates to devices that it manages). 316 The following figure gives an overview of the process: 318 Process for RPKI CAs: 320 Phase 0 Phase 1 Phase 2 Phase 4 Phase 0 321 -----------x---------x-------------------x--------x----------- 322 ^ ^ ^ ^ ^ 323 | | | | | 324 (1) (2) (3) (5) (6) 326 Process for RPKI RPs: 328 Phase 0 Phase 3 Phase 4 Phase 0 329 -------------------------------x---------x--------x----- 330 ^ ^ ^ ^ 331 | | | | 332 (1) (4) (5) (6) 334 (1) RPKI algorithm document is updated and the algorithm transition timeline document is issued 335 (2) CA Ready Algorithm B Date 336 (3) CA Go Algorithm B Date 337 (4) RP Ready Algorithm B Date 338 (5) Twilight Date 339 (6) End Of Live (EOL) Date 341 Each of these milestones is discussed in the next section when 342 describing each phase of the transition process. 344 Two situations have been identified that motivate pausing or rolling 345 back the transition process. The first situation arises if the RPKI 346 community is not ready to make the transition. For example, many CAs 347 might not be prepared to issue signed products under Suite B, or many 348 RPs might not be ready to process Suite B products. Under these 349 circumstances, the timetable MUST be reissued, postponing the date 350 for the phase in question, and pushing back the dates for later 351 phases. The other situation arises if, during the transition, 352 serious concerns arise about the security of the Suite B algorithms. 353 Such concerns would motivate terminating the transition and rolling 354 back signed products, i.e., reverting to Suite A. In this case the 355 timetable MUST be republished, and the RPKI algorithm document MUST 356 be superseded. The phase descriptions below allude to these two 357 situations, as appropriate. 359 4.3. Phase 0 361 Phase 0 is the steady state phase of the process; throughout this 362 phase, Algorithm Suite A is the only supported algorithm suite in 363 RPKI. This is also the steady state for the RPKI. 365 During Phase 0, CAs X, Y and Z are required to generate signed 366 product sets using only the Algorithm Suite A. Also, RPs are required 367 to validate signed product sets issued using only Algorithm Suite A. 369 The following figure shows an example of the structure of signed 370 objects in the repository, indicating the algorithm suites in use, 371 and showing the relationships between three CAs (X, Y, and Z) that 372 form a certification chain. Vertical alignment in the figure 373 indicates objects signed by the same CA using the same private key. 374 The differences in horizontal indentation also represent use of 375 different publication points for objects signed by different CAs. 376 The characters "|->" are used for visualization purposes for both the 377 signing relationship and the publication point change. For example, 378 the objects CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm- 379 Suite-A and CA-X-Signed-Objects-Algorithm-Suite-A are all signed 380 using the private key corresponding to CA-X-Certificate-Algorithm- 381 Suite-A and published at CA X's corresponding publication point. 383 CA-X-Certificate-Algorithm-Suite-A (Cert-XA) 384 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 385 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 386 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 387 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 388 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 389 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 390 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 391 |-> CA-X-Signed-Objects-Algorithm-Suite-A 393 Note: Cert-XA represent the certificate for CA X, that is signed 394 using the algorithm suite A. 396 4.3.1. Milestone 1 398 The first milestone initiates the migration process. It updates 399 [RFC6485] with the following definitions for the RPKI: 401 o Algorithm Suite A 403 o Algorithm Suite B 405 Additionally, the new algorithm transition timeline document MUST be 406 published with the following information: 408 o CA Ready Algorithm B Date 410 o CA Go Algorithm B Date 412 o RP Ready Algorithm B Date 413 o Twilight Date 415 o EOL Date 417 o Readiness metrics for CAs and RPs in each phase 419 Each date specified here is assumed at one minute after midnight, 420 UTC. No finer granularity time specification is required or 421 supported. 423 4.4. Phase 1 425 Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all 426 (non-leaf) CAs MUST be ready to process a request from a child CA to 427 issue or revoke a certificate using the Algorithm Suite B. If it is 428 determined that a substantial number of CAs are not ready, the 429 algorithm transition timeline document MUST be reissued, as noted in 430 Section 4.2. However, CAs that are capable of issuing Suite B 431 certificates may continue to do so, if requested by their child CAs. 432 Since this phase does not require any RPs to process signed objects 433 under Suite B, and since Suite B product sets SHOULD be stored at 434 independent publication points, there is no adverse impact on RPs. 435 If the Suite B algorithm is deemed unsuitable, the algorithm 436 transition timeline and the algorithm specification documents MUST be 437 replaced, the Algorithm Suite B MUST be deprecated using the process 438 described in Section 10. 440 As the transition will happen using a (hierarchic) top-down model, a 441 child CA will be able to issue certificates using the Algorithm Suite 442 B only after its parent CA has issued its own. The RPKI provisioning 443 protocol can identify if a parent CA is capable of issuing 444 certificates using the Algorithm Suite B, and can identify the 445 corresponding algorithm suite in each Certificate Signing Request 446 (see Section 5). During much of this phase the Suite B product tree 447 will be incomplete, i.e., not all CAs will have issued products under 448 Suite B. Thus for production purposes, RPs MUST fetch and validate 449 only Suite A products. Suite B products should be fetched and 450 processed only for testing purposes. 452 The following figure shows the status of repository entries for the 453 three example CAs during this Phase. Two distinct certificate chains 454 are maintained and CA Z has not yet requested any material using the 455 Algorithm Suite B. 457 CA-X-Certificate-Algorithm-Suite-A (Cert-XA) 458 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 459 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 460 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 461 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 462 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 463 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 464 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 465 |-> CA-X-Signed-Objects-Algorithm-Suite-A 467 CA-X-Certificate-Algorithm-Suite-B (Cert-XB) 468 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB) 469 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 470 |-> CA-Y-Signed-Objects-Algorithm-Suite-B 471 |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB) 472 |-> CA-X-Signed-Objects-Algorithm-Suite-B 474 4.5. Phase 2 476 Phase 2 starts at the CA Go Algorithm B Date. At the start of this 477 phase, each signed product set MUST be available using both Algorithm 478 Suite A and Algorithm Suite B. Thus, prior to the start of this 479 phase, every CA MUST ensure that there is a Suite B product 480 corresponding to each Suite A product that the CA has issued. 481 Throughout this Phase, each CA MUST maintain this correspondence. 482 During this phase, RPs MUST be prepared to validate sets issued using 483 Algorithm Suite A and MAY be prepared to validate sets issued using 484 the Algorithm Suite B. 486 If it is determined that a substantial number of CAs are not ready, 487 the algorithm transition timeline document MUST be reissued, as noted 488 in Section 4.2. (Since the processing requirement for RPs here is a 489 MAY, if RPs have problems with Suite B products this does not require 490 pushing back the Phase 2 milestone, but it does motivate delaying the 491 start of Phase 3.) CAs that are capable of publishing products under 492 Suite B MAY continue to do so. Phase 2, like Phase 1, does not 493 require any RPs to process signed objects under Suite B. Also, Suite 494 B product SHOULD be stored at independent publication points, so 495 there is no adverse impact on RPs that are not prepared to process 496 suite B products (See Section 9 for additional details.) If the 497 Suite B algorithm is deemed unsuitable, the algorithm transition 498 timeline and the algorithm specification documents MUST be replaced 499 and the Algorithm Suite B MUST be deprecated using the process 500 described in Section 10. 502 It is RECOMMENDED that RPs that can process Algorithm Suite B fetch 503 and validate Suite B products. RPs that are not ready to process 504 Suite B products MUST continue to make use of Suite A products. An 505 RP that elects to validate signed product sets using both Algorithm 506 Suite A or Algorithm Suite B should expect the same results. If 507 there are discrepancies when evaluating corresponding signed product 508 sets, successful validation of either product set is acceptable. A 509 detailed analysis of the validation of multiple instances of signed 510 objects is included in Section 6. 512 The following figure shows the status of the repository entries for 513 the three example CAs throughout this phase, where all signed objects 514 are available using both algorithm suites. 516 CA-X-Certificate-Algorithm-Suite-A (Cert-XA) 517 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 518 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) 519 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) 520 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 521 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 522 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 523 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 524 |-> CA-X-Signed-Objects-Algorithm-Suite-A 526 CA-X-Certificate-Algorithm-Suite-B (Cert-XB) 527 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB) 528 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB) 529 |-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB) 530 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 531 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 532 |-> CA-Y-Signed-Objects-Algorithm-Suite-B 533 |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB) 534 |-> CA-X-Signed-Objects-Algorithm-Suite-B 536 4.6. Phase 3 538 Phase 3 starts at the RP Ready Algorithm B Date. During this phase, 539 all signed product sets are available using both algorithm suites and 540 all RPs MUST be able to validate them. (The correspondence between 541 Suite A and Suite B products was required for Phase 2, and maintained 542 throughout that Phase. The same requirements apply throughout this 543 Phase.) It is RECOMMENDED that, in preparation for Phase 4, RPs 544 retrieve and process Suite B product sets first, and treat them as 545 the preferred product sets for validation throughout this phase. 546 Thus an RP SHOULD try to validate the sets of signed products 547 retrieved from the Algorithm Suite B repository first. 549 If a substantial number of RPs are unable to process product sets 550 signed with Suite B, the algorithm transition timeline document MUST 551 be reissued, pushing back the date for this and later milestones, as 552 discussed in Section 4.2. Since the Suite B products SHOULD be 553 published at distinct publication points, RPs that cannot process 554 Suite B products can be expected to revert to the Suite A products 555 that still exist. If the Suite B algorithm is deemed unsuitable, the 556 algorithm transition timeline and the algorithm specification 557 documents MUST be replaced and the Algorithm Suite B MUST be 558 deprecated using the process described in Section 10. 560 There are no changes to the CA behavior throughout this phase. 562 4.7. Phase 4 564 Phase 4 starts at the Twilight Date. At that date, the Algorithm A 565 is labeled as "old" and the Algorithm B is labeled as "current". 567 During this phase, all signed product sets MUST be issued using 568 Algorithm Suite B and MAY be issued using Algorithm Suite A. All 569 signed products sets issued using Suite B MUST be published at their 570 corresponding publication points. Signed products sets issued using 571 Suite A might not be available at their corresponding publication 572 points. Every RP MUST validate signed product sets using Suite B. 573 RPs MAY validate signed product sets using Suite A. However, RPs 574 SHOULD NOT assume that the collection of Suite A product sets is 575 complete. Thus RPs SHOULD make use of only Suite B products sets. 576 (See Section 6 for further details.) 578 If it is determined that many RPs are not capable of processing the 579 new algorithm suite, the algorithm transition timeline document MUST 580 be reissued pushing back the date for this and the next milestone. 581 The document MUST require CA to not remove Suite A product sets if 582 this phase is delayed. If the Algorithm Suite B is deemed 583 unsuitable, the algorithm transition timeline, the algorithm 584 specification documents MUST be replaced, the Algorithm Suite B MUST 585 be deprecated using the process described in Section 10 and CAs MUST 586 NOT remove Suite A product sets. At this stage, RPs are still 587 capable of processing Suite A signed products, so the RPKI is still 588 viable. 590 The following figure describes a possible status for the repositories 591 of the example CAs. 593 CA-X-Certificate-Algorithm-Suite-A (Cert-XA) 594 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) 595 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 596 |-> CA-Y-Signed-Objects-Algorithm-Suite-A 597 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) 598 |-> CA-X-Signed-Objects-Algorithm-Suite-A 600 CA-X-Certificate-Algorithm-Suite-B (Cert-XB) 601 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB) 602 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB) 603 |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB) 604 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 605 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB) 606 |-> CA-Y-Signed-Objects-Algorithm-Suite-B 607 |-> CA-X-CRL-Algorithm-Suite-A (CRL-XB) 608 |-> CA-X-Signed-Objects-Algorithm-Suite-B 610 4.8. Return to Phase 0 612 The EOL Date triggers the return to Phase 0 (steady state). At this 613 point, the old algorithm suite (Algorithm Suite A) MUST be deprecated 614 using the process described in Section 10. 616 This phase closes the loop as the new algorithm suite (Algorithm 617 Suite B) is the only required algorithm suite in RPKI. From this 618 point forward, this suite is referred to as Algorithm Suite A. 620 If it is determined that many RPs are not capable of processing the 621 new algorithm suite, the algorithm transition timeline document MUST 622 be reissued pushing back the date for this milestone. 624 5. Multi Algorithm support in the RPKI provisioning protocol 626 The migration described in this document is a top-down process, where 627 two synchronization issues need to be solved between child and parent 628 CAs: 630 o A child CA needs to identify which algorithm suites are supported 631 by its parent CA 633 o A child CA needs to signal which algorithm suite should be used by 634 its parent CA to sign a Certificate Signing Request (CSR) 636 The RPKI provisioning protocol [RFC6492] supports multiple algorithms 637 suites by implementing different resource classes for each suite. 638 Several different resource classes also may use the same algorithm 639 suite for different resource sets. 641 A child CA that wants to identify which algorithm suites are 642 supported by its parent CA MUST perform the following tasks: 644 1. Establish a provisioning protocol session with its parent CA 646 2. Perform a "list" command as described in Section 3.3.1 of 647 [RFC6492] 649 3. From the Payload in the "list response" resource class, extract 650 the "issuer's certificate" for each class. The Algorithm Suite 651 for each class will match the Algorithm Suite used to issue the 652 corresponding "issuer's certificate" (as specified in the 653 SubjectPublicKeyInfo field of that certificate) 655 A child CA that wants to specify an Algorithm Suite to its parent CA 656 (e.g., in a certificate request) MUST perform the following tasks: 658 1. Perform the tasks described above to identify the algorithm 659 suites supported by its parent CA, and the resource class 660 corresponding to each suite 662 2. Identify the corresponding resource class in the appropriate 663 provisioning protocol command (e.g. "issue" or "revoke") 665 Upon receipt of a certificate request from a child CA, a parent CA 666 will verify the PoP of the private key. If a child CA requests 667 issuing a certificate using an algorithm suite that does not match a 668 resource class, the PoP validation will fail and the request will not 669 be performed. 671 6. Validation of multiple instance of signed products 673 During Phases 1,2,3 and 4, two algorithm suites will be valid 674 simultaneously in RPKI. In this section, we describe the RP behavior 675 when validating corresponding signed products using different 676 algorithm suites. 678 During Phase 1 two (corresponding) instances MAY be available for 679 each signed product, one signed under Algorithm Suite A and one under 680 Algorithm Suite B. As noted in Section 4.4, in this phase there is a 681 preference for Suite A product sets. All products are available 682 under Suite A, while only some products may be available under Suite 683 B. For production purposes an RP MAY fetch and validate only Suite A 684 products. Suite B products SHOULD be fetched and validated only for 685 test purposes. When product sets exist under both Suites, they 686 should yield equivalent results, which facilitates testing. (It is 687 not possible to directly compare Suite A and Suite B product sets, as 688 certs, CRLs, and manifests will appear syntactically different. 689 However, the output of the process, i.e., the ROA payloads 690 (Autonomous System Number and address prefix data), SHOULD match, 691 modulo timing issues.) 693 During Phases 2 and 3 of this process, two (corresponding) instances 694 of all signed products MUST be available to RPs. As noted in Section 695 4.5, it is RECOMMENDED that Suite B capable RPs fetch and validate 696 Suite B products sets, during Phase 2. If an RP encounters 697 validation problems with the Suite B products, it SHOULD revert to 698 using Suite A products. RPs that are Suite B capable MAY fetch both 699 product sets and compare the results (e.g., ROA outputs) for testing. 701 In Phase 3 all RPs MUST be Suite B capable, and MUST fetch Suite B 702 product sets. If an RP encounters problems with Suite B product 703 sets, it can revert to Suite A products. RPs encountering such 704 problems SHOULD contact the relevant repository maintainers (e.g., 705 using the mechanism defined in [RFC6493] to report problems.) 707 During Phase 4 only Suite B product sets are required to be present 708 for all RPKI entities, as per Section 4.7. Thus RPs SHOULD retrieve 709 and validate only these product sets. Retrieval of Suite A products 710 sets may yield an incomplete set of signed products and is NOT 711 RECOMMENDED. 713 7. Revocation 715 The algorithm migration process mandates the maintenance of two 716 parallel but equivalent certification hierarchies during Phases 2 and 717 3 of the process. During these phases, a CA MUST revoke and request 718 revocation of certificates consistently under both algorithm Suites. 719 When not performing a key rollover operation (as described in Section 720 8), a CA requesting the revocation of its certificate during these 721 two phases MUST perform that request for both algorithm suites (A and 722 B). A non-leaf CA SHOULD NOT verify that its child CAs comply with 723 this requirement. Note that a CA MUST request revocation of its 724 certificate relative to a specific algorithm suite using the 725 mechanism described in Section 5 727 During Phase 1, a CA that revokes a certificate under Suite A SHOULD 728 revoke the corresponding certificate under Suite B, if that 729 certificate exists. During Phase 4, a CA that revokes a certificate 730 under Suite B SHOULD revoke the corresponding certificate under Suite 731 A, if that certificate exists. 733 During Phase 1, a CA may revoke certificates under Suite B without 734 revoking them under Suite A, since the Suite B products are for test 735 purposes. During Phase 4 a CA may revoke certificates issued under 736 Suite A without revoking them under Suite B, since Suite A products 737 are being deprecated. 739 8. Key rollover 741 Key rollover (without algorithm changes) is effected independently 742 for each algorithm suite and MUST follow the process described in 743 [RFC6489]. 745 9. Repository structure 747 The two parallel hierarchies that will exist during the transition 748 process SHOULD have independent publications points. The repository 749 structures for each algorithm suite are described in [RFC6481]. 751 10. Deprecating an Algorithm Suite 753 To deprecate an algorithm suite, the following process MUST be 754 executed by every CA in the RPKI: 756 1. Each CA MUST cease issuing certificates under the suite. This 757 means that any request for a (CA) certificate from a child will 758 be rejected, e.g., sending an error_response message with error 759 code:"request - no such resource class" as defined in [RFC6492]. 761 2. Each CA MUST cease generating signed products, except the CRL and 762 Manifest, under the deprecated Algorithm Suite. 764 3. Each CA MUST revoke the EE certificates for all signed products 765 that it has issued under the deprecated Algorithm Suite. The CA 766 SHOULD delete these products from its publication point, to avoid 767 burdening RPs with downloading and processing these products. 769 4. Each CA MUST revoke all CA certificates that it has issued under 770 the deprecated Algorithm Suite. 772 5. Each CA SHOULD remove all CA certificates that it has issued 773 under the deprecated Algorithm Suite. 775 6. Each CA that publishes a TAL under the deprecated Algorithm Suite 776 MUST removed it from the TAL's publication point. 778 7. Each CA SHOULD continue to maintain the publication point for the 779 deprecated Algorithm Suite, maintained at least until the CRL 780 nextUpdate. This publication point MUST contain only the CRL and 781 a Manifest for that publication point. This behavior provides a 782 window in which RPs may be able to become aware of the revoked 783 status of the signed products that have been deleted. 785 8. Each RP MUST remove any TALs that is has published under the 786 deprecated Algorithm Suite. 788 CAs in the RPKI hierarchy may become aware of the deprecation of the 789 algorithm suite at different times, and may execute the procedure 790 above in an asynchronous fashion relative to one another. Thus, for 791 example, a CA may request revocation of its CA certificate only to 792 learn that the certificate has already been revoked by the issuing 793 CA. The revocation of a CA certificate makes the CRL and manifest 794 issued under it incapable of validation. The asynchronous execution 795 of this procedure likely will result in transient "inconsistencies" 796 among the publication points associated with the deprecated algorithm 797 suite. However, these inconsistencies should yield "fail safe" 798 results, i.e., the objects signed under the deprecated suite should 799 be rejected by RPs. 801 11. IANA Considerations 803 No IANA requirements 805 12. Security Considerations 807 An algorithm transition in RPKI should be a very infrequent event and 808 it requires wide community consensus. The events that may lead to an 809 algorithm transition may be related to a weakness of the 810 cryptographic strength of the algorithm suite in use by RPKI, which 811 is normal to happen over time. The procedure described in this 812 document will take years to complete an algorithm transition. During 813 that time, the RPKI system will be vulnerable to any cryptographic 814 weakness that may have triggered this procedure (i.e. downgrade 815 attack). 817 This document does not describe an emergency mechanism for algorithm 818 migration. Due to the distributed nature of RPKI, and the very large 819 number of CAs and RPs, the authors do not believe it is feasible to 820 effect an emergency algorithm migration procedure. 822 If a CA does not complete its migration to the new algorithm suite as 823 described in this document (after the EOL of the "old" algorithm 824 suite), its signed product set will no longer be valid. 825 Consequently, the RPKI may, at the end of Phase 4, have a smaller 826 number of valid signed products than before starting the process. 827 Conversely, a RP that does not follow this process will lose the 828 ability to validate signed products issued under the new algorithm 829 suite. The resulting incomplete view of routing info from the RPKI 830 (as a result of a failure by CAs or RPs to complete the transition) 831 could degrade routing in the public Internet. 833 13. Acknowledgements 835 The authors would like to acknowledge the work of the SIDR working 836 group co-chairs (Sandra Murphy and Chris Morrow) as well as the 837 contributions given by Geoff Huston, Arturo Servin, Brian Weis, Terry 838 Manderson, Brian Dickson and Danny McPherson. 840 14. Normative References 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 846 Addresses and AS Identifiers", RFC 3779, June 2004. 848 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 849 Housley, R., and W. Polk, "Internet X.509 Public Key 850 Infrastructure Certificate and Certificate Revocation List 851 (CRL) Profile", RFC 5280, May 2008. 853 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 854 Resource Certificate Repository Structure", RFC 6481, 855 February 2012. 857 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 858 Origin Authorizations (ROAs)", RFC 6482, February 2012. 860 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 861 Policy (CP) for the Resource Public Key Infrastructure 862 (RPKI)", BCP 173, RFC 6484, February 2012. 864 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 865 Use in the Resource Public Key Infrastructure (RPKI)", 866 RFC 6485, February 2012. 868 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 869 Authority (CA) Key Rollover in the Resource Public Key 870 Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012. 872 [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 873 "Resource Public Key Infrastructure (RPKI) Trust Anchor 874 Locator", RFC 6490, February 2012. 876 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 877 Protocol for Provisioning Resource Certificates", 878 RFC 6492, February 2012. 880 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 881 Ghostbusters Record", RFC 6493, February 2012. 883 Appendix A. Change Log 885 Note to the RFC Editor: Please remove this section before 886 publication. 888 From 11 to 12 890 Changed to BCP from Standard track. 892 From 10 to 11 894 Additional GenArt review on section 4 to improve the description of 895 the figures showing the CAs chains. 897 From 09 to 10 899 1. GenArt Comments: Remove Algorithm C from process and replace a 900 couple of "will" with MUST when referring to issuing a new 901 document. 903 From 08 to 09 905 1. SecDIR comments and nits included 907 From 07 to 08 909 1. Typo in Section 10 911 2. Correct reference for RFC6493 913 From 06 to 07: 915 1. Added definition for "Correspond" 917 2. Added reference of correspondence between suites in phase 2 and 3 919 3. Small nit on the revocation definition. 921 From 05 to 06: 923 1. Added reference to published RFCs 925 2. Removed requirement on dates format 927 3. Changed revocation section to emphasize the differences between 928 phase 1,2,3 and 4. 930 4. Added Section 10: Deprecating an Algorithm Suite 932 5. Typos and editoral changes 934 From 04 to 05: 936 1. WGLC nits 938 From 03 to 04: 940 1. Added text for "roll-over" capability in each phase 942 2. Added the requirement for splitting the milestone 1 in two 943 documents: the update of the alg document and a new document 944 specifying the particular timelines 946 3. WGLC nits 948 From 02 to 03: 950 1. Explicitely named than "mixed" certificates are not allowed for 951 CA certs but may be possible for EE certs that are not used to 952 validate repository objects. 954 From 01 to 02: 956 1. Add reference to Multi-Objects validation 958 2. EOL Date is the only milestone that RP and CA take actions "at 959 the same time". 961 3. Updated references 963 4. Editorial 965 From 00 to 01: 967 1. Include text to clarify former Suites 969 2. Include text that documents that an RP that validates an object 970 signed with either suites in Phase 2 MUST consider it as valid 972 From individual submission to WG item: 974 1. Change form "laisez faire" to "top-down" 976 2. Included Multi Algorithm support in the RPKI provisioning 977 protocol 979 3. Included Validation of multiple instance of signed products 981 4. Included Revocations 983 5. Included Key rollover 985 6. Included Repository structure 987 7. Included Security Considerations 989 8. Included Acknowledgements 991 Authors' Addresses 993 Roque Gagliano 994 Cisco Systems 995 Avenue des Uttins 5 996 Rolle, 1180 997 Switzerland 999 Email: rogaglia@cisco.com 1001 Stephen Kent 1002 BBN Technologies 1003 10 Moulton St. 1004 Cambridge, MA 02138 1005 USA 1007 Email: kent@bbn.com 1009 Sean Turner 1010 IECA, Inc. 1011 3057 Nutley Street, Suite 106 1012 Fairfax, VA 22031 1013 USA 1015 Email: turners@ieca.com