Network Working Group R. Gagliano
Internet-Draft Cisco Systems
Intended status: Standards Track S. Kent
Expires: April 21, 2011 BBN Technologies
S. Turner
IECA, Inc.
October 18, 2010
Algorithm Agility Procedure for RPKI.
draft-rgaglian-sidr-algorithm-agility-00
Abstract
This document specifies the process that Certificate 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.
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 April 21, 2011.
Copyright Notice
Copyright (c) 2010 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
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Gagliano, et al. Expires April 21, 2011 [Page 1]
Internet-Draft RPKI_Alg_Agility October 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Phase 5 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.9. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Synchronization issues during the algorithm transition . . . . 15
5.1. Signed Objects Information . . . . . . . . . . . . . . . . 15
5.2. Revocations . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Key rollover . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Repository structure . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Gagliano, et al. Expires April 21, 2011 [Page 2]
Internet-Draft RPKI_Alg_Agility October 2010
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 April 21, 2011 [Page 3]
Internet-Draft RPKI_Alg_Agility October 2010
2. Introduction
The RPKI must accommodate transitions between the public keys by 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. (One might adopt
a new hash algorithm while retaining the current signature algorithm.
In such circumstances this document treats the change as equivalent
to a key rollover, and requires the CA to change its key as well).
Such transitions will be required in order to maintain an acceptable
level of cryptographic security, to 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.
A failure to comply with this process during an algorithm transition
MUST be considered as non-compliance with the RPKI Certificate Policy
Gagliano, et al. Expires April 21, 2011 [Page 4]
Internet-Draft RPKI_Alg_Agility October 2010
(CP).
Gagliano, et al. Expires April 21, 2011 [Page 5]
Internet-Draft RPKI_Alg_Agility October 2010
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
din examples are provided below.
Algorithm migration A planned transition from one signature and hash
algorithm to a new signature and hash algorithm.
Algorithm Siute A The "current" algorithm suite used for hashing and
signing, in examples in this document
Algorithm Siute B The "next" algorithm suite used for hashing and
signing, used in examples in this document
Algorithm Siute 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 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 reissuance (unilateral) Certificate reissuance
(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 (see Section X.X) 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 reissuance.
Key rollover (planned) - reissuance of CA's certificate with a new
key, at a pre-determined time.
Gagliano, et al. Expires April 21, 2011 [Page 6]
Internet-Draft RPKI_Alg_Agility October 2010
Key rollover (emergency) - reissuance of CA's certificate with a new
key, e.g., as a result of a suspected compromise or loss
of access to a private key. An emergency key rollover is
not a planed event (from the perspective of the CA).
Non-Leaf CA - a CA that issues certificates to entities not under its
administrative control.
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 April 21, 2011 [Page 7]
Internet-Draft RPKI_Alg_Agility October 2010
4. Key Rollover steps for algorithm migration
The "current" RPKI algorithm suite (Suite A) definition is defined in
the RPKI's CP document , by reference to [I-D.ietf-sidr-rpki-algs].
If 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 that will
include all the information described in section 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 containing an Algorithm B key for signature,
even if signing the certificate using the Algorithm A
suite.
CA Set Algorithm B Date - After this date, all CAs MUST be able to
issue a certificate signed under the Algorithm B suite to
a child CA that requests such. At this stage there is no
requirement that any CA issue such certificates, but
rather that all (non-eaf) CAs be prepared to do so upon
request.
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 old algorithm 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 validate 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 that affects both CAs and RPs, at the same moment
is the EOL date. Due to the decentralized nature of the RPKI
Gagliano, et al. Expires April 21, 2011 [Page 8]
Internet-Draft RPKI_Alg_Agility October 2010
infrastructure, it is expected that the process will take several
months or even years. It also is expected that different CAs and RPs
will achieve the various milestones at different moments without
central synchronization. The following figure gives an overview of
the process:
Process for RPKI CAs:
Phase 0 Phase 1 Phase 2 Phase 3 Phase 5 Phase 0
-----------x--------x--------x-------------------x--------x-------
^ ^ ^ ^ ^ ^
| | | | | |
(1) (2) (3) (4) (6) (7)
Process for RPKI RPs:
Phase 0 Phase 4 Phase 5 Phase 0
----------------------------------------x--------x--------x--------
^ ^ ^ ^
| | | |
(1) (5) (6) (7)
(1) RPKI's algorithm document updated.
(2) CA Ready Algorithm B Date
(3) CA Set Algorithm B Date
(4) CA Go Algorithm B Date
(5) RP Ready Algorithm B Date
(6) Twilight Date
(7) End Of Live (EOL) Date
4.3. Phase 0
Phase 0 is the initial phase of the process, during which the
Algorithm suite A is the only required algorithm suite in RPKI.
The first milestone here (1), is updating the [alg] document with the
following definitions:
o Algorithm Suite A
o Algortihm Suite B
o CA Ready Algorithm B Date
o CA Set Algorithm B Date
o CA Go Algorithm B Date
Gagliano, et al. Expires April 21, 2011 [Page 9]
Internet-Draft RPKI_Alg_Agility October 2010
o RP Ready Algorithm B Date
o Twilight Date
o EOL Date
All Dates MUST be represented using the local UTC date-time format
specified in [RFC 3339].
As an example, 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-XAA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YAA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZAA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Other-Signed-Objects-Algorithm-Suite-A
Note: Cert-XAA represent the certificate for CA X, that includes an
algorithm suite A key in its Subject Public Key Info field (first A)
and is signed using the algorithm suite A (second A).
4.4. Phase 1
Phase 1 starts at the CA Ready Algorithm B Date. During the Phase 1,
ALL (non-leaf) CAs MUST be ready to process a request from a child CA
to issue a certificate containing an Algorithm B key for signature.
In order to perform this task, the issued CA MUST be able to
demonstrate the subject's PoP by verifying the certificate request's
signature, which MAY be calculated using the signature algorithm B.
During this phase, the issuing CA is NOT required to sign the
certificates it issues using the Algorithm suite B. Consequently, it
is possible to issue certificates signed using the Algorithm suite A,
but that have a "Subject Public Key Info" field that correspond to
the Algorithm suite B. Also, the issuing CA MAY receive requests with
the same Subject field but different Subject Public Key Info fields
(for either the Algorithm A or B suite).
During the complete transition process, all CA MUST NOT sign a CSR
that includes an Algorithm Suite A "Subject Public Key Info" using
the Algorithm Suite B.
(Note 1: Now we may have an issue with the decision from the WG of
not using the "top-down" model. If I am a subordinate CA and my
Gagliano, et al. Expires April 21, 2011 [Page 10]
Internet-Draft RPKI_Alg_Agility October 2010
parent has the possibility of issuing certificates with both, the A
and B algorithm suite, how does a request indicate the algorithm
suite that should be used? We may need to modify the provisioning
protocol to indicate which algorithm suite to use. In the following
sections, I assume that the subordinate CA has the ability to chose
which Algorithm Suite it will use).
(Note 2: Also in the provisioning protocol, it looks that it would be
great to have the possibility to question the server on what
algorithm suite it supports in order to not depend in any off-band
communication).
A RP is not required to modify its behavior during the Phase 1.
However, a RP MAY validate the signed objects signed using the
Algorithm suite B. A RP that choses to do so MUST consider as equally
valid any validated signed object signed with Algorithm suite A or B.
The objective of this phase is to allow a subordinate CA to start its
transition to the Algorithm Suite B, although its parent CA is not
ready to issue certificates using the new suite. In our example if
CA Y would like to start the transition, it should send a certificate
request that includes an Algorithm Suite B key in its "Subject Public
Key Info". CA X will be able to verify the signature of the
certificate request and issue the certificate that, in this case, is
signed using Algorithm Suite A. CA Y then will be able to issue a
certificate signed by Algorithm Suite B to CA Z, and to generate any
signed object using the new algorithm suite. CA Y will have two
certificates with the same resources, both signed with the same key
from CA X. CA Z may have three certificates, depending on which
validation paths CA Z would like to enable. The typical
certification hierarchy is shown in this figure:
CA X-Certificate-Algorithm-Suite-A (Cert-XAA)
|
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YAA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZAA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Y-Other-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YBA)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Other-Signed-Objects-Algorithm-Suite-B
In the example of the figure, an RP that can validate signed product
Gagliano, et al. Expires April 21, 2011 [Page 11]
Internet-Draft RPKI_Alg_Agility October 2010
sets using either algorithm suites, and that is configure with
Certificate Cert-XAA as its Trust Anchor (TA) would be able to
validate the CA Y signed product sets signed using Algorithm Suite B,
by using the following validation path: Cert-XAA --> Cert-YBA.
The RP also will be able to validate CA Z signed product sets signed
using Algorithm Suite B, by using either of the following validation
paths:
Cert-XAA --> Cert-YAA --> Cert-ZBA-> CA-Z-Signed-Objects-Algorithm-
Suite-B
or
Cert-XAA --> Cert-YBA --> Cert-ZBB-> CA-Z-Signed-Objects-Algorithm-
Suite-B
If any CA in the example were in the process of a key rollover (using
the same algorithm suite), more validation paths would be possible.
4.5. Phase 2
Phase 2 starts at the CA Set Algorithm B Date. During this phase,
ALL CAs MUST be able to issue a certificate signed under the
Algorithm B suite to a child CA that requests such. Also, every CA
MUST issue its CRLs using both Algorithm suites (A and B).
At this phase a subordinate CA has the ability to choose which
Algorithm suite should be used by the issuing CA to generate the
requested certificate. (Note: here we should add a reference to the
mechanism that should be part of the provisioning protocol).
Every CA MUST issue a CRL for each CA Certificate associated with the
CA. Each CRL should be signed with the correspondent algorithm
suite.
The same comment for RP behaviour during Phase 1 is valid during
Phase 2.
In our three CA example, CA A will be able to issue certificates
using Algorithm Suite B:
Gagliano, et al. Expires April 21, 2011 [Page 12]
Internet-Draft RPKI_Alg_Agility October 2010
CA X-Certificate-Algorithm-Suite-A (Cert-XAA)
|
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YAA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZAA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Y-Other-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YBA)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Other-Signed-Objects-Algorithm-Suite-B
CA X-Certificate-Algorithm-Suite-B (Cert-XBB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YBB)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZBB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Other-Signed-Objects-Algorithm-Suite-B
In this example, the certificate requests for Cert-YBB and Cert-YBA
are the same, the only difference is that, in one case, the
certificate is issued signed using Algorithm-Suite A (Cert-YBA) and
in the other case using Algorithm-Suite B (Cert-YBB). This
architecture simplifies the operation of the CA-Y and the structure
of the repository system.
A RP that can validate signed product sets using Algorithm Suite B,
could use Cert-XBB as trust anchor and validate all CA Y and CA Z
signed product sets using only the new suite. At this stage not all
CAs are required to issue signed product sets using Algorithm Suite B
and it is not expected that an RP uses only Algorithm Suite B trust
anchors.
4.6. Phase 3
Phase 3 starts at the CA Go Algorithm B Date. During this phase all
signed product sets are available either using Algorithm Suite A or
Algorithm Suite B. At this phase, RPs are not yet required to
validate the sets issued using Algorithm Suite B.
At this phase, RPs are still required to be able to validate signed
product sets using only the Algorithm Suite A.
An RP that validates all signed product sets using exclusively either
Algorithm Suite A or Algorithm Suite B, should expect the same
Gagliano, et al. Expires April 21, 2011 [Page 13]
Internet-Draft RPKI_Alg_Agility October 2010
results.
4.7. Phase 4
Phase 4 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.
4.8. Phase 5
Phase 5 starts at the Algorithm B Twilight Date. At that date, the
Algorithm A is labeled as "old" and the Algorithm B is labeled as
"current":
A->C
B->A
During this phase, all signed product sets MUST use using the current
Algorithm Suite A and MAY be used using the old Algorithm Suite C.
Also, every RP MUST validate signed product sets using the current
Algorithm Suite A, but also MAY validate signed product sets using
the old Algorithm Suite C.
4.9. Phase 0
Phase 0 starts at the EOL Algorithm Date. At this phase, ALL signed
product sets under using Algorithm Suite C MUST be considered
invalid.
This phase closes the loop as Algorithm suite A is the only required
algorithm suite in RPKI.
Gagliano, et al. Expires April 21, 2011 [Page 14]
Internet-Draft RPKI_Alg_Agility October 2010
5. Synchronization issues during the algorithm transition
TBC
5.1. Signed Objects Information
TBC
5.2. Revocations
TBC
5.3. Key rollover
TBC
5.4. Repository structure
TBC
Gagliano, et al. Expires April 21, 2011 [Page 15]
Internet-Draft RPKI_Alg_Agility October 2010
6. IANA Considerations
No IANA requirements
Gagliano, et al. Expires April 21, 2011 [Page 16]
Internet-Draft RPKI_Alg_Agility October 2010
7. Security Considerations
TBC
Gagliano, et al. Expires April 21, 2011 [Page 17]
Internet-Draft RPKI_Alg_Agility October 2010
8. Acknowledgements
Gagliano, et al. Expires April 21, 2011 [Page 18]
Internet-Draft RPKI_Alg_Agility October 2010
9. References
9.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-14 (work in progress), October 2010.
[I-D.ietf-sidr-keyroll]
Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
in the RPKI", draft-ietf-sidr-keyroll-01 (work in
progress), September 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-05 (work in progress),
October 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-19 (work in progress),
October 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-07 (work in
progress), October 2010.
[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-03 (work in progress),
October 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.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
Gagliano, et al. Expires April 21, 2011 [Page 19]
Internet-Draft RPKI_Alg_Agility October 2010
[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.
9.2. Informative References
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
Gagliano, et al. Expires April 21, 2011 [Page 20]
Internet-Draft RPKI_Alg_Agility October 2010
Appendix A. Change Log
Gagliano, et al. Expires April 21, 2011 [Page 21]
Internet-Draft RPKI_Alg_Agility October 2010
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 April 21, 2011 [Page 22]