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]