SIDR                                                           G. Huston
Internet-Draft                                             G. Michaelson
Intended status: BCP                                               APNIC
Expires: June 6, 2011                                            S. Kent
                                                                     BBN
                                                        December 3, 2010


                      CA Key Rollover in the RPKI
                     draft-ietf-sidr-keyroll-05.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 June 6, 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



Huston, et al.            Expires June 6, 2011                  [Page 1]


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





























Huston, et al.            Expires June 6, 2011                  [Page 2]


Internet-Draft                Key Rollover                 December 2010


1.  Introduction

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

   This document defines a conservative procedure for such entities to
   follow when performing a key 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-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], the
   profile for RPKI Certificates [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 Resource Public Key
   Infrastructure (RPKI) is an entity that issues CA and End Entity (EE)
   certificates and Certificate Revocation Lists (CRLs).  A CA instance
   is associated with a single key pair ([ID.ietf-sidr-res-certs]),
   implying that if key rollover is a regularly scheduled event then,
   over time, there will be many instances of a CA.  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 CA creates a "new" instance of itself, with a new
   key pair, and then effectively substitutes this "new" CA instance
   into the RPKI hierarchy in place of the old CA instance.

   There are several considerations regarding this procedure that MUST
   be followed by 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 made in the context of the RPKI.  A CA cannot assume



Huston, et al.            Expires June 6, 2011                  [Page 3]


Internet-Draft                Key Rollover                 December 2010


   that all RPs will perform path validation and path discovery in the
   same fashion, and therefore the key rollover procedure MUST preserve
   the integrity of the CRL Distribution Points (CRLDP), Subject
   Information Access (SIA) and Authority Information Access (AIA)
   pointers in RPKI certificates.

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

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

   During the transition of the "current" and "new" CA instances it is
   necessary for the "new" CA instance to re-issue all subordinate
   products of the "current" CA.  The procedure described here 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
   objects with these re-issued objects.  The intent of this overwriting
   operation is to ensure that the AIA pointers of subordinate products
   at lower tiers in the RPKI hierarchy remain correct, and that CA key
   rollover does not require any associated actions by any subordinate
   CA.

   There are three CA states described here:

   CURRENT:
      The CURRENT CA is the active CA instance used to accept and
      process certificate issuance and revocation requests The starting
      point for this algorithm is that the key of the CURRENT CA is to
      be rolled over.




Huston, et al.            Expires June 6, 2011                  [Page 4]


Internet-Draft                Key Rollover                 December 2010


   NEW:
      The NEW CA is the CA instance that is being created.  The NEW CA
      is not active, and thus does not accept nor process certificate
      issuance and revocation requests.  The NEW CA SHOULD issue a CRL
      and an EE certificate in association with its manifest to provide
      a trivial, complete, consistent instance of a CA.

   OLD:
      The CA instance is in the process of being removed.  An OLD CA
      instance is unable to process any certificate issuance and
      revocation requests.  An OLD CA instance will continue to issue
      regularly scheduled CRLs and 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 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 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 this key pair and pass the
          request to the CA that issued the CURRENT CA 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 NEW CA
          certificate.  This (NEW) CA certificate will contain a Subject
          Name selected by the issuer, which MUST be distinct from the
          Subject Name used in the CURRENT CA certificate.  The CPS for
          the issuer of the NEW CA certificate will indicate the time
          frame within which a certificate request is expected to be
          processed.

      3.  Publish the NEW CA's CRL and manifest.

             The steps involved here are:

             -  Wait for the issuer of the NEW CA to publish the NEW CA
                certificate.

             -  As quickly as possible following the publication of the
                NEW CA certificate, use the key pair associated with the
                NEW CA to generate an initial, empty CRL, and publish
                this CRL in the NEW CA's repository publication point.



Huston, et al.            Expires June 6, 2011                  [Page 5]


Internet-Draft                Key Rollover                 December 2010


                It is RECOMMENDED that the CRL for the NEW CA have a
                nextUpdate value that will cause the CRL to be replaced
                at the end of the Staging Period (see in Step 4 below).

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

             -  Generate a manifest containing the new CA's CRL as the
                only entry, and sign it with the private key associated
                with the manifest EE certificate.  Publish the manifest
                at the NEW CA's repository publication point.

             -  Destroy the private key associated with the manifest EE
                certificate.

      4.  The NEW CA enters a Staging Period.  This duration of the
          Staging Period is determined by the CA, but it MUST be no less
          than 24 hours.  The Staging Period is intended to afford an
          opportunity for all RPs to download the NEW CA certificate,
          prior to publication of certificates, CRLs, and RPKI signed
          objects under the NEW CA.  During the Staging Period, the NEW
          CA SHOULD re-issue, but not publish, all of the products that
          were issued under the CURRENT CA.  This includes all CA
          certificates, EE certificates, and RPKI signed objects.
          Section 4 describes how each re-issued 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 re-issued, signed products.  At this point the
          CURRENT CA becomes the OLD CA, and the NEW CA becomes the
          CURRENT CA.  Use the OLD CA to issue a manifest that lists



Huston, et al.            Expires June 6, 2011                  [Page 6]


Internet-Draft                Key Rollover                 December 2010


          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 re-issued 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.  Re-issuing Certificates and RPKI Signed Objects

   This section provides rules a CA MUST use when it re-issues
   subordinate certificates and RPKI signed objects
   [ID.ietf-sidr-signed-object] as part of the key rollover process.
   Note that CRLs and manifests are not re-issued, 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, re-issues 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 are that the notBefore value MAY be set to the current date
   and time, and the certificate serial number MAY change.  Because the
   re-issued CA certificate is issued by a different CA instance, it is
   not a requirement that the certificate serial number change in the
   re-issued certificate.  Nonetheless, the CA MUST ensure that each
   certificate issued under a specific CA instance (a distinct name and



Huston, et al.            Expires June 6, 2011                  [Page 7]


Internet-Draft                Key Rollover                 December 2010


   key) contains a unique serial number.

4.2.  RPKI Signed Objects

   An RPKI signed object is a CMS signed-data object, containing an EE
   certificate and a payload (content) [ID.ietf-sidr-signed-object].
   When a key rollover occurs, the EE certificate for the RPKI signed
   object MUST be re-issued, under the key of the NEW CA.  A CA MAY
   choose to treat this EE certificate the same way that it deals with
   CA certificates, i.e., to copy over all fields and extensions, and
   MAY change only the notBefore date and the serial number.  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 reflect the current time.)
   Alternatively, the CA MAY elect to generate a new key pair for this
   EE certificate.  If it does so, the object content MUST be resigned
   under the private key corresponding to the EE certificate.  In this
   case the EE certificate MUST contain a new public key and a new
   notBefore value, and it MAY contain a new notAfter value, but all
   other field and extension values, other that those relating to the
   digital signature and its associated certificate validation path,
   remain unchanged.  If the signing time or binary signing time values
   in the CMS wrapper are non-null, they MAY be updated to reflect the
   current time.

   As noted in Section 2.1.6.4.3 and 2.1.6.4.4 of
   [ID.ietf-sidr-signed-object], the presence or absence of the
   SigningTime and/or the BinarySigningTime attribute MUST NOT affect
   the validity of the RPKI signed object.


