Network Working Group R. Gagliano
Internet-Draft Cisco Systems
Intended status: Standards Track S. Kent
Expires: June 1, 2012 BBN Technologies
S. Turner
IECA, Inc.
November 29, 2011
Algorithm Agility Procedure for RPKI.
draft-ietf-sidr-algorithm-agility-04
Abstract
This document specifies the process that Certification Authorities
(CAs) and Relying Parties (RP) participating in the Resource Public
Key Infrastructure (RPKI) will need to follow to transition to a new
(and probably cryptographically stronger) algorithm set. The process
is expected to be completed in a time scale of months or years.
Consequently, no emergency transition is specified. The transition
procedure defined in this document supports only a top-down migration
(parent migrates before children).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Gagliano, et al. Expires June 1, 2012 [Page 1]
Internet-Draft RPKI Algorithm Agility November 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Rollover steps for algorithm migration . . . . . . . . . . 8
4.1. Milestones definition . . . . . . . . . . . . . . . . . . 8
4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 8
4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 11
4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 16
5. Multi Algorithm support in the RPKI provisioning protocol . . 17
6. Validation of multiple instance of signed products . . . . . . 18
7. Revocations . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Repository structure . . . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Gagliano, et al. Expires June 1, 2012 [Page 2]
Internet-Draft RPKI Algorithm Agility November 2011
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Gagliano, et al. Expires June 1, 2012 [Page 3]
Internet-Draft RPKI Algorithm Agility November 2011
2. Introduction
The RPKI must accommodate transitions between the public keys used by
CAs. Transitions of this sort are usually termed "key rollover".
Planned key rollover will occur at regular intervals throughout the
life of the RPKI, as each CA changes its public keys, in a non-
coordinated fashion. (By non-coordinated we mean that the time at
which each CA elects to change its keys is locally determined, not
coordinated across the RPKI.) Moreover, because a key change might
be necessitated by suspected private key compromise, one can never
assume coordination of these events among all of the CAs in the RPKI.
In an emergency key rollover, the old certificate is revoked and a
new certificate with a new key is issued. The mechanisms to perform
a key rollover in RPKI (either planned or in an emergency), while
maintaining the same algorithm suite, are covered in
[I-D.ietf-sidr-keyroll].
This document describes the mechanism to perform a key rollover in
RPKI due to the migration to a new signature algorithm suite. A
signature algorithm suite encompasses both a signature algorithm
(with a specified key size range) and a one-way hash algorithm. It
is anticipated that the RPKI will require the adoption of updated key
sizes and/or different algorithm suites over time. This document
treats the adoption of a new hash algorithm while retaining the
current signature algorithm as equivalent to an algorithm migration,
and requires the CA to change its key. Migration to a new algorithm
suite will be required in order to maintain an acceptable level of
cryptographic security and protect the integrity of certificates,
CRLs and signed objects in the RPKI. All of the data structures in
the RPKI explicitly identify the signature and hash algorithms being
used. However, experience has demonstrated that the ability to
represent algorithm IDs is not sufficient to enable migration to new
algorithm suites (algorithm agility). One also must ensure that
protocols, infrastructure elements, and operational procedures also
accommodate migration from one algorithm suite to another. Algorithm
migration is expected to be very infrequent, but it also will require
support of a "current" and "next" suite for a prolonged interval,
probably several years.
This document defines how entities in the RPKI execute (planned) CA
key rollover when the algorithm suite changes. The description
covers actions by CAs, repository operators, and RPs. It describes
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
used to support key rollover.
This document does not specify any algorithm suite.
Gagliano, et al. Expires June 1, 2012 [Page 4]
Internet-Draft RPKI Algorithm Agility November 2011
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
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
be updated (as defined in Section 4.1 of this document) redefining
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
(and thus the policy OID in RPKI certificates will not change.)
An additional document, the algorithm transition timetable, will be
published (as a BCP) to define the dates for each milestone defined
in this document. It will define dates for the phase transitions,
consistent with the descriptions provided in Section 4. It also will
describe how the RPKI community will measure the readiness of CAs and
RPs to transition to each phase. CAs publish certificates, CRLs, and
other signed objects under the new algorithm suite as the transition
progresses. This provides visibility into the deployment of the new
algorithm suite, enabling the community to evaluate deployment
progress. The transition procedure allows CAs to remove old
certificates, CRLs, and signed products, during the twilight phase.
This provides an ability to observe and measure the withdrawal of the
old algorithm suite. Thus the phases defined in this document enable
the community to evaluate the progress of the transition. The
timetable document will also describe procedures to amend the
timetable if problems arise in implementing later phases of the
transition. It is RECOMMENDED that the timetable document be
developed by representatives of the RPKI community, e.g., IANA,
Internet Registries, and network operators.
Gagliano, et al. Expires June 1, 2012 [Page 5]
Internet-Draft RPKI Algorithm Agility November 2011
3. Terminology
This document assumes that the reader is familiar with the terms and
concepts described in "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile" [RFC5280],
"X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and
"A Profile for Resource Certificate Repository Structure"
[I-D.ietf-sidr-repos-struct]. Additional terms and conventions use
in examples are provided below.
Algorithm migration A planned transition from one signature and hash
algorithm to a new signature and hash algorithm.
Algorithm Suite A The "current" algorithm suite used for hashing and
signing, in examples in this document
Algorithm Suite B The "next" algorithm suite used for hashing and
signing, used in examples in this document
Algorithm Suite C The "old" algorithm suite used for hashing and
signing, used in examples in this document
CA X The CA that issued CA Y's certificate (i.e., CA Y's
parent), used in examples in this document.
CA Y The CA that is changing keys and/or algorithm suites,
used in examples this document
CA Z A CA that is a "child" of CA Y, used in examples this
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
CA.
Gagliano, et al. Expires June 1, 2012 [Page 6]
Internet-Draft RPKI Algorithm Agility November 2011
Leaf CA A leaf CA is a CA that issues only EE certs.
PoP (proof of possession) Execution of a protocol that demonstrates
to an issuer that a subject requesting a certificate
possesses the private key corresponding to the public key
in the certificate submitted by the subject.
Signed Product Set (or Set) A collection of certificates, signed
objects, a CRL and a manifest that are associated by
virtue of being verifiable under the same parent CA
certificate
Gagliano, et al. Expires June 1, 2012 [Page 7]
Internet-Draft RPKI Algorithm Agility November 2011
4. Key Rollover steps for algorithm migration
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
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
new algorithm suite. The algorithm transition timeline document MUST
also be published, to inform the community of the dates selected for
milestones in the transition process, as described in Section 4.3.
4.1. Milestones definition
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
certificate under the Algorithm B suite.
CA Go Algorithm B Date - After this date, all (non-leaf) CAs MUST
have re-issued all of its signed product set under the
Algorithm B suite.
RP Ready Algorithm B Date - After this date, all RPs MUST be
prepared to process signed material issued under the
Algorithm B suite.
Twilight Algorithm B - After this date, a CA MAY cease issuing
signed products under the Algorithm A suite. Also, after
this date, a RP MAY cease to validate signed materials
issued under the Algorithm A suite.
End Of Life (EOL) Algorithm A - After this date every CA MUST NOT
generate certificates, CRLs, or other RPKI signed objects
under the Algorithm A suite. Also, after this date, no
RP SHOULD accept as valid any certificate, CRL or signed
object using the Algorithm A suite.
4.2. Process overview
The migration process described in this document involves a series of
steps that MUST be executed in chronological order by CAs and RPs.
The only milestone at which both CAs and RPs take action at the same
time is the "EOL Algorithm A" date. Due to the decentralized nature
of the RPKI infrastructure, it is expected that an algorithm
transition will span several years.
In order to facilitate the transition, CAs will start issuing
certificates using the Algorithm B in a hierarchical top-down
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
Gagliano, et al. Expires June 1, 2012 [Page 8]
Internet-Draft RPKI Algorithm Agility November 2011
Algorithm B Date > CA X Ready Algorithm B Date). This ordered
transition avoids issuance of "mixed" suite certificates, e.g., a CA
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
that corresponds to an algorithm suite that differs from the one used
to sign the certificate.(X.509 accommodates such mixed algorithm
certificates, but this process avoids using that capability. A not
top-down transition approach would require use of such mixed mode
certificates, but this would lead to exponential growth of the RPKI
repository. Also, because the RPKI CP mandates "proof of possession"
for certificate requests, it is not possible for a CA to request a
certificate for Algorithm Suite B, until its parent CA supports that
Suite. See Section 5 for more details.)
The algorithm agility model described here does not prohibit a CA
from issuing an EE certificate with a subject public key from a
different algorithm suite, if that certificate is not used to verify
repository objects. This exception to the mixed algorithm suite
certificate rule is allowed because an EE certificate that is not
used to verify repository objects does not interfere with the ability
of RPs to download and verify repository content. As noted above,
every CA in the RPKI is required to perform a Proof of Possession
(PoP) check for the subject public key when issuing a certificate.
In general a subject cannot assume that a CA is capable of supporting
a different algorithm. However, if the subject is closely affiliated
with the CA, it is reasonable to assume that there are ways for the
subject to know whether the CA can support a request to issue an EE
certificate containing a specific, different public key algorithm.
This document does not specify how a subject can determine whether a
CA is capable of issuing a mixed suite EE certificate, because it
anticipates that such certificates will be issued only in contexts
where the subject and CA are sufficiently closely affiliated (for
example, an ISP issuing certificates to devices that it manages).
The following figure gives an overview of the process:
Gagliano, et al. Expires June 1, 2012 [Page 9]
Internet-Draft RPKI Algorithm Agility November 2011
Process for RPKI CAs:
Phase 0 Phase 1 Phase 2 Phase 4 Phase 0
-----------x---------x-------------------x--------x-----------
^ ^ ^ ^ ^
| | | | |
(1) (2) (3) (5) (6)
Process for RPKI RPs:
Phase 0 Phase 3 Phase 4 Phase 0
-------------------------------x---------x--------x-----
^ ^ ^ ^
| | | |
(1) (4) (5) (6)
(1) RPKI algorithm document is updated and the algorithm transition timeline document is issued
(2) CA Ready Algorithm B Date
(3) CA Go Algorithm B Date
(4) RP Ready Algorithm B Date
(5) Twilight Date
(6) End Of Live (EOL) Date
Each of these milestones is discussed in the next section as part of
describing each phase of the transition process.
Two situations have been identified that motivate pausing or rolling
back the transition process. The first situation arises if the RPKI
community is not ready to make the transition. For example, many CAs
might not prepared to issue signed products under Suite B, or many
RPs might be ready to process Suite B product sets. Under these
circumstances, the timetable MUST be reissued, postponing the date
for the phase in question, and pushing back the dates for later
phases. The other situation arises if, during the transition,
serious concerns arise about the security of the Suite B algorithms.
Such concerns would motivate terminating the transition and rolling
back signed products, i.e., reverting to Suite A. In this case the
timetable MUST be republished, and the RPKI algorithm document MUST
be superseded. The phase descriptions below allude to these two
situations, as appropriate.
4.3. Phase 0
Phase 0 is the initial phase of the process, throughout this phase
the algorithm suite A is the only supported algorithm suite in RPKI.
This is also the steady state for the RPKI.
The following figure illustrates the format used to describe signed
Gagliano, et al. Expires June 1, 2012 [Page 10]
Internet-Draft RPKI Algorithm Agility November 2011
objects in the repository. It reflects the algorithm suites in use,
and shows the relationship between three CAs (X, Y, and Z) that form
a chain.
During Phase 0, CAs X, Y and Z are required to generate signed
product sets using only the Algorithm Suite A. Also, RPs are required
to validate signed product sets issued using only Algorithm Suite A.
CA X-Certificate-Algorithm-Suite-A (Cert-XA)
|
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
Note: Cert-XA represent the certificate for CA X, that is signed
using the algorithm suite A.
4.3.1. Milestone 1
The first milestone initiates the migration process. It updates the
[I-D.ietf-sidr-rpki-algs] document with the following definitions for
the RPKI:
o Algorithm Suite A
o Algorithm Suite B
Additionally, the new algorithm transition timeline document will be
published with the following information:
o CA Ready Algorithm B Date
o CA Go Algorithm B Date
o RP Ready Algorithm B Date
o Twilight Date
o EOL Date
o Readiness metrics for CAs and RPs in each phase
All Dates MUST be represented using the local UTC date-time format
Gagliano, et al. Expires June 1, 2012 [Page 11]
Internet-Draft RPKI Algorithm Agility November 2011
specified in [RFC3339].
4.4. Phase 1
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
issue or revoke a certificate using the Algorithm B suite. If it is
determined that a substantial number of CAs are not ready, the
algorithm transition timeline document will be reissued, as noted in
Section 4.2. However, CAs that are capable of issuing Suite B
certificates may continue to do so, if requested by their child CAs.
Since this phase does not require any RPs to process signed objects
under Suite B, and since Suite B product SHOULD be stored at
independent publication points, there is no adverse impact on RPs.
If the Suite B algorithm is deemed unsuitable, the algorithm
transition timeline and the algorithm specification documents MUST be
replaced. CAs MUST cease accepting requests for certificates under
Suite B, and Suite B certificates that have been issued MUST be
revoked.
As the transition will happen using a (hierarchic) top-down model, a
child CA will be able to issue certificates using the Algorithm B
suite only after its parent CA has issued its own. The RPKI
provisioning protocol can identify if a parent CA is capable of
issuing certificates using the Algorithm Suite B, and can identify
the corresponding algorithm suite in each Certificate Signing Request
(see Section 5).
The following figure shows the status of repository entries for the
three example CAs during this Phase. Two distinct certificate chains
are maintained and CA Z has not yet requested any material using the
Algorithm B suite.
Gagliano, et al. Expires June 1, 2012 [Page 12]
Internet-Draft RPKI Algorithm Agility November 2011
CA X-Certificate-Algorithm-Suite-A (Cert-XA)
|
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA X-Certificate-Algorithm-Suite-B (Cert-XB)
|
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
4.5. Phase 2
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
Algorithm Suite A and Algorithm Suite B. 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,
the algorithm transition timeline document will be reissued, as noted
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
pushing back the Phase 2 milestone, but it does motivate delaying the
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
require any RPs to process signed objects under Suite B. Also, Suite
B product SHOULD be stored at independent publication points, so
there is no adverse impact on RPs. If the Suite B algorithm is
deemed unsuitable, the algorithm transition timeline and the
algorithm specification documents MUST be replaced. CAs MUST cease
accepting requests for certificates under Suite B, and Suite B
certificates that have been issued MUST be revoked.
An RP that validates all signed product sets using both Algorithm
Suite A or Algorithm Suite B, SHOULD expect the same results.
However, an object that validates using either Algorithm Suite A or
Algorithm Suite B MUST be considered valid. A detailed analysis on
the validation of multiple instance of signed objects is included in
Section 6.
Gagliano, et al. Expires June 1, 2012 [Page 13]
Internet-Draft RPKI Algorithm Agility November 2011
The following figure shows the status of the repository entries for
the three example CAs throughout this phase, where all signed objects
are available using both algorithm suites.
CA X-Certificate-Algorithm-Suite-A (Cert-XA)
|
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA X-Certificate-Algorithm-Suite-B (Cert-XB)
|
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
|-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
4.6. Phase 3
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 RPs MUST be able to validate them using either suite. An object
that validates using either Algorithm Suite A or Algorithm Suite B
MUST be considered valid. It is RECOMMENDED that, in preparation for
Phase 4, RPs utilize Suite B as the first and preferred option for
validation throughout this phase. Thus, for example, an RP SHOULD
try to validate the sets of signed products retrieved from the
Algorithm Suite B repository first. If this effort fails (relative
to the local validation policy), the RP SHOULD revert to using the
Algorithm Suite A repository.
If a substantial number of RPs are unable to process product sets
signed with Suite B, the algorithm transition timeline document MUST
be reissued, pushing back the date for this and later milestones, as
discussed in Section 4.2. Since the Suite B products SHOULD be
published at distinct publication points, RPs that cannot process
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
algorithm transition timeline and the algorithm specification
Gagliano, et al. Expires June 1, 2012 [Page 14]
Internet-Draft RPKI Algorithm Agility November 2011
documents MUST be replaced. CAs MUST cease accepting requests for
certificates under Suite B, and Suite B certificates that have been
issued MUST be revoked.
There are no changes to the CA behavior throughout this phase.
4.7. Phase 4
Phase 4 starts at the Algorithm A Twilight Date. At that date, the
Algorithm A is labeled as "old" and the Algorithm B is labeled as
"current":
Before Twilight --> After Twilight
Algorithm Suite A ("current") --> Algorithm Suite C ("old")
Algorithm Suite B ("new") --> Algorithm Suite A ("current")
During this phase, all signed product sets MUST be issued using
Algorithm Suite A (formerly B) and MAY be issued using Algorithm
Suite C (formerly A). All signed products sets issued using Suite A
MUST be published at their corresponding publication points, but
signed products sets issued using Suite C MAY be published at their
corresponding publication points. Also, every RP MUST
validate signed product sets using Suite A but also MAY validate
signed product sets using Suite C. However, RPs SHOULD NOT assume the
Suite C repository is complete.
If it is determined that many RPs are not capable of processing the
new algorithm suite, the algorithm transition timeline document MUST
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)
product sets if this phase is delayed. If the Suite B algorithm is
deemed unsuitable, the algorithm transition timeline and the
algorithm specification documents MUST be replaced. CAs MUST cease
accepting requests for certificates under Suite B, and Suite B
certificates that have been issued MUST be revoked. At this stage,
RPs are still capable of processing old Suite A signed products.
The following figure describes a possible status for the repositories
of the example CAs. In this case, CA Z no longer issues signed
products using the Algorithm Suite C.
Gagliano, et al. Expires June 1, 2012 [Page 15]
Internet-Draft RPKI Algorithm Agility November 2011
CA X-Certificate-Algorithm-Suite-C (Cert-XC)
|
|-> CA-Y-Certificate-Algorithm-Suite-C (Cert-YC)
|-> CA-Y-CRL-Algorithm-Suite-C (CRL-YC)
|-> CA-Y-Signed-Objects-Algorithm-Suite-C
|-> CA-X-CRL-Algorithm-Suite-C (CRL-XC)
|-> CA-X-Signed-Objects-Algorithm-Suite-C
CA X-Certificate-Algorithm-Suite-A (Cert-XA)
|
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
4.8. Return to Phase 0
The EOL Algorithm Date triggers a return to Phase 0 (steady state).
At this phase, ALL signed product sets using Algorithm Suite C MUST
be considered invalid. CAs MUST neither issue nor publish signed
products using Algorithm Suite C.
This phase closes the loop as Algorithm Suite A is the only required
algorithm suite in RPKI.
If it is determined that many RPs are not capable of processing the
new algorithm suite, the algorithm transition timeline document MUST
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.
Gagliano, et al. Expires June 1, 2012 [Page 16]
Internet-Draft RPKI Algorithm Agility November 2011
5. Multi Algorithm support in the RPKI provisioning protocol
The migration described in this document is a top-down process, where
two synchronization issues need to be solved between child and parent
CAs:
o A child CA needs to identify which algorithm suites are supported
by its parent CA
o A child CA needs to identify which algorithm suite should be used
to sign a Certificate Signing Request (CSR)
The RPKI provisioning protocol [I-D.ietf-sidr-rescerts-provisioning]
supports multiple algorithms suites by implementing different
resource classes for each suite. Several different resource classes
also may use the same algorithm suite for different resource sets.
A child CA that wants to identify which algorithm suites are
supported by its parent CA MUST perform the following tasks:
1. Establish a provisioning protocol session with its parent CA
2. Perform a "list" command as described in Section 3.3.1 of
[I-D.ietf-sidr-rescerts-provisioning]
3. From the Payload in the "list response" resource class, extract
the "issuer's certificate" for each class. The Algorithm Suite
for each class will match the Algorithm Suite used to issue the
corresponding "issuer's certificate".
A child CA that wants to specify an Algorithm Suite to its parent CA
(e.g., in a certificate request) MUST perform the following tasks:
1. Perform the tasks to identify the resource class for each
Algorithm Suite supported by its parent CA (as above).
2. Identify the corresponding resource class in the appropriate
provisioning protocol command (e.g. "issue" or "revoke")
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
issuing a certificate using an algorithm suite that does not match a
resource class, the PoP validation will fail and the request will not
be performed.
Gagliano, et al. Expires June 1, 2012 [Page 17]
Internet-Draft RPKI Algorithm Agility November 2011
6. Validation of multiple instance of signed products
During Phases 1,2,3 and 4, two algorithm suites will be valid
simultaneously in RPKI. In this section, we describe the RP behavior
when validating instances of the same signed product but signed with
different algorithm suites. As a general rule, the validation of
signed products using different algorithm suites are independent and
the RP MUST NOT keep any relationship between the different
hierarchies.
During Phase 1 two (corresponding) files for an object MAY be
available for each signed product, one signed under Algorithm Suite A
and one under Algorithm Suite B. When an RP validates these signed
products, if either instance of an object validates, the product is
accepted. A failure to validate one instance of a product, under
either algorithm Suite MUST NOT cause the RP to reject the other
instance of the product. Because both instances of such products
MUST contain the same resources, relying on either instance will
yield the same outcome.
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
an RP validates these signed products, if either instance validates,
the product is accepted. A failure to validate one instance of a
product, under either algorithm Suite MUST NOT cause the RP to reject
the other instance of the product. Also, as above, if only one
instance of a signed product can be validated, subordinate products
issued under the other (non-validated) algorithm suite cannot be
used, and thus SHOULD NOT be processed (or even retrieved).
During Phase 4 two (corresponding) files for an object MAY be
available for each signed product, one signed under Algorithm Suite A
and one under Algorithm Suite C. When an RP validates these signed
products, if either instance of an object validates, the product is
accepted. A failure to validate one instance of a product, under
either algorithm Suite MUST NOT cause the RP to reject the other
instance of the product. Because both instances of such products
MUST contain the same resources, relying on either instance will
yield the same outcome.
Gagliano, et al. Expires June 1, 2012 [Page 18]
Internet-Draft RPKI Algorithm Agility November 2011
7. Revocations
As the algorithm migration process mandates the maintenance of two
parallel certificate hierarchies, revocations requests for each
algorithm suite MUST be handled independently. A Child CA MUST
request revocation of a certificate relative to a specific algorithm
suite.
During phase 2 and phase 3, the two parallel certificate hierarchies
are designed to carry identical information. Consequently, a child
CA requesting the revocation of a certificate during these two phases
MUST perform that request for both algorithm suites (A and B). A
non-leaf CA is NOT required to verify that its child CAs comply with
this requirement.
Gagliano, et al. Expires June 1, 2012 [Page 19]
Internet-Draft RPKI Algorithm Agility November 2011
8. Key rollover
Key rollover (without algorithm changes) is effected independently
for each algorithm suite and MUST follow the process described in
[I-D.ietf-sidr-keyroll].
Gagliano, et al. Expires June 1, 2012 [Page 20]
Internet-Draft RPKI Algorithm Agility November 2011
9. Repository structure
The two parallel hierarchies that will exist during the transition
process SHOULD have independent publications points. The repository
structures for each algorithm suite are described in
[I-D.ietf-sidr-repos-struct].
Gagliano, et al. Expires June 1, 2012 [Page 21]
Internet-Draft RPKI Algorithm Agility November 2011
10. IANA Considerations
No IANA requirements
Gagliano, et al. Expires June 1, 2012 [Page 22]
Internet-Draft RPKI Algorithm Agility November 2011
11. Security Considerations
An algorithm transition in RPKI should be a very infrequent event and
it requires wide community consensus. The events that may lead to an
algorithm transition may be related to a weakness of the
cryptographic strength of the algorithm suite in use by RPKI, which
is normal to happen over time. The procedure described in this
document will take years to complete an algorithm transition. During
that time, the RPKI system will be vulnerable to any cryptographic
weakness that may have triggered this procedure (i.e. downgrade
attack).
This document does not describe an emergency mechanism for algorithm
migration. Due to the distributed nature of RPKI, and the very large
number of CAs and RPs, the authors do not believe it is feasible to
effect an emergency algorithm migration procedure.
If a CA does not complete its migration to the new algorithm suite as
described in this document (after the EOL of the "old" algorithm
suite), its signed product set will no longer be valid.
Consequently, the RPKI may, at the end of Phase 4, have a smaller
number of valid signed products than before starting the process.
Conversely, a RP that does not follow this process will lose the
ability to validate signed products issued under the new algorithm
suite. The resulting incomplete view of routing info from the RPKI
(as a result of a failure by CAs or RPs to complete the transition)
could degrade routing in the public Internet.
Gagliano, et al. Expires June 1, 2012 [Page 23]
Internet-Draft RPKI Algorithm Agility November 2011
12. Acknowledgements
The authors would like to acknowledge the work of the SIDR working
group co-chairs (Sandra Murphy and Chris Morrow) as well as the
contributions given by Geoff Huston, Arturo Servin, Brian Weis, Terry
Manderson, Brian Dickson and Danny McPherson.
Gagliano, et al. Expires June 1, 2012 [Page 24]
Internet-Draft RPKI Algorithm Agility November 2011
13. References
13.1. Normative References
[I-D.ietf-sidr-cp]
Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource PKI (RPKI",
draft-ietf-sidr-cp-17 (work in progress), April 2011.
[I-D.ietf-sidr-keyroll]
Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
in the RPKI", draft-ietf-sidr-keyroll-05 (work in
progress), December 2010.
[I-D.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure",
draft-ietf-sidr-repos-struct-06 (work in progress),
November 2010.
[I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-21 (work in progress),
December 2010.
[I-D.ietf-sidr-rescerts-provisioning]
Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
Protocol for Provisioning Resource Certificates",
draft-ietf-sidr-rescerts-provisioning-10 (work in
progress), June 2011.
[I-D.ietf-sidr-rpki-algs]
Huston, G., "A Profile for Algorithms and Key Sizes for
use in the Resource Public Key Infrastructure",
draft-ietf-sidr-rpki-algs-04 (work in progress),
November 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
Gagliano, et al. Expires June 1, 2012 [Page 25]
Internet-Draft RPKI Algorithm Agility November 2011
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
13.2. Informative References
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
Gagliano, et al. Expires June 1, 2012 [Page 26]
Internet-Draft RPKI Algorithm Agility November 2011
Appendix A. Change Log
From 03 to 04:
1. Added text for "roll-over" capability in each phase
2. Added the requirement for splitting the milestone 1 in two
documents: the update of the alg document and a new document
specifying the particular timelines
3. WGLC nits
From 02 to 03:
1. Explicitely named than "mixed" certificates are not allowed for
CA certs but may be possible for EE certs that are not used to
validate repository objects.
From 01 to 02:
1. Add reference to Multi-Objects validation
2. EOL Data is the only milestone that RP and CA take actions "at
the same time".
3. Updated references
4. Editorial
From 00 to 01:
1. Include text to clarify former Suites
2. Include text that documents that an RP that validates an object
signed with either suites in Phase 2 MUST consider it as valid
From individual submission to WG item:
1. Change form "laisez faire" to "top-down"
2. Included Multi Algorithm support in the RPKI provisioning
protocol
3. Included Validation of multiple instance of signed products
4. Included Revocations
Gagliano, et al. Expires June 1, 2012 [Page 27]
Internet-Draft RPKI Algorithm Agility November 2011
5. Included Key rollover
6. Included Repository structure
7. Included Security Considerations
8. Included Acknowledgements
Gagliano, et al. Expires June 1, 2012 [Page 28]
Internet-Draft RPKI Algorithm Agility November 2011
Authors' Addresses
Roque Gagliano
Cisco Systems
Avenue des Uttins 5
Rolle, 1180
Switzerland
Email: rogaglia@cisco.com
Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Email: kent@bbn.com
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
Email: turners@ieca.com
Gagliano, et al. Expires June 1, 2012 [Page 29]
