SIDR                                                           G. Huston
Internet-Draft                                             G. Michaelson
Intended status: BCP                                               APNIC
Expires: April 3, 4, 2011                                           S. Kent
                                                                     BBN
                                                      September 30,
                                                         October 1, 2010

                      CA Key Rollover in the RPKI
                     draft-ietf-sidr-keyroll-00.txt
                     draft-ietf-sidr-keyroll-01.txt

Abstract

   This document describes an algorithm to allow an entity who
   undertakes the role of a Certification Authority in the Resource
   Public Key Infrastructure to perform a rollover of its key pair.
   This document also notes the requirements placed on Relying Parties
   who maintain a local cache of the objects that have been published in
   the distributed Resource Public Key Infrastructure repository
   publication structure.

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 3, 4, 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
   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology and Concepts  . . . . . . . . . . . . . . . . . 3
   2.  CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . . 3
   3.  Relying Party Requirements  . . . . . . . . . . . . . . . . . . 6 7
   4.  Security Considerations  Reissuing Certificates and RPKI Signed Objects  . . . . . . . . 7
     4.1.  CA Certificates . . . . . . . . . . . . . . . . . . . . . . 7
     4.2.  RPKI Signed Objects . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6. 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7. 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1. 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2. 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7 9

1.  Introduction

   This document describes an algorithm to allow an entity undertaking
   the role of by employed by a
   Certification Authority (CA) in the Resource Public Key
   Infrastucture
   Infrastructure (RPKI) [ID.ietf-sidr-arch] to perform a rollover of
   its key pair.

   The intent of this

   This document is to define defines a conservative procedure for such entities to
   follow when performing a key rollover rollover, so that Relying Parties are in
   a position to be able to validate all authentic objects in the RPKI
   using the validation procedure described in [ID.ietf-sidr-res-certs] [ID.ietf-sidr-arch] at
   all times.

1.1.  Terminology and Concepts

   It is assumed 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 the
   profile for RPKI Certificates [ID.ietf-sidr-res-certs] [ID.ietf-sidr-res-certs], and the RPKI
   repository structure [ID.ietf-sidr-repos-struct] .

   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 RFC 2119.

