< draft-ietf-sidr-algorithm-agility-04.txt   draft-ietf-sidr-algorithm-agility-05.txt >
Network Working Group R. Gagliano Network Working Group R. Gagliano
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track S. Kent Intended status: Standards Track S. Kent
Expires: June 1, 2012 BBN Technologies Expires: July 20, 2012 BBN Technologies
S. Turner S. Turner
IECA, Inc. IECA, Inc.
November 29, 2011 January 17, 2012
Algorithm Agility Procedure for RPKI. Algorithm Agility Procedure for RPKI.
draft-ietf-sidr-algorithm-agility-04 draft-ietf-sidr-algorithm-agility-05
Abstract Abstract
This document specifies the process that Certification Authorities This document specifies the process that Certification Authorities
(CAs) and Relying Parties (RP) participating in the Resource Public (CAs) and Relying Parties (RP) participating in the Resource Public
Key Infrastructure (RPKI) will need to follow to transition to a new Key Infrastructure (RPKI) will need to follow to transition to a new
(and probably cryptographically stronger) algorithm set. The process (and probably cryptographically stronger) algorithm set. The process
is expected to be completed in a time scale of months or years. is expected to be completed in a time scale of months or years.
Consequently, no emergency transition is specified. The transition Consequently, no emergency transition is specified. The transition
procedure defined in this document supports only a top-down migration procedure defined in this document supports only a top-down migration
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2012. This Internet-Draft will expire on July 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Rollover steps for algorithm migration . . . . . . . . . . 8 4. Key Rollover steps for algorithm migration . . . . . . . . . . 7
4.1. Milestones definition . . . . . . . . . . . . . . . . . . 8 4.1. Milestones definition . . . . . . . . . . . . . . . . . . 7
4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 8 4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 7
4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 10
4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 16 4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 15
5. Multi Algorithm support in the RPKI provisioning protocol . . 17 5. Multi Algorithm support in the RPKI provisioning protocol . . 16
6. Validation of multiple instance of signed products . . . . . . 18 6. Validation of multiple instance of signed products . . . . . . 17
7. Revocations . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Revocations . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Repository structure . . . . . . . . . . . . . . . . . . . . . 21 9. Repository structure . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 26 13.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
The RPKI must accommodate transitions between the public keys used by The RPKI must accommodate transitions between the public keys used by
skipping to change at page 4, line 51 skipping to change at page 4, line 51
support of a "current" and "next" suite for a prolonged interval, support of a "current" and "next" suite for a prolonged interval,
probably several years. probably several years.
This document defines how entities in the RPKI execute (planned) CA This document defines how entities in the RPKI execute (planned) CA
key rollover when the algorithm suite changes. The description key rollover when the algorithm suite changes. The description
covers actions by CAs, repository operators, and RPs. It describes covers actions by CAs, repository operators, and RPs. It describes
the behavior required of both CAs and RPs to make such key changes the behavior required of both CAs and RPs to make such key changes
work in the RPKI context, including how the RPKI repository system is work in the RPKI context, including how the RPKI repository system is
used to support key rollover. used to support key rollover.
This document does not specify any algorithm suite.
This document does not specify any algorithm suite per se. The RPKI This document does not specify any algorithm suite per se. The RPKI
Certificate Policy (CP) [I-D.ietf-sidr-cp] mandates the use of the Certificate Policy (CP) [I-D.ietf-sidr-cp] mandates the use of the
algorithms defined in [I-D.ietf-sidr-rpki-algs] by CAs and RPs. When algorithms defined in [I-D.ietf-sidr-rpki-algs] by CAs and RPs. When
an algorithm transition is initiated, [I-D.ietf-sidr-rpki-algs] will an algorithm transition is initiated, [I-D.ietf-sidr-rpki-algs] will
be updated (as defined in Section 4.1 of this document) redefining be updated (as defined in Section 4.1 of this document) redefining
the required algorithm(s) for compliant RPKI CAs and RPs under the the required algorithm(s) for compliant RPKI CAs and RPs under the
CP. The CP will not change as a side effect of algorithm transition CP. The CP will not change as a side effect of algorithm transition
(and thus the policy OID in RPKI certificates will not change.) (and thus the policy OID in RPKI certificates will not change.)
An additional document, the algorithm transition timetable, will be An additional document, the algorithm transition timetable, will be
published (as a BCP) to define the dates for each milestone defined published (as a BCP) to define the dates for each milestone defined
in this document. It will define dates for the phase transitions, in this document. It will define dates for the phase transitions,
consistent with the descriptions provided in Section 4. It also will consistent with the descriptions provided in Section 4. It also will
describe how the RPKI community will measure the readiness of CAs and describe how the RPKI community will measure the readiness of CAs and
RPs to transition to each phase. CAs publish certificates, CRLs, and RPs to transition to each phase. CAs publish certificates, CRLs, and
other signed objects under the new algorithm suite as the transition other signed objects under the new algorithm suite as the transition
progresses. This provides visibility into the deployment of the new progresses. This provides visibility into the deployment of the new
algorithm suite, enabling the community to evaluate deployment algorithm suite, enabling the community to evaluate deployment
progress. The transition procedure allows CAs to remove old progress. The transition procedure allows CAs to remove old
certificates, CRLs, and signed products, during the twilight phase. certificates, CRLs, and signed products, after the twilight date.
This provides an ability to observe and measure the withdrawal of the This provides an ability to observe and measure the withdrawal of the
old algorithm suite. Thus the phases defined in this document enable old algorithm suite. Thus the phases defined in this document enable
the community to evaluate the progress of the transition. The the community to evaluate the progress of the transition. The
timetable document will also describe procedures to amend the timetable document will also describe procedures to amend the
timetable if problems arise in implementing later phases of the timetable if problems arise in implementing later phases of the
transition. It is RECOMMENDED that the timetable document be transition. It is RECOMMENDED that the timetable document be
developed by representatives of the RPKI community, e.g., IANA, developed by representatives of the RPKI community, e.g., IANA,
Internet Registries, and network operators. Internet Registries, and network operators.
3. Terminology 3. Terminology
This document assumes that the reader is familiar with the terms and This document assumes that the reader is familiar with the terms and
concepts described in "Internet X.509 Public Key Infrastructure concepts described in "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], Certificate and Certificate Revocation List (CRL) Profile" [RFC5280],
"X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and
"A Profile for Resource Certificate Repository Structure" "A Profile for Resource Certificate Repository Structure"
[I-D.ietf-sidr-repos-struct]. Additional terms and conventions use [I-D.ietf-sidr-repos-struct]. Additional terms and conventions used
in examples are provided below. in examples are provided below.
Algorithm migration A planned transition from one signature and hash Algorithm migration A planned transition from one signature and hash
algorithm to a new signature and hash algorithm. algorithm to a new signature and hash algorithm.
Algorithm Suite A The "current" algorithm suite used for hashing and Algorithm Suite A The "current" algorithm suite used for hashing and
signing, in examples in this document signing, in examples in this document
Algorithm Suite B The "next" algorithm suite used for hashing and Algorithm Suite B The "next" algorithm suite used for hashing and
signing, used in examples in this document signing, used in examples in this document
Algorithm Suite C The "old" algorithm suite used for hashing and Algorithm Suite C The "old" algorithm suite used for hashing and
signing, used in examples in this document signing, used in examples in this document
CA X The CA that issued CA Y's certificate (i.e., CA Y's CA X The CA that issued CA Y's certificate (i.e., CA Y's
parent), used in examples in this document. parent), used in examples in this document.
CA Y The CA that is changing keys and/or algorithm suites, CA Y The non-leaf CA used in examples this document
used in examples this document
CA Z A CA that is a "child" of CA Y, used in examples this CA Z A CA that is a "child" of CA Y, used in examples this
document document
Certificate re-issuance (unilateral) A CA MAY reissue a certificate
to a subordinate Subject without the involvement of the
Subject. The public key, resource extensions, and most
other fields are copied from the current Subject
certificate into the next Subject certificate. The
Issuer name MAY change, if necessary to reflect the
Subject name in the CA certificate under which the
reissued certificate will be validated. The validity
interval also MAY be changed. This action is defined as
a unilateral certificate re-issuance.
Non-Leaf CA A CA that issues certificates to other CAs is a non-leaf Non-Leaf CA A CA that issues certificates to other CAs is a non-leaf
CA. CA.
Leaf CA A leaf CA is a CA that issues only EE certs. Leaf CA A leaf CA is a CA that issues only EE certs.
PoP (proof of possession) Execution of a protocol that demonstrates PoP (proof of possession) Execution of a protocol that demonstrates
to an issuer that a subject requesting a certificate to an issuer that a subject requesting a certificate
possesses the private key corresponding to the public key possesses the private key corresponding to the public key
in the certificate submitted by the subject. in the certificate submitted by the subject.
Signed Product Set (or Set) A collection of certificates, signed Signed Product Set (or Set or Product Set) A collection of
objects, a CRL and a manifest that are associated by certificates, signed objects, a CRL and a manifest that
virtue of being verifiable under the same parent CA are associated by virtue of being verifiable under the
certificate same parent CA certificate
4. Key Rollover steps for algorithm migration 4. Key Rollover steps for algorithm migration
The "current" RPKI algorithm suite (Suite A) is defined in the RPKI The "current" RPKI algorithm suite (Suite A) is defined in the RPKI
CP document, by reference to [I-D.ietf-sidr-rpki-algs]. When a CP document, by reference to [I-D.ietf-sidr-rpki-algs]. When a
migration of the RPKI algorithm suite is needed, the first step MUST migration of the RPKI algorithm suite is needed, the first step MUST
be an update of the [I-D.ietf-sidr-rpki-algs] document to define the be an update of the [I-D.ietf-sidr-rpki-algs] document to define the
new algorithm suite. The algorithm transition timeline document MUST new algorithm suite. The algorithm transition timeline document MUST
also be published, to inform the community of the dates selected for also be published (as a BCP), to inform the community of the dates
milestones in the transition process, as described in Section 4.3. selected for milestones in the transition process, as described in
Section 4.1.
4.1. Milestones definition 4.1. Milestones definition
CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST
be ready to process a request from a child CA to issue a be ready to process a request from a child CA to issue a
certificate under the Algorithm B suite. certificate under the Algorithm B suite.
CA Go Algorithm B Date - After this date, all (non-leaf) CAs MUST CA Go Algorithm B Date - After this date, all (non-leaf) CAs MUST
have re-issued all of its signed product set under the have reissued all of their signed product sets under the
Algorithm B suite. Algorithm B suite.
RP Ready Algorithm B Date - After this date, all RPs MUST be RP Ready Algorithm B Date - After this date, all RPs MUST be
prepared to process signed material issued under the prepared to process signed material issued under the
Algorithm B suite. Algorithm B suite.
Twilight Algorithm B - After this date, a CA MAY cease issuing Twilight Algorithm B - After this date, a CA MAY cease issuing
signed products under the Algorithm A suite. Also, after signed products under the Algorithm A suite. Also, after
this date, a RP MAY cease to validate signed materials this date, a RP MAY cease to validate signed materials
issued under the Algorithm A suite. issued under the Algorithm A suite.
skipping to change at page 9, line 9 skipping to change at page 8, line 10
In order to facilitate the transition, CAs will start issuing In order to facilitate the transition, CAs will start issuing
certificates using the Algorithm B in a hierarchical top-down certificates using the Algorithm B in a hierarchical top-down
fashion. In our example, CA Y will issue certificates using the fashion. In our example, CA Y will issue certificates using the
Algorithm B suite only after CA X has started to do so (CA Y Ready Algorithm B suite only after CA X has started to do so (CA Y Ready
Algorithm B Date > CA X Ready Algorithm B Date). This ordered Algorithm B Date > CA X Ready Algorithm B Date). This ordered
transition avoids issuance of "mixed" suite certificates, e.g., a CA transition avoids issuance of "mixed" suite certificates, e.g., a CA
certificate signed using Suite A, containing a key from Suite B. In certificate signed using Suite A, containing a key from Suite B. In
the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key
that corresponds to an algorithm suite that differs from the one used that corresponds to an algorithm suite that differs from the one used
to sign the certificate.(X.509 accommodates such mixed algorithm to sign the certificate (X.509 accommodates such mixed algorithm
certificates, but this process avoids using that capability. A not certificates, but this process avoids using that capability.) A not
top-down transition approach would require use of such mixed mode top-down transition approach would require use of such mixed mode
certificates, but this would lead to exponential growth of the RPKI certificates, but this would lead to exponential growth of the RPKI
repository. Also, because the RPKI CP mandates "proof of possession" repository. Also, because the RPKI CP mandates "proof of possession"
for certificate requests, it is not possible for a CA to request a for certificate requests, it is not possible for a CA to request a
certificate for Algorithm Suite B, until its parent CA supports that certificate for Algorithm Suite B, until its parent CA supports that
Suite. See Section 5 for more details.) Suite. (See Section 5 for more details.)
The algorithm agility model described here does not prohibit a CA The algorithm agility model described here does not prohibit a CA
from issuing an EE certificate with a subject public key from a from issuing an EE certificate with a subject public key from a
different algorithm suite, if that certificate is not used to verify different algorithm suite, if that certificate is not used to verify
repository objects. This exception to the mixed algorithm suite repository objects. This exception to the mixed algorithm suite
certificate rule is allowed because an EE certificate that is not certificate rule is allowed because an EE certificate that is not
used to verify repository objects does not interfere with the ability used to verify repository objects does not interfere with the ability
of RPs to download and verify repository content. As noted above, of RPs to download and verify repository content. As noted above,
every CA in the RPKI is required to perform a Proof of Possession every CA in the RPKI is required to perform a Proof of Possession
(PoP) check for the subject public key when issuing a certificate. (PoP) check for the subject public key when issuing a certificate.
skipping to change at page 10, line 34 skipping to change at page 9, line 34
(4) RP Ready Algorithm B Date (4) RP Ready Algorithm B Date
(5) Twilight Date (5) Twilight Date
(6) End Of Live (EOL) Date (6) End Of Live (EOL) Date
Each of these milestones is discussed in the next section as part of Each of these milestones is discussed in the next section as part of
describing each phase of the transition process. describing each phase of the transition process.
Two situations have been identified that motivate pausing or rolling Two situations have been identified that motivate pausing or rolling
back the transition process. The first situation arises if the RPKI back the transition process. The first situation arises if the RPKI
community is not ready to make the transition. For example, many CAs community is not ready to make the transition. For example, many CAs
might not prepared to issue signed products under Suite B, or many might not be prepared to issue signed products under Suite B, or many
RPs might be ready to process Suite B product sets. Under these RPs might not be ready to process Suite B product sets. Under these
circumstances, the timetable MUST be reissued, postponing the date circumstances, the timetable MUST be reissued, postponing the date
for the phase in question, and pushing back the dates for later for the phase in question, and pushing back the dates for later
phases. The other situation arises if, during the transition, phases. The other situation arises if, during the transition,
serious concerns arise about the security of the Suite B algorithms. serious concerns arise about the security of the Suite B algorithms.
Such concerns would motivate terminating the transition and rolling Such concerns would motivate terminating the transition and rolling
back signed products, i.e., reverting to Suite A. In this case the back signed products, i.e., reverting to Suite A. In this case the
timetable MUST be republished, and the RPKI algorithm document MUST timetable MUST be republished, and the RPKI algorithm document MUST
be superseded. The phase descriptions below allude to these two be superseded. The phase descriptions below allude to these two
situations, as appropriate. situations, as appropriate.
skipping to change at page 12, line 16 skipping to change at page 11, line 16
4.4. Phase 1 4.4. Phase 1
Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all
(non-leaf) CAs MUST be ready to process a request from a child CA to (non-leaf) CAs MUST be ready to process a request from a child CA to
issue or revoke a certificate using the Algorithm B suite. If it is issue or revoke a certificate using the Algorithm B suite. If it is
determined that a substantial number of CAs are not ready, the determined that a substantial number of CAs are not ready, the
algorithm transition timeline document will be reissued, as noted in algorithm transition timeline document will be reissued, as noted in
Section 4.2. However, CAs that are capable of issuing Suite B Section 4.2. However, CAs that are capable of issuing Suite B
certificates may continue to do so, if requested by their child CAs. certificates may continue to do so, if requested by their child CAs.
Since this phase does not require any RPs to process signed objects Since this phase does not require any RPs to process signed objects
under Suite B, and since Suite B product SHOULD be stored at under Suite B, and since Suite B product sets SHOULD be stored at
independent publication points, there is no adverse impact on RPs. independent publication points, there is no adverse impact on RPs.
If the Suite B algorithm is deemed unsuitable, the algorithm If the Suite B algorithm is deemed unsuitable, the algorithm
transition timeline and the algorithm specification documents MUST be transition timeline and the algorithm specification documents MUST be
replaced. CAs MUST cease accepting requests for certificates under replaced, CAs MUST cease accepting requests for certificates under
Suite B, and Suite B certificates that have been issued MUST be Suite B, and Suite B certificates that have been issued MUST be
revoked. revoked.
As the transition will happen using a (hierarchic) top-down model, a As the transition will happen using a (hierarchic) top-down model, a
child CA will be able to issue certificates using the Algorithm B child CA will be able to issue certificates using the Algorithm B
suite only after its parent CA has issued its own. The RPKI suite only after its parent CA has issued its own. The RPKI
provisioning protocol can identify if a parent CA is capable of provisioning protocol can identify if a parent CA is capable of
issuing certificates using the Algorithm Suite B, and can identify issuing certificates using the Algorithm Suite B, and can identify
the corresponding algorithm suite in each Certificate Signing Request the corresponding algorithm suite in each Certificate Signing Request
(see Section 5). (see Section 5).
skipping to change at page 13, line 27 skipping to change at page 12, line 27
| |
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB) |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB) |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B |-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB) |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B |-> CA-X-Signed-Objects-Algorithm-Suite-B
4.5. Phase 2 4.5. Phase 2
Phase 2 starts at the CA Go Algorithm B Date. At the start of this Phase 2 starts at the CA Go Algorithm B Date. At the start of this
phase, each signed product sets MUST be available using both phase, each signed product set MUST be available using both Algorithm
Algorithm Suite A and Algorithm Suite B. During this phase, RPs MUST Suite A and Algorithm Suite B. During this phase, RPs MUST be
be prepared to validate sets issued using Algorithm Suite A and MAY prepared to validate sets issued using Algorithm Suite A and MAY be
be prepared to validate sets issued using the Algorithm Suite B. prepared to validate sets issued using the Algorithm Suite B.
If it is determined that a substantial number of CAs are not ready, If it is determined that a substantial number of CAs are not ready,
the algorithm transition timeline document will be reissued, as noted the algorithm transition timeline document will be reissued, as noted
in Section 4.2.. (Since the processing requirement for RPs here is a in Section 4.2. (Since the processing requirement for RPs here is a
MAY, if RPs have problems with Suite B products this does not require MAY, if RPs have problems with Suite B products this does not require
pushing back the Phase 2 milestone, but it does motivate delaying the pushing back the Phase 2 milestone, but it does motivate delaying the
start of Phase 3.) CAs that are capable of publishing products under start of Phase 3.) CAs that are capable of publishing products under
Suite B MAY continue to do so. Phase 2, like Phase 1, does not Suite B MAY continue to do so. Phase 2, like Phase 1, does not
require any RPs to process signed objects under Suite B. Also, Suite require any RPs to process signed objects under Suite B. Also, Suite
B product SHOULD be stored at independent publication points, so B product SHOULD be stored at independent publication points, so
there is no adverse impact on RPs. If the Suite B algorithm is there is no adverse impact on RPs. If the Suite B algorithm is
deemed unsuitable, the algorithm transition timeline and the deemed unsuitable, the algorithm transition timeline and the
algorithm specification documents MUST be replaced. CAs MUST cease algorithm specification documents MUST be replaced. CAs MUST cease
accepting requests for certificates under Suite B, and Suite B accepting requests for certificates under Suite B, and Suite B
certificates that have been issued MUST be revoked. certificates that have been issued MUST be revoked.
An RP that validates all signed product sets using both Algorithm An RP that validates all signed product sets using both Algorithm
Suite A or Algorithm Suite B, SHOULD expect the same results. Suite A or Algorithm Suite B SHOULD expect the same results.
However, an object that validates using either Algorithm Suite A or However, an object that validates using either Algorithm Suite A or
Algorithm Suite B MUST be considered valid. A detailed analysis on Algorithm Suite B MUST be considered valid. A detailed analysis on
the validation of multiple instance of signed objects is included in the validation of multiple instances of signed objects is included in
Section 6. Section 6
The following figure shows the status of the repository entries for The following figure shows the status of the repository entries for
the three example CAs throughout this phase, where all signed objects the three example CAs throughout this phase, where all signed objects
are available using both algorithm suites. are available using both algorithm suites.
CA X-Certificate-Algorithm-Suite-A (Cert-XA) CA X-Certificate-Algorithm-Suite-A (Cert-XA)
| |
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A |-> CA-Z-Signed-Objects-Algorithm-Suite-A
skipping to change at page 15, line 25 skipping to change at page 14, line 25
Before Twilight --> After Twilight Before Twilight --> After Twilight
Algorithm Suite A ("current") --> Algorithm Suite C ("old") Algorithm Suite A ("current") --> Algorithm Suite C ("old")
Algorithm Suite B ("new") --> Algorithm Suite A ("current") Algorithm Suite B ("new") --> Algorithm Suite A ("current")
During this phase, all signed product sets MUST be issued using During this phase, all signed product sets MUST be issued using
Algorithm Suite A (formerly B) and MAY be issued using Algorithm Algorithm Suite A (formerly B) and MAY be issued using Algorithm
Suite C (formerly A). All signed products sets issued using Suite A Suite C (formerly A). All signed products sets issued using Suite A
MUST be published at their corresponding publication points, but MUST be published at their corresponding publication points, but
signed products sets issued using Suite C MAY be published at their signed products sets issued using Suite C MAY NOT be published at
corresponding publication points. Also, every RP MUST their corresponding publication points. Also, every RP MUST
validate signed product sets using Suite A but also MAY validate validate signed product sets using Suite A but also MAY validate
signed product sets using Suite C. However, RPs SHOULD NOT assume the signed product sets using Suite C. However, RPs SHOULD NOT assume the
Suite C repository is complete. Suite C repository is complete.
If it is determined that many RPs are not capable of processing the If it is determined that many RPs are not capable of processing the
new algorithm suite, the algorithm transition timeline document MUST new algorithm suite, the algorithm transition timeline document MUST
be reissued pushing back the date for this and the next milestone. be reissued pushing back the date for this and the next milestone.
The document MUST requires CA to not remove Suite C (old Suite A) The document MUST requires CA to not remove Suite C product sets if
product sets if this phase is delayed. If the Suite B algorithm is this phase is delayed. If the Suite B algorithm is deemed
deemed unsuitable, the algorithm transition timeline and the unsuitable, the algorithm transition timeline and the algorithm
algorithm specification documents MUST be replaced. CAs MUST cease specification documents MUST be replaced. CAs MUST cease accepting
accepting requests for certificates under Suite B, and Suite B requests for certificates under Suite A (formal Suite A), and Suite A
certificates that have been issued MUST be revoked. At this stage, certificates that have been issued MUST be revoked. At this stage,
RPs are still capable of processing old Suite A signed products. RPs are still capable of processing Suite C signed products.
The following figure describes a possible status for the repositories The following figure describes a possible status for the repositories
of the example CAs. In this case, CA Z no longer issues signed of the example CAs. In this case, CA Z no longer issues signed
products using the Algorithm Suite C. products using the Algorithm Suite C.
CA X-Certificate-Algorithm-Suite-C (Cert-XC) CA X-Certificate-Algorithm-Suite-C (Cert-XC)
| |
|-> CA-Y-Certificate-Algorithm-Suite-C (Cert-YC) |-> CA-Y-Certificate-Algorithm-Suite-C (Cert-YC)
|-> CA-Y-CRL-Algorithm-Suite-C (CRL-YC) |-> CA-Y-CRL-Algorithm-Suite-C (CRL-YC)
|-> CA-Y-Signed-Objects-Algorithm-Suite-C |-> CA-Y-Signed-Objects-Algorithm-Suite-C
skipping to change at page 16, line 37 skipping to change at page 15, line 37
At this phase, ALL signed product sets using Algorithm Suite C MUST At this phase, ALL signed product sets using Algorithm Suite C MUST
be considered invalid. CAs MUST neither issue nor publish signed be considered invalid. CAs MUST neither issue nor publish signed
products using Algorithm Suite C. products using Algorithm Suite C.
This phase closes the loop as Algorithm Suite A is the only required This phase closes the loop as Algorithm Suite A is the only required
algorithm suite in RPKI. algorithm suite in RPKI.
If it is determined that many RPs are not capable of processing the If it is determined that many RPs are not capable of processing the
new algorithm suite, the algorithm transition timeline document MUST new algorithm suite, the algorithm transition timeline document MUST
be reissued pushing back the date for this milestone. CAs MUST NOT be reissued pushing back the date for this milestone. CAs MUST NOT
remove Suite C (old Suite A) product sets if this phase is delayed. remove Suite C product sets if this phase is delayed.
5. Multi Algorithm support in the RPKI provisioning protocol 5. Multi Algorithm support in the RPKI provisioning protocol
The migration described in this document is a top-down process, where The migration described in this document is a top-down process, where
two synchronization issues need to be solved between child and parent two synchronization issues need to be solved between child and parent
CAs: CAs:
o A child CA needs to identify which algorithm suites are supported o A child CA needs to identify which algorithm suites are supported
by its parent CA by its parent CA
skipping to change at page 18, line 15 skipping to change at page 17, line 15
6. Validation of multiple instance of signed products 6. Validation of multiple instance of signed products
During Phases 1,2,3 and 4, two algorithm suites will be valid During Phases 1,2,3 and 4, two algorithm suites will be valid
simultaneously in RPKI. In this section, we describe the RP behavior simultaneously in RPKI. In this section, we describe the RP behavior
when validating instances of the same signed product but signed with when validating instances of the same signed product but signed with
different algorithm suites. As a general rule, the validation of different algorithm suites. As a general rule, the validation of
signed products using different algorithm suites are independent and signed products using different algorithm suites are independent and
the RP MUST NOT keep any relationship between the different the RP MUST NOT keep any relationship between the different
hierarchies. hierarchies.
During Phase 1 two (corresponding) files for an object MAY be During Phase 1 two (corresponding) instances MAY be available for
available for each signed product, one signed under Algorithm Suite A each signed product, one signed under Algorithm Suite A and one under
and one under Algorithm Suite B. When an RP validates these signed Algorithm Suite B. When an RP validates these signed products, if
products, if either instance of an object validates, the product is either instance of an object validates, the product is accepted. A
accepted. A failure to validate one instance of a product, under failure to validate one instance of a product, under either algorithm
either algorithm Suite MUST NOT cause the RP to reject the other Suite MUST NOT cause the RP to reject the other instance of the
instance of the product. Because both instances of such products product. Because both instances of such products MUST contain the
MUST contain the same resources, relying on either instance will same resources, relying on either instance will yield the same
yield the same outcome. outcome.
During Phases 2 and 3 of this process, two (corresponding) instances During Phases 2 and 3 of this process, two (corresponding) instances
of all signed products MUST be available to RPs. As in Phase 1, when of all signed products MUST be available to RPs. As in Phase 1, when
an RP validates these signed products, if either instance validates, an RP validates these signed products, if either instance validates,
the product is accepted. A failure to validate one instance of a the product is accepted. A failure to validate one instance of a
product, under either algorithm Suite MUST NOT cause the RP to reject product, under either algorithm Suite MUST NOT cause the RP to reject
the other instance of the product. Also, as above, if only one the other instance of the product. Also, as above, if only one
instance of a signed product can be validated, subordinate products instance of a signed product can be validated, subordinate products
issued under the other (non-validated) algorithm suite cannot be issued under the other (non-validated) algorithm suite cannot be
used, and thus SHOULD NOT be processed (or even retrieved). used, and thus SHOULD NOT be processed (or even retrieved).
skipping to change at page 19, line 14 skipping to change at page 18, line 14
7. Revocations 7. Revocations
As the algorithm migration process mandates the maintenance of two As the algorithm migration process mandates the maintenance of two
parallel certificate hierarchies, revocations requests for each parallel certificate hierarchies, revocations requests for each
algorithm suite MUST be handled independently. A Child CA MUST algorithm suite MUST be handled independently. A Child CA MUST
request revocation of a certificate relative to a specific algorithm request revocation of a certificate relative to a specific algorithm
suite. suite.
During phase 2 and phase 3, the two parallel certificate hierarchies During phase 2 and phase 3, the two parallel certificate hierarchies
are designed to carry identical information. Consequently, a child are designed to carry identical information. When not performing a
CA requesting the revocation of a certificate during these two phases key rollover operation (which process is described in Section 8), a
MUST perform that request for both algorithm suites (A and B). A child CA requesting the revocation of a certificate during these two
non-leaf CA is NOT required to verify that its child CAs comply with phases MUST perform that request for both algorithm suites (A and B).
this requirement. A non-leaf CA is NOT required to verify that its child CAs comply
with this requirement.
8. Key rollover 8. Key rollover
Key rollover (without algorithm changes) is effected independently Key rollover (without algorithm changes) is effected independently
for each algorithm suite and MUST follow the process described in for each algorithm suite and MUST follow the process described in
[I-D.ietf-sidr-keyroll]. [I-D.ietf-sidr-keyroll].
9. Repository structure 9. Repository structure
The two parallel hierarchies that will exist during the transition The two parallel hierarchies that will exist during the transition
skipping to change at page 27, line 7 skipping to change at page 26, line 7
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
13.2. Informative References 13.2. Informative References
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010. Scheme", RFC 5781, February 2010.
Appendix A. Change Log Appendix A. Change Log
Note to the RFC Editor: Please remove this section before
publication.
From 04 to 05:
1. WGLC nits
From 03 to 04: From 03 to 04:
1. Added text for "roll-over" capability in each phase 1. Added text for "roll-over" capability in each phase
2. Added the requirement for splitting the milestone 1 in two 2. Added the requirement for splitting the milestone 1 in two
documents: the update of the alg document and a new document documents: the update of the alg document and a new document
specifying the particular timelines specifying the particular timelines
3. WGLC nits 3. WGLC nits
 End of changes. 30 change blocks. 
91 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/