idnits 2.17.1 draft-rgaglian-sidr-algorithm-agility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4940 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: 'RFC 3339' is mentioned on line 306, but not defined == Unused Reference: 'I-D.ietf-sidr-cp' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-res-certs' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-rescerts-provisioning' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC2560' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC5781' is defined on line 604, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-sidr-cp-14 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-keyroll-01 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-05 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-19 == Outdated reference: A later version (-11) exists of draft-ietf-sidr-rescerts-provisioning-07 == Outdated reference: A later version (-05) exists of draft-ietf-sidr-rpki-algs-03 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) Summary: 1 error (**), 0 flaws (~~), 14 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: April 21, 2011 BBN Technologies 6 S. Turner 7 IECA, Inc. 8 October 18, 2010 10 Algorithm Agility Procedure for RPKI. 11 draft-rgaglian-sidr-algorithm-agility-00 13 Abstract 15 This document specifies the process that Certificate Authorities 16 (CAs) and Relying Parties (RP) participating in the Resource Public 17 Key Infrastructure (RPKI) will need to follow to transition to a new 18 (and probably cryptographically stronger) algorithm set. The process 19 is expected to be completed in a time scale of months or years. 20 Consequently, no emergency transition is specified. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 21, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Key Rollover steps for algorithm migration . . . . . . . . . . 8 60 4.1. Milestones definition . . . . . . . . . . . . . . . . . . 8 61 4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 4.8. Phase 5 . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 4.9. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 5. Synchronization issues during the algorithm transition . . . . 15 70 5.1. Signed Objects Information . . . . . . . . . . . . . . . . 15 71 5.2. Revocations . . . . . . . . . . . . . . . . . . . . . . . 15 72 5.3. Key rollover . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.4. Repository structure . . . . . . . . . . . . . . . . . . . 15 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 80 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 83 1. Requirements notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Introduction 91 The RPKI must accommodate transitions between the public keys by used 92 by CAs. Transitions of this sort are usually termed "key rollover". 93 Planned key rollover will occur at regular intervals throughout the 94 life of the RPKI, as each CA changes its public keys, in a non- 95 coordinated fashion. (By non-coordinated we mean that the time at 96 which each CA elects to change its keys is locally determined, not 97 coordinated across the RPKI.) Moreover, because a key change might 98 be necessitated by suspected private key compromise, one can never 99 assume coordination of these events among all of the CAs in the RPKI. 100 In an emergency key rollover, the old certificate is revoked and a 101 new certificate with a new key is issued. The mechanisms to perform 102 a key rollover in RPKI (either planned or in an emergency), while 103 maintaining the same algorithm suite, are covered in 104 [I-D.ietf-sidr-keyroll]. 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. (One might adopt 112 a new hash algorithm while retaining the current signature algorithm. 113 In such circumstances this document treats the change as equivalent 114 to a key rollover, and requires the CA to change its key as well). 115 Such transitions will be required in order to maintain an acceptable 116 level of cryptographic security, to protect the integrity of 117 certificates, CRLs and signed objects in the RPKI. All of the data 118 structures in the RPKI explicitly identify the signature and hash 119 algorithms being used. However, experience has demonstrated that the 120 ability to represent algorithm IDs is not sufficient to enable 121 migration to new algorithm suites (algorithm agility). One also must 122 ensure that protocols, infrastructure elements, and operational 123 procedures also accommodate migration from one algorithm suite to 124 another. Algorithm migration is expected to be very infrequent, but 125 it also will require support of a "current" and "next" suite for a 126 prolonged 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 A failure to comply with this process during an algorithm transition 136 MUST be considered as non-compliance with the RPKI Certificate Policy 137 (CP). 139 3. Terminology 141 This document assumes that the reader is familiar with the terms and 142 concepts described in "Internet X.509 Public Key Infrastructure 143 Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], 144 "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 145 "A Profile for Resource Certificate Repository Structure" 146 [I-D.ietf-sidr-repos-struct]. Additional terms and conventions use 147 din examples are provided below. 149 Algorithm migration A planned transition from one signature and hash 150 algorithm to a new signature and hash algorithm. 152 Algorithm Siute A The "current" algorithm suite used for hashing and 153 signing, in examples in this document 155 Algorithm Siute B The "next" algorithm suite used for hashing and 156 signing, used in examples in this document 158 Algorithm Siute C The "old" algorithm suite used for hashing and 159 signing, used in examples in this document 161 CA X The CA that issued CA Y's certificate (i.e., CA Y's 162 parent), used in examples this document. 164 CA Y The CA that is changing keys and/or algorithm suites, 165 used in examples this document 167 CA Z A CA that is a "child" of CA Y, used in examples this 168 document 170 Certificate reissuance (unilateral) Certificate reissuance 171 (unilateral) - a CA MAY reissue a certificate to a 172 subordinate Subject without the involvement of the 173 Subject. The public key, resource extensions, and most 174 other fields (see Section X.X) are copied from the 175 current Subject certificate into the next Subject 176 certificate. The Issuer name MAY change, if necessary to 177 reflect the Subject name in the CA certificate under 178 which the reissued certificate will be validated. The 179 validity interval also MAY be changed. This action is 180 defined as a unilateral certificate reissuance. 182 Key rollover (planned) - reissuance of CA's certificate with a new 183 key, at a pre-determined time. 185 Key rollover (emergency) - reissuance of CA's certificate with a new 186 key, e.g., as a result of a suspected compromise or loss 187 of access to a private key. An emergency key rollover is 188 not a planed event (from the perspective of the CA). 190 Non-Leaf CA - a CA that issues certificates to entities not under its 191 administrative control. 193 PoP (proof of possession) - execution of a protocol that 194 demonstrates to an issuer that a subject requesting a 195 certificate possesses the private key corresponding to 196 the public key in the certificate submitted by the 197 subject. 199 Signed Product Set (or Set) - a collection of certificates, signed 200 objects, a CRL and a manifest that are associated by 201 virtue of being verifiable under the same parent CA 202 certificate 204 4. Key Rollover steps for algorithm migration 206 The "current" RPKI algorithm suite (Suite A) definition is defined in 207 the RPKI's CP document , by reference to [I-D.ietf-sidr-rpki-algs]. 208 If a migration of the RPKI algorithm suite is needed, the first step 209 MUST be an update of the [I-D.ietf-sidr-rpki-algs] document that will 210 include all the information described in section Section 4.3. 212 4.1. Milestones definition 214 CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST 215 be ready to process a request from a child CA to issue a 216 certificate containing an Algorithm B key for signature, 217 even if signing the certificate using the Algorithm A 218 suite. 220 CA Set Algorithm B Date - After this date, all CAs MUST be able to 221 issue a certificate signed under the Algorithm B suite to 222 a child CA that requests such. At this stage there is no 223 requirement that any CA issue such certificates, but 224 rather that all (non-eaf) CAs be prepared to do so upon 225 request. 227 CA Go Algorithm B Date - After this date, all (non-leaf) CAs MUST 228 have re-issued all of its signed product set under the 229 Algorithm B suite. 231 RP Ready Algorithm B Date - After this date, all RPs MUST be 232 prepared to process signed material issued under the 233 Algorithm B suite. 235 Twilight Algorithm B - After this date, a CA MAY cease issuing 236 signed products under the old algorithm suite. Also, 237 after this date, a RP MAY cease to validate signed 238 materials issued under the Algorithm A suite. 240 End Of Life (EOL) Algorithm A - After this date every CA MUST NOT 241 generate certificates, CRLs, or other RPKI signed objects 242 under the Algorithm A suite. Also, after this date, no 243 RP should validate any certificate, CRL or signed object 244 using the Algorithm A suite. 246 4.2. Process overview 248 The migration process described in this document involves a series of 249 steps that MUST be executed in chronological order by CAs and RPs. 250 The only milestone that affects both CAs and RPs, at the same moment 251 is the EOL date. Due to the decentralized nature of the RPKI 252 infrastructure, it is expected that the process will take several 253 months or even years. It also is expected that different CAs and RPs 254 will achieve the various milestones at different moments without 255 central synchronization. The following figure gives an overview of 256 the process: 258 Process for RPKI CAs: 260 Phase 0 Phase 1 Phase 2 Phase 3 Phase 5 Phase 0 261 -----------x--------x--------x-------------------x--------x------- 262 ^ ^ ^ ^ ^ ^ 263 | | | | | | 264 (1) (2) (3) (4) (6) (7) 266 Process for RPKI RPs: 268 Phase 0 Phase 4 Phase 5 Phase 0 269 ----------------------------------------x--------x--------x-------- 270 ^ ^ ^ ^ 271 | | | | 272 (1) (5) (6) (7) 274 (1) RPKI's algorithm document updated. 275 (2) CA Ready Algorithm B Date 276 (3) CA Set Algorithm B Date 277 (4) CA Go Algorithm B Date 278 (5) RP Ready Algorithm B Date 279 (6) Twilight Date 280 (7) End Of Live (EOL) Date 282 4.3. Phase 0 284 Phase 0 is the initial phase of the process, during which the 285 Algorithm suite A is the only required algorithm suite in RPKI. 287 The first milestone here (1), is updating the [alg] document with the 288 following definitions: 290 o Algorithm Suite A 292 o Algortihm Suite B 294 o CA Ready Algorithm B Date 296 o CA Set Algorithm B Date 298 o CA Go Algorithm B Date 299 o RP Ready Algorithm B Date 301 o Twilight Date 303 o EOL Date 305 All Dates MUST be represented using the local UTC date-time format 306 specified in [RFC 3339]. 308 As an example, during Phase 0, CAs X, Y and Z are required to 309 generate signed product sets using only the Algorithm suite A. Also, 310 RPs are required to validate signed product sets issued using only 311 Algorithm suite A. 313 CA X-Certificate-Algorithm-Suite-A (Cert-XAA) 314 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YAA) 315 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZAA) 316 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 317 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) 318 |-> CA-Y-Other-Signed-Objects-Algorithm-Suite-A 320 Note: Cert-XAA represent the certificate for CA X, that includes an 321 algorithm suite A key in its Subject Public Key Info field (first A) 322 and is signed using the algorithm suite A (second A). 324 4.4. Phase 1 326 Phase 1 starts at the CA Ready Algorithm B Date. During the Phase 1, 327 ALL (non-leaf) CAs MUST be ready to process a request from a child CA 328 to issue a certificate containing an Algorithm B key for signature. 329 In order to perform this task, the issued CA MUST be able to 330 demonstrate the subject's PoP by verifying the certificate request's 331 signature, which MAY be calculated using the signature algorithm B. 333 During this phase, the issuing CA is NOT required to sign the 334 certificates it issues using the Algorithm suite B. Consequently, it 335 is possible to issue certificates signed using the Algorithm suite A, 336 but that have a "Subject Public Key Info" field that correspond to 337 the Algorithm suite B. Also, the issuing CA MAY receive requests with 338 the same Subject field but different Subject Public Key Info fields 339 (for either the Algorithm A or B suite). 341 During the complete transition process, all CA MUST NOT sign a CSR 342 that includes an Algorithm Suite A "Subject Public Key Info" using 343 the Algorithm Suite B. 345 (Note 1: Now we may have an issue with the decision from the WG of 346 not using the "top-down" model. If I am a subordinate CA and my 347 parent has the possibility of issuing certificates with both, the A 348 and B algorithm suite, how does a request indicate the algorithm 349 suite that should be used? We may need to modify the provisioning 350 protocol to indicate which algorithm suite to use. In the following 351 sections, I assume that the subordinate CA has the ability to chose 352 which Algorithm Suite it will use). 354 (Note 2: Also in the provisioning protocol, it looks that it would be 355 great to have the possibility to question the server on what 356 algorithm suite it supports in order to not depend in any off-band 357 communication). 359 A RP is not required to modify its behavior during the Phase 1. 360 However, a RP MAY validate the signed objects signed using the 361 Algorithm suite B. A RP that choses to do so MUST consider as equally 362 valid any validated signed object signed with Algorithm suite A or B. 364 The objective of this phase is to allow a subordinate CA to start its 365 transition to the Algorithm Suite B, although its parent CA is not 366 ready to issue certificates using the new suite. In our example if 367 CA Y would like to start the transition, it should send a certificate 368 request that includes an Algorithm Suite B key in its "Subject Public 369 Key Info". CA X will be able to verify the signature of the 370 certificate request and issue the certificate that, in this case, is 371 signed using Algorithm Suite A. CA Y then will be able to issue a 372 certificate signed by Algorithm Suite B to CA Z, and to generate any 373 signed object using the new algorithm suite. CA Y will have two 374 certificates with the same resources, both signed with the same key 375 from CA X. CA Z may have three certificates, depending on which 376 validation paths CA Z would like to enable. The typical 377 certification hierarchy is shown in this figure: 379 CA X-Certificate-Algorithm-Suite-A (Cert-XAA) 380 | 381 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YAA) 382 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZAA) 383 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 384 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBA) 385 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 386 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-ZA) 387 |-> CA-Y-Other-Signed-Objects-Algorithm-Suite-A 388 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YBA) 389 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBB) 390 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 391 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 392 |-> CA-Y-Other-Signed-Objects-Algorithm-Suite-B 394 In the example of the figure, an RP that can validate signed product 395 sets using either algorithm suites, and that is configure with 396 Certificate Cert-XAA as its Trust Anchor (TA) would be able to 397 validate the CA Y signed product sets signed using Algorithm Suite B, 398 by using the following validation path: Cert-XAA --> Cert-YBA. 400 The RP also will be able to validate CA Z signed product sets signed 401 using Algorithm Suite B, by using either of the following validation 402 paths: 404 Cert-XAA --> Cert-YAA --> Cert-ZBA-> CA-Z-Signed-Objects-Algorithm- 405 Suite-B 407 or 409 Cert-XAA --> Cert-YBA --> Cert-ZBB-> CA-Z-Signed-Objects-Algorithm- 410 Suite-B 412 If any CA in the example were in the process of a key rollover (using 413 the same algorithm suite), more validation paths would be possible. 415 4.5. Phase 2 417 Phase 2 starts at the CA Set Algorithm B Date. During this phase, 418 ALL CAs MUST be able to issue a certificate signed under the 419 Algorithm B suite to a child CA that requests such. Also, every CA 420 MUST issue its CRLs using both Algorithm suites (A and B). 422 At this phase a subordinate CA has the ability to choose which 423 Algorithm suite should be used by the issuing CA to generate the 424 requested certificate. (Note: here we should add a reference to the 425 mechanism that should be part of the provisioning protocol). 427 Every CA MUST issue a CRL for each CA Certificate associated with the 428 CA. Each CRL should be signed with the correspondent algorithm 429 suite. 431 The same comment for RP behaviour during Phase 1 is valid during 432 Phase 2. 434 In our three CA example, CA A will be able to issue certificates 435 using Algorithm Suite B: 437 CA X-Certificate-Algorithm-Suite-A (Cert-XAA) 438 | 439 |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YAA) 440 |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZAA) 441 |-> CA-Z-Signed-Objects-Algorithm-Suite-A 442 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBA) 443 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 444 |-> CA-Y-CRL-Algorithm-Suite-A (CRL-ZA) 445 |-> CA-Y-Other-Signed-Objects-Algorithm-Suite-A 446 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YBA) 447 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBB) 448 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 449 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 450 |-> CA-Y-Other-Signed-Objects-Algorithm-Suite-B 452 CA X-Certificate-Algorithm-Suite-B (Cert-XBB) 453 |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YBB) 454 |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBB) 455 |-> CA-Z-Signed-Objects-Algorithm-Suite-B 456 |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) 457 |-> CA-Y-Other-Signed-Objects-Algorithm-Suite-B 459 In this example, the certificate requests for Cert-YBB and Cert-YBA 460 are the same, the only difference is that, in one case, the 461 certificate is issued signed using Algorithm-Suite A (Cert-YBA) and 462 in the other case using Algorithm-Suite B (Cert-YBB). This 463 architecture simplifies the operation of the CA-Y and the structure 464 of the repository system. 466 A RP that can validate signed product sets using Algorithm Suite B, 467 could use Cert-XBB as trust anchor and validate all CA Y and CA Z 468 signed product sets using only the new suite. At this stage not all 469 CAs are required to issue signed product sets using Algorithm Suite B 470 and it is not expected that an RP uses only Algorithm Suite B trust 471 anchors. 473 4.6. Phase 3 475 Phase 3 starts at the CA Go Algorithm B Date. During this phase all 476 signed product sets are available either using Algorithm Suite A or 477 Algorithm Suite B. At this phase, RPs are not yet required to 478 validate the sets issued using Algorithm Suite B. 480 At this phase, RPs are still required to be able to validate signed 481 product sets using only the Algorithm Suite A. 483 An RP that validates all signed product sets using exclusively either 484 Algorithm Suite A or Algorithm Suite B, should expect the same 485 results. 487 4.7. Phase 4 489 Phase 4 starts at the RP Ready Algorithm B Date. During this phase, 490 all signed product sets are available using both algorithm suites and 491 ALL RPs MUST be able to validate them using either suite. 493 4.8. Phase 5 495 Phase 5 starts at the Algorithm B Twilight Date. At that date, the 496 Algorithm A is labeled as "old" and the Algorithm B is labeled as 497 "current": 499 A->C 500 B->A 502 During this phase, all signed product sets MUST use using the current 503 Algorithm Suite A and MAY be used using the old Algorithm Suite C. 504 Also, every RP MUST validate signed product sets using the current 505 Algorithm Suite A, but also MAY validate signed product sets using 506 the old Algorithm Suite C. 508 4.9. Phase 0 510 Phase 0 starts at the EOL Algorithm Date. At this phase, ALL signed 511 product sets under using Algorithm Suite C MUST be considered 512 invalid. 514 This phase closes the loop as Algorithm suite A is the only required 515 algorithm suite in RPKI. 517 5. Synchronization issues during the algorithm transition 519 TBC 521 5.1. Signed Objects Information 523 TBC 525 5.2. Revocations 527 TBC 529 5.3. Key rollover 531 TBC 533 5.4. Repository structure 535 TBC 537 6. IANA Considerations 539 No IANA requirements 541 7. Security Considerations 543 TBC 545 8. Acknowledgements 546 9. References 548 9.1. Normative References 550 [I-D.ietf-sidr-cp] 551 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 552 Policy (CP) for the Resource PKI (RPKI", 553 draft-ietf-sidr-cp-14 (work in progress), October 2010. 555 [I-D.ietf-sidr-keyroll] 556 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 557 in the RPKI", draft-ietf-sidr-keyroll-01 (work in 558 progress), September 2010. 560 [I-D.ietf-sidr-repos-struct] 561 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 562 Resource Certificate Repository Structure", 563 draft-ietf-sidr-repos-struct-05 (work in progress), 564 October 2010. 566 [I-D.ietf-sidr-res-certs] 567 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 568 X.509 PKIX Resource Certificates", 569 draft-ietf-sidr-res-certs-19 (work in progress), 570 October 2010. 572 [I-D.ietf-sidr-rescerts-provisioning] 573 Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 574 Protocol for Provisioning Resource Certificates", 575 draft-ietf-sidr-rescerts-provisioning-07 (work in 576 progress), October 2010. 578 [I-D.ietf-sidr-rpki-algs] 579 Huston, G., "A Profile for Algorithms and Key Sizes for 580 use in the Resource Public Key Infrastructure", 581 draft-ietf-sidr-rpki-algs-03 (work in progress), 582 October 2010. 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 588 Adams, "X.509 Internet Public Key Infrastructure Online 589 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 591 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 592 Addresses and AS Identifiers", RFC 3779, June 2004. 594 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 595 Addresses", RFC 4193, October 2005. 597 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 598 Housley, R., and W. Polk, "Internet X.509 Public Key 599 Infrastructure Certificate and Certificate Revocation List 600 (CRL) Profile", RFC 5280, May 2008. 602 9.2. Informative References 604 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 605 Scheme", RFC 5781, February 2010. 607 Appendix A. Change Log 608 Authors' Addresses 610 Roque Gagliano 611 Cisco Systems 612 Avenue des Uttins 5 613 Rolle, 1180 614 Switzerland 616 Email: rogaglia@cisco.com 618 Stephen Kent 619 BBN Technologies 620 10 Moulton St. 621 Cambridge, MA 02138 622 USA 624 Email: kent@bbn.com 626 Sean Turner 627 IECA, Inc. 628 3057 Nutley Street, Suite 106 629 Fairfax, VA 22031 630 USA 632 Email: turners@ieca.com