< draft-ietf-sidr-algorithm-agility-06.txt   draft-ietf-sidr-algorithm-agility-07.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: December 28, 2012 BBN Technologies Expires: March 27, 2013 BBN Technologies
S. Turner S. Turner
IECA, Inc. IECA, Inc.
June 26, 2012 September 23, 2012
Algorithm Agility Procedure for RPKI. Algorithm Agility Procedure for RPKI.
draft-ietf-sidr-algorithm-agility-06 draft-ietf-sidr-algorithm-agility-07
Abstract Abstract
This document specifies the process that Certification Authorities This document specifies the process that Certification Authorities
(CAs) and Relying Parties (RPs) participating in the Resource Public (CAs) and Relying Parties (RPs) 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 December 28, 2012. This Internet-Draft will expire on March 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . 7 4. Key Rollover steps for algorithm migration . . . . . . . . . . 8
4.1. Milestones definition . . . . . . . . . . . . . . . . . . 7 4.1. Milestones definition . . . . . . . . . . . . . . . . . . 8
4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 7 4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 8
4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 11
4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 15 4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 16
5. Multi Algorithm support in the RPKI provisioning protocol . . 16 5. Multi Algorithm support in the RPKI provisioning protocol . . 17
6. Validation of multiple instance of signed products . . . . . . 17 6. Validation of multiple instance of signed products . . . . . . 18
7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Repository structure . . . . . . . . . . . . . . . . . . . . . 20 9. Repository structure . . . . . . . . . . . . . . . . . . . . . 21
10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 21 10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
14. Normative References . . . . . . . . . . . . . . . . . . . . . 26 14. Normative References . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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 7, line 5 skipping to change at page 6, line 49
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 request submitted by the subject. in the certificate request submitted by the subject.
Signed Product Set (or Set or Product Set): A collection of Signed Product Set (or Set or Product Set): A collection of
certificates, signed objects, a CRL and a manifest that certificates, signed objects, a CRL and a manifest that
are associated by virtue of being verifiable under the are associated by virtue of being verifiable under the
same parent CA certificate same parent CA certificate
Correspond: Two certificates, issued under different Algorithm Suites
correspond to one another if they are issued to the same
entity by the same CA and bind identical Internet Number
Resoureces (INRs) to that entity. Two CRLs correspond if
they are issued by the same CA and enumerate
corresponding certificates. Two signed objects (other
than manifests) correspond if they are verified using
corresponding EE certificates and they contain the same
encapsulated Context Info field. Two manifests
correspond if they encompass corresponding certificates,
ROAs, CRLs, and (other) signed objects (the term
"equivalent" is used synonymously when referring to such
RPKI signed products.)
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 [RFC6485]. When a migration of the RPKI CP document, by reference to [RFC6485]. When a migration of the RPKI
algorithm suite is needed, the first step MUST be an update of algorithm suite is needed, the first step MUST be an update of
[RFC6485] to define the new algorithm suite. The algorithm [RFC6485] to define the new algorithm suite. The algorithm
transition timeline document MUST also be published (as a BCP), to transition timeline document MUST also be published (as a BCP), to
inform the community of the dates selected for milestones in the inform the community of the dates selected for milestones in the
transition process, as described in Section 4.1. transition process, as described in Section 4.1.
skipping to change at page 12, line 28 skipping to change at page 13, line 28
|-> 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 set MUST be available using both Algorithm phase, each signed product set MUST be available using both Algorithm
Suite A and Algorithm Suite B. During this phase, RPs MUST be Suite A and Algorithm Suite B. Thus, prior to the start of this
prepared to validate sets issued using Algorithm Suite A and MAY be phase, every CA MUST ensure that there is a Suite B product
prepared to validate sets issued using the Algorithm Suite B. corresponding to each Suite A product that the CA has issued.
Throughout this Phase, each CA MUST maintain this correspondence.
During this phase, RPs MUST be prepared to validate sets issued using
Algorithm Suite A and MAY be 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
skipping to change at page 13, line 38 skipping to change at page 14, line 42
|-> CA-Z-Signed-Objects-Algorithm-Suite-B |-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> 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.6. Phase 3 4.6. Phase 3
Phase 3 starts at the RP Ready Algorithm B Date. During this phase, Phase 3 starts at the RP Ready Algorithm B Date. During this phase,
all signed product sets are available using both algorithm suites and all signed product sets are available using both algorithm suites and
all RPs MUST be able to validate them. It is RECOMMENDED that, in all RPs MUST be able to validate them. (The correspondence between
preparation for Phase 4, RPs retrieve and process Suite B product Suite A and Suite B products was required for Phase 2, and maintained
sets first, and treat them as the preferred product sets for throughout that Phase. The same requirements apply throughout this
validation throughout this phase. Thus an RP SHOULD try to validate Phase.) It is RECOMMENDED that, in preparation for Phase 4, RPs
the sets of signed products retrieved from the Algorithm Suite B retrieve and process Suite B product sets first, and treat them as
repository first. the preferred product sets for validation throughout this phase.
Thus an RP SHOULD try to validate the sets of signed products
retrieved from the Algorithm Suite B repository first.
If a substantial number of RPs are unable to process product sets If a substantial number of RPs are unable to process product sets
signed with Suite B, the algorithm transition timeline document MUST signed with Suite B, the algorithm transition timeline document MUST
be reissued, pushing back the date for this and later milestones, as be reissued, pushing back the date for this and later milestones, as
discussed in Section 4.2. Since the Suite B products SHOULD be discussed in Section 4.2. Since the Suite B products SHOULD be
published at distinct publication points, RPs that cannot process published at distinct publication points, RPs that cannot process
Suite B products can be expected to revert to the Suite A products Suite B products can be expected to revert to the Suite A products
that still exist. If the Suite B algorithm is deemed unsuitable, the that still exist. If the Suite B algorithm is deemed unsuitable, the
algorithm transition timeline and the algorithm specification algorithm transition timeline and the algorithm specification
documents MUST be replaced and the Algorithm Suite B MUST be documents MUST be replaced and the Algorithm Suite B MUST be
skipping to change at page 17, line 9 skipping to change at page 18, line 9
Upon receipt of a certificate request from a child CA, a parent CA Upon receipt of a certificate request from a child CA, a parent CA
will verify the PoP of the private key. If a child CA requests will verify the PoP of the private key. If a child CA requests
issuing a certificate using an algorithm suite that does not match a issuing a certificate using an algorithm suite that does not match a
resource class, the PoP validation will fail and the request will not resource class, the PoP validation will fail and the request will not
be performed. be performed.
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 corresponding instances of the same signed product when validating corresponding signed products using different
signed with different algorithm suites. algorithm suites.
During Phase 1 two (corresponding) instances MAY be available for During Phase 1 two (corresponding) instances MAY be available for
each signed product, one signed under Algorithm Suite A and one under each signed product, one signed under Algorithm Suite A and one under
Algorithm Suite B. As noted in Section 4.4, in this phase there is a Algorithm Suite B. As noted in Section 4.4, in this phase there is a
preference for Suite A product sets. All products are available preference for Suite A product sets. All products are available
under Suite A, while only some products may be available under Suite under Suite A, while only some products may be available under Suite
B. For production purposes an RP MAY fetch and validate only Suite A B. For production purposes an RP MAY fetch and validate only Suite A
products. Suite B products SHOULD be fetched and validated only for products. Suite B products SHOULD be fetched and validated only for
test purposes. When product sets exist under both Suites, they test purposes. When product sets exist under both Suites, they
should yield equivalent results, which facilitates testing. (It is should yield equivalent results, which facilitates testing. (It is
skipping to change at page 18, line 9 skipping to change at page 19, line 9
During Phase 4 only Suite A (previously Suite B) product sets are During Phase 4 only Suite A (previously Suite B) product sets are
required to be present for all RPKI entities, as per Section 4.7. required to be present for all RPKI entities, as per Section 4.7.
Thus RPs SHOULD retrieve and validate only these product sets. Thus RPs SHOULD retrieve and validate only these product sets.
Retrieval of Suite C (old Suite A) products sets may yield an Retrieval of Suite C (old Suite A) products sets may yield an
incomplete set of signed products and is NOT RECOMMENDED. incomplete set of signed products and is NOT RECOMMENDED.
7. Revocation 7. Revocation
The algorithm migration process mandates the maintenance of two The algorithm migration process mandates the maintenance of two
parallel but equivalent certification hierarchies during Phases 2 and parallel but equivalent certification hierarchies during Phases 2 and
3 of the process. During these phases, a CA MUST revoke certificates 3 of the process. During these phases, a CA MUST revoke and request
consistently under both algorithm Suites. When not performing a key revocation of certificates consistently under both algorithm Suites.
rollover operation (as described in Section 8), a CA requesting the When not performing a key rollover operation (as described in Section
revocation of its certificate during these two phases MUST perform 8), a CA requesting the revocation of its certificate during these
that request for both algorithm suites (A and B). A non-leaf CA two phases MUST perform that request for both algorithm suites (A and
SHOULD NOT verify that its child CAs comply with this requirement. B). A non-leaf CA SHOULD NOT verify that its child CAs comply with
Note that a CA MUST request revocation of its certificate relative to this requirement. Note that a CA MUST request revocation of its
a specific algorithm suite using the mechanism described in Section 5 certificate relative to a specific algorithm suite using the
mechanism described in Section 5
During Phase 1, a CA that revokes a certificate under Suite A SHOULD During Phase 1, a CA that revokes a certificate under Suite A SHOULD
revoke the corresponding certificate under Suite B, if that revoke the corresponding certificate under Suite B, if that
certificate exists. During Phase 4, a CA that revokes a certificate certificate exists. During Phase 4, a CA that revokes a certificate
under Suite A SHOULD revoke the corresponding certificate under Suite under Suite A SHOULD revoke the corresponding certificate under Suite
C, if that certificate exists. C, if that certificate exists.
During Phase 1, a CA may revoke certificates under Suite B without During Phase 1, a CA may revoke certificates under Suite B without
revoking them under Suite A, since the Suite B products are for test revoking them under Suite A, since the Suite B products are for test
purposes. During Phase 4 a CA may revoke certificates issued under purposes. During Phase 4 a CA may revoke certificates issued under
skipping to change at page 27, line 10 skipping to change at page 28, line 10
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
Protocol for Provisioning Resource Certificates", Protocol for Provisioning Resource Certificates",
RFC 6492, February 2012. RFC 6492, February 2012.
Appendix A. Change Log Appendix A. Change Log
Note to the RFC Editor: Please remove this section before Note to the RFC Editor: Please remove this section before
publication. publication.
From 06 to 07:
1. Added definition for "Correspond"
2. Added reference of correspondence between suites in phase 2 and 3
3. Small nit on the revocation definition.
From 05 to 06: From 05 to 06:
1. Added reference to published RFCs 1. Added reference to published RFCs
2. Removed requirement on dates format 2. Removed requirement on dates format
3. Changed revocation section to emphasize the differences between 3. Changed revocation section to emphasize the differences between
phase 1,2,3 and 4. phase 1,2,3 and 4.
4. Added Section 10: Deprecating an Algorithm Suite 4. Added Section 10: Deprecating an Algorithm Suite
 End of changes. 11 change blocks. 
45 lines changed or deleted 74 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/