2.  CA Key Rollover Procedure

   A certification Authority (CA) in the RPKI is an entity that issues
   certificates and CRLs.  Over time, there will be many instances of a
   CA.  A CA instance is associated with a single key pair
   ([ID.ietf-sidr-res-certs]).  The implication in the context of key
   rollover is that, strictly speaking, a CA does not perform a key
   rollover per se.  In order to perform the equivalent of a key
   rollover, the entity who undertakes the role of a CA needs to
   instantiate creates a new instance of a CA, itself, with the a new key
   pair, and then
   substitute substitutes this new CA instance into the RPKI
   hierarchy in place of the old
   CA. CA instance.

   There are some several considerations regarding this procedure that should MUST
   be followed by an entity a CA performing a key rollover operation.  The
   critical consideration is that the RPKI has potential application in
   the area of control of routing integrity [ID.ietf-sidr-arch], , and
   key rollover should not cause any transient hiatus where a Relying
   Party (RP) is led to incorrect conclusions regarding the authenticity
   of attestations and authorities made in the context of the RPKI.  A CA
   should not cannot assume
   that Relying Parties all RPs will universally use one form
   of construction of a potential perform path validation and path over any other, discovery in the
   same fashion, and therefore the key rollover procedure should endeavour at all times to MUST preserve
   the integrity of the CRLDP, SIA and AIA pointers in RPKI
   certificates.

   In the procedure described here, the entity CA creates a "new" new CA instance,
   and has the associated new public key published in the form
   af of a "new" new
   CA certificate.  While the "current" current and "new" new CA instances share a
   single repository publication point, each CA has its own CRL, CRL and its
   own manifest.  Initially, the "new" new CA publishes an empty CRL and a
   manifest that contains a single entry for the CRL.  The "current" CA
   also is maintains its published CRL and manifest at this Repository
   publication point.

   The entity should then wait CA performing key rollover waits for a period of time to allow Relying
   Parties afford
   every RP an opportunity to discover and retrieve this "new" new CA certificate
   certificate, and store it in their its local RPKI Repository cache instances (this
   instance.  This period of time is termed the "staging period"). period".
   During this period, the entity CA will have a "new" new CA instance, with no
   subordinate products, and an
   "current" a current CA instance which that has issued all
   subordinate products.  At the expiration of the staging period the "new"
   new CA instance can re-
   issue MUST replace all (valid) subordinate products of the previous
   current CA instance, overwriting the old current subordinate products in
   the CA's repository publication point.  When this process is complete
   the "current" current CA instance
   can be is retired, and the "new" new CA instance can be re-termed becomes
   the
   "current" current CA.

   During the transition of the current and new CA instances it is
   necessary for the
   "new" new CA instance to re-issue all subordinate
   products of the
   "current" current CA.  The procedure described here specifies requires
   that, with the exception of manifests and CRLs, the re-issued
   subordinate products be published using the same repository
   publication point object names, effectively overwriting the old subordinate
   objects with these re-issued subordinate objects.  The intent of this overwriting
   operation is to ensure that the AIA pointers of indirect subordinate products
   at lower levels tiers in the PKI RPKI hierarchy remain correct, and that CA key
   rollover does not require any associated actions by any subordinate
   CA.

   There are four three CA states described here:

   CURRENT:
      The CURRENT CA is the active CA instance used to accept and
      process certificate issuance and revocation requests from subordinate entities.

   NEW: The CA starting
      point for this algorithm is in that the process key of the CURRENT CA is to
      be rolled over.

   NEW:
      The NEW CA is the CA instance that is being created.  The NEW CA
      is unable to not active, and thus does not accept nor process certificate
      issuance and revocation requests from
      subordinate entities. requests.  The NEW CA may SHOULD issue a CRL
      and an EE certificate in association with its Manifest, but has no other
      subordinate products.

   PENDING:
      The CA is in the process of being set up.  The CA is able to able
      to issue certificates that were previously issued with the old
      key, but is not able manifest to process new certificate issuance and
      revocation requests from subordinate entities. provide
      a trivial, complete, consistent instance of a CA.

   OLD:
      The CA instance is in the process of being removed.  The  An OLD CA
      instance is able to unable to process any certificate issuance and
      revocation requests
      from subordinate entities.  The requests.  An OLD CA instance will continue to issue
      regularly scheduled CRLs and be permitted to issue an EE certificate as part of
      the process of updating its manifest to reflect the updated CRL.

   To perform a key rollover operation the entity CA MUST perform the following
   steps in the order given here.  Unless specified otherwise each step
   SHOULD be performed without any intervening delay.  The process MUST
   be run through to completion.

      1.  Generate a new key pair for use by the NEW CA.  Because the
          goal of this algorithm is key pair. rollover, the key pair generated
          in this step MUST be different from the pair in use by the
          CURRENT CA.

      2.  Generate a certificate request with the NEW this key pair and pass the
          request to the entity's immediate superior CA as that issued the CURRENT CA
           certificate Issuer.

      3.   Request certificate.
          This request MUST include the same SIA extension that is
          present in the CURRENT CA certificate.  This request, when
          satisfied, will result in the publication of the entity's Issuer to generate and publish a NEW CA
           certificate, with
          certificate.  This (NEW) CA certificate will contain an issuer-selected
          Subject Name that is selected by the issuer, which MUST be distinct
          from the Subject Name used in the CURRENT CA
           certificate for this entity.

      4.   Wait certificate.  The
          CPS for a "Staging Period" following the completion issuer of the NEW CA certificate request.  This "Staging Period is selected
           by will indicate the entity, and MUST
          time frame within which a certificate request is expected to
          be no less than 24 hours.

      5.   Upon expiration of processed.

      3.  Publish the Staging Period, suspend NEW CA's CRL and manifest.

             The steps involved here are:

             -  Wait for the processing issuer of subordinate certificate issuance requests and revocation
           requests.  Mark the CURRENT NEW CA as OLD and to publish the NEW CA
                certificate.

             -  As quickly as
           PENDING.  Halt possible following the operation publication of the OLD
                NEW CA for all operations
           except certificate, use the further issuance of subsequent CRLs and EE
           certificates for Manifests.

      6.   Use key pair associated with the PENDING
                NEW CA to generate new certificates for all
           existing subordinate CA and EE certificates, an initial, empty CRL, and publish
           those products
                this CRL in the same NEW CA's repository publication point and
           with point.

                It is RECOMMENDED that the same repository publication point name as CRL for the
           previous OLD subordinate NEW CA and EE certificates.  The keys in
           these reissued certificates must not change.

      7.   Excluding manifests, where the signing structure uses have a
           packaging format that includes the EE certificate within the
           signed data, signed objects
                nextUpdate value that included OLD CA-issed EE
           certificates in their signed data will need cause the CRL to be re-signed
           using replaced
                at the end of the Staging Period (see in Step 4 below).

             -  Generate a new key pair, and generate an associated EE
                certificate issued by request with an AIA value of the PENDING CA.  In NEW CA's
                repository publication point.  Pass this EE certificate
                request to the
           case where NEW CA, and use the OLD CA-issued returned (single-use)
                EE certificate is a "single use" as the NEW CA's manifest EE certificate certificate.

             -  Generate a manifest containing the new CA's CRL as the
                only entry, and sign it with the associated private key has been
           previously destroyed, this will entail associated
                with the generation of a
           new manifest EE certificate.  Publish the manifest
                at the NEW CA's repository publication point.

             -  Destroy the private key pair, associated with the issuing of an manifest EE certificate
                certificate.

      4.  The NEW CA enters a Staging Period.  This duration of the
          Staging Period is determined by the PENDING CA, and but it MUST be no less
          than 24 hours.  The Staging Period is intended to afford an
          opportunity for all RPs to download the signing NEW CA certificate,
          prior to publication of certificates, CRLs, and RPKI signed
          objects under the data by NEW CA.  During the newly generated
           private key.  In Staging Period, the case NEW
          CA SHOULD reissue, but not publish, all of a "multi-use" EE certificate, the EE certificate should be products that
          were issued using under the PENDING CURRENT CA.
           The object, together with  This includes all CA
          certificates, EE certificates, and RPKI signed objects.
          Section 4 describes how each reissued product relates to the
          product that it replaces.  During the Staging Period, the
          CURRENT CA SHOULD continue to accept and process certificate
          issuance requests and MUST continue to accept and process
          certificate revocation requests.  If any certificates are
          issued by the CURRENT CA during the staging period, they MUST
          be re-issued under the NEW CA during the period.  Any
          certificates that are revoked under the CURRENT CA MUST NOT be
          re-issued under the NEW CA.

      5.  Upon expiration of the Staging Period, the NEW CA MUST publish
          the signed products that have been re-issued under the NEW CA,
          replacing the corresponding products issued under the CURRENT
          CA at the NEW CA's repository publication point.  This
          replacement is implied by the file naming requirements imposed
          by [ID.ietf-sidr-repos-struct] for these signed products.  The
          trivial manifest for the NEW CA (which contained only one
          entry, for the NEW CA's CRL) is replaced by a manifest listing
          all of these reissued, signed products.  At this point the
          CURENT CA becomes the OLD CA, and the NEW CA becomes the
          CURRENT CA.  Use the OLD CA to issue a manifest that lists
          only the OLD CA's CRL.  It is anticipated that this step is
          very brief, perhaps a few minutes in duration, because the CA
          has reissued all of the signed products during the Staging
          Period.  Nonetheless, it is desirable that the activities
          performed in this step be viewed as atomic by RPs.

      6.  Generate a certificate revocation request for the OLD CA
          certificate and submit it to the issuer of that certificate.
          When the OLD CA certificate is revoked, the CRL for the OLD CA
          is removed from the repository, along with the manifest for
          the OLD CA.  The private key for the OLD CA is destroyed.

3.  Relying Party Requirements

   This procedure defines a Staging Period for CAs performing a key
   rollover operation.  This period is defined as a period no shorter
   than 24 hours.

   RPs who maintain a local cache of the distributed RPKI repository
   MUST perform a local cache synchronisation operation against the
   distributed RPKI repository at regular intervals of no longer than 24
   hours.

4.  Reissuing Certificates and RPKI Signed Objects

   This section provides rules a CA MUST use when it reissues
   certificates and RPKI signed objects as part of the key rollover
   process.  Note that CRLs and manifests are not reissued, per se.
   They are generated for each CA instance.  A manifest catalogues the
   contents of a publication point relative to a CA instance.  A CRL
   lists revoked certificates, relative to a CA instance.  Key rollover
   processing for CRLs and manifests is described above, in Section 3.

4.1.  CA Certificates

   When a CA, as part of the key rollover process, reissues a CA
   certificate, it copies all of the field and extension values from the
   old certificate into the new certificate.  The only exceptions to
   this rule is that the certificate serial number MUST change, and the
   notBefore value MAY be set to the current date and time.

4.2.  RPKI Signed Objects

   An RPKI signed object is a CMS signed-data object, containing an EE
   certificate and a payload (content).  When a key rollover occurs, the issued
   EE certificate, should
           be certificate for the RPKI signed with object MUST be reissued, under the associated private key, and published in
   key of the same repository publication point, using NEW CA.  A CA may choose to treat this EE certificate the
   same
           repository publication point name, as the previously signed
           object way that it replaces (i.e. overwrite the old signed
           object).

      8.   Use the OLD deals with CA certificates, i.e., to issue a manifest that lists copy over all
   fields and extensions, and change only the OLD
           CA's CRL, serial number and use the PENDING
   notBefore date.  If the CA adopts this approach, then the new EE
   certificate is inserted into the CMS wrapper, but the signed context
   remains the same.  (If the signing time or binary signing time values
   in the CMS wrapper are non-null, they MAY be updated to issue a manifest that
           lists all subordinate products that were issued by reflect the
           PENDING CA.

      9.   Mark
   current time.)  Alternatively, the PENDING CA as CURRENT and resume processing
           subordinate certificate issuance requests.

      10.  Generate MAY elect to generate a certificate revocation request new key
   pair for the OLD CA
           certificate and pass this EE certificate.  If it to does so, the entity's Issuer.

      11.  Wait for completion of object content MUST
   be resigned under the OLD CA certificate revocation
           request, then remove private key corresponding to the OLD CA's CRL and Manifest and
           destroy EE
   certificate.  In this case the OLD private key.

3.  Relying Party Requirements

   This procedure defines a "Staging Period" for CAs performing EE certificate MUST contain a new
   public key
   rollover operation, which is defined as and a period no shorter than 24
   hours.

   Relying Parties who maintain new notBefore value, it MAY contain a local cache of new notAfter
   value, but all other field and extension values remain constant.  (If
   the distributed RPKI
   repository MUST perform a local cache synchronisation operation
   against signing time or binary signing time values in the distributed RPKI repository at regular intervals of no
   longer than 24 hours.

4. CMS wrapper are
   non-null, they MAY be updated to reflect the current time.)

5.  Security Considerations

   [To be added]

5.

6.  IANA Considerations

   [Note to IANA, to be removed prior to publication: there are no IANA
   considerations stated in this document.]

6.

7.  Acknowledgements

   The authors would like to acknowledge the review comments of Tim
   Bruijnzeels in preparing this document.

7.

8.  References

7.1.

8.1.  Normative References

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.

   [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.

7.2.

8.2.  Informative References

   [ID.ietf-sidr-arch]
              Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", draft-ietf-sidr-arch-11 (work in
              progress), September 2010.

   [ID.ietf-sidr-repos-struct]
              Huston, G., Loomans, R., and G. Michaleson, "A Profile for
              Resource Certificate Repository Structure", Internet
              Draft draft-ietf-sidr-repos-struct-04.txt, May 2010.

   [ID.ietf-sidr-res-certs]
              Huston, G., Michaleson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", Internet
              Draft draft-ietf-sidr-res-certs-18.txt, May 2010.

Authors' Addresses

   Geoff Huston
   Asia Pacific Network Information Centre

   Email: gih@apnic.net
   URI:   http://www.apnic.net

   George Michaelson

   Email: ggm@apnic.net
   URI:   http://www.apnic.net

   Stephen Kent
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   USA

   Email: kent@bbn.com