[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-sidr-algorithm-agility

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/