5.  Security Considerations

   No key should be used forever.  The longer a key is in use, the
   greater the probability that it will have been compromised through
   carelessness, accident, espionage, or cryptanalysis.  Infrequent key
   rollover increases the risk that the rollover procedures will not be
   followed to the appropriate level of precision, increasing the risk
   of operational failure of some form in the key rollover process.
   Regular scheduling of key rollover is generally considered to be a
   part of a prudent key management practice.  However, key rollover
   does impose additional operational burdens on both the CA and upon
   the population of RPs.

   These considerations imply that in choosing lifetimes for the keys it
   manages, a CA should balance security and operational impact (on
   RPs).  A CA should perform key rollover at regularly scheduled



Huston, et al.            Expires June 6, 2011                  [Page 8]


Internet-Draft                Key Rollover                 December 2010


   intervals.  These intervals should be frequent enough to minimize the
   risks associated with key compromise (noted above) and to maintain
   local operational proficiency with respect to the key rollover
   process.  However, key lifetimes should be sufficiently long so that
   the (system-wide) load associated with key rollover events (across
   the entire RPKI) does not impose an excessive burden upon the
   population of RPs.  RPs are encouraged to maintain an accurate local
   cache of the current state of the RPKI, which implies frequent
   queries to the RPKI repository system to detect changes.  When a CA
   rekeys, it changes many signed objects, thus impacting all RPs.


6.  IANA Considerations

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


7.  Acknowledgements

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


8.  References

8.1.  Normative References

   [ID.ietf-sidr-repos-struct]
              Huston, G., Loomans, R., and G. Michaelson, "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., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", Internet
              Draft draft-ietf-sidr-res-certs-18.txt, May 2010.

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






Huston, et al.            Expires June 6, 2011                  [Page 9]


Internet-Draft                Key Rollover                 December 2010


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-signed-object]
              Lepinski, M., Chi, A., and S. Kent, "Signed Object
              Template for the Resource Public Key Infrastructure",
              draft-ietf-sidr-signed-object-01.txt (work in progress),
              October 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















Huston, et al.            Expires June 6, 2011                 [Page 10]