Skip to main content

Root CA Certificate Rekeying in the Scenario of Post Quantum Migration
draft-wang-lamps-root-ca-cert-rekeying-00

Document Type Active Internet-Draft (individual)
Authors Guilin WANG , Yanjiang Yang , Jie Zhang
Last updated 2024-07-05
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-lamps-root-ca-cert-rekeying-00
Limited Additional Mechanisms for PKIX and SMIME            G. Wang, Ed.
Internet-Draft                                                   Y. Yang
Intended status: Standards Track                     Huawei Int. Pte Ltd
Expires: 6 January 2025                                         J. Zhang
                                                        Huawei Tech. Ltd
                                                             5 July 2024

 Root CA Certificate Rekeying in the Scenario of Post Quantum Migration
               draft-wang-lamps-root-ca-cert-rekeying-00

Abstract

   In the public key infrastructures (PKIs), root certifcation authority
   (CA) certificate rekeying is crucial to guarantee business
   continuity.  Two approaches are given in [RFC4210] for entities which
   are belonging to different generations to verify each other's
   certificate chain.  However, these two approaches rely on the
   assumption that the old entities can be updated.  In this draft, we
   propose a one-way link certificate based solution such that old
   entities are transparent to root CA certificate rekeying.  Namely,
   during the overlapping lifetime of two root CA certificates, without
   any update in old entities, old and new entities can verify each
   other's certificate chain smoothly.  Furthermore, the proposed
   solution works in both traditional PKIs, and post-quantum (PQ) PKIs,
   where the cerficate can be pure PQ ones or hybrid ones.

Editorial Note (To be removed by RFC Editor)

   Discussion of this draft takes place on the rfc-interest mailing list
   (rfc-interest@rfc-editor.org), which has its home page at
   https://www.rfc-editor.org/mailman/listinfo/rfc-interest.

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 https://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."

Wang, et al.             Expires 6 January 2025                 [Page 1]
Internet-Draft            Root CA Cert Rekeying                July 2024

   This Internet-Draft will expire on 6 January 2025.

Copyright Notice

   Copyright (c) 2024 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
   3.  Design Goals of a New Solution for Root CA Rekeying . . . . .   5
   4.  The Proposed Solution Based on One-way Link Certificate . . .   6
   5.  Testing Results . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   In the public key infrastructures (PKIs), root certification
   authority (CA) certificate management is crucial to guarantee
   business continuity, as the CA certificate is the trust anchor for
   certificate chains, which establish the trust paths in PKIs from end
   users to the trusted authority, i.e., the root CA.

   However, just like the certificates for end users, the root CA
   certificate has a limited time of liftime as well, which normally
   varies from a few years to several decades to satsify various
   applications.  Further more, while new end user certificates can be
   issued when old ones are nealy expiring, but a new root CA
   certificate should be issued normally when the old root CA
   certificate has been just used for half of its lifetime.  Here are
   the main reasonos behind this pratice.

Wang, et al.             Expires 6 January 2025                 [Page 2]
Internet-Draft            Root CA Cert Rekeying                July 2024

   A root CA ceritifate is generally used to issue one or more
   suborniate CA (sub-CA) certificates (for different departments in a
   given organization, for exmpale), and then each of scuh sub-CA
   certificate is used to issue lower level sub-CA certificates or end
   user certificates.  The lifetime of ened user ceritificates are
   expected to be around a given period, say 5 years (for some specific
   products, for example).  Accoridg to [RFC4210], to issue end user
   certificates with validity of 5 years, the remaining lifetime of the
   sub-CA certificate must be 5 years or more, such that the lifetime of
   each end user certificate MUST be covered by that of the sub-CA
   certificate.  However, to avoid frequenly apply and mannage multiple
   or even many sub_CA certificates, the liftetime of each sub-CA
   certicate could be set as 10 years, which means for each 5 years sub-
   CA sub_CA certificates should be updated so that end ceritificates
   for new users or products can still be continously issued to
   guarratte business continuity.  Similarly, for continously issuing
   sub_CA certificates with validity of 10 years without frequently
   changing the root CA certificate, it can be expected that each root
   CA certificate may has lifetime of 20 years, which also implies that
   each root CA certificate should be updated for each 10 years, not
   nearly the expiry date of the root CA certificate.  Each such new
   root CA certificate can be called a new generation of root CA
   certificate, though all of them still belong to the same legal
   entity, a particular CA.

   However, this also implies that different sub-CA certificates and end
   user certificates issued under different generations of root CA
   certificate co-exit during the overlapping period of those root CA
   certificastes.  So, it may be not easy to verify each other's
   certificate chain between entities that hold different generations of
   certificates issued by the same CA in the aspect of legal meaning but
   under different generations of root CA certificates.

   Say, for the above example, the sub-CA certifiates and end user
   certifiates issued under the first genarteation of root CA
   certificate may still be valid in the year of 12 when a given CA has
   been established, but the newly issued sub-CA certifiates and end
   user certifiates are actually under the second genarteation of root
   CA certificate.  For simpliciy, we call the owner of a sub-CA
   certifiate or such an end user as an entity or a device.  Moreover, a
   device or entity hold certificate chain issued by an old generation
   of root CA certificate are called as old device or old entity, while
   a device or entity hold certificate chain issued by a new generation
   of root CA certificate are called as new device or new entity.  These
   terms are in a relative way.

   Actually, to address the above issue, there are two solutions given
   in [RFC4210]:

Wang, et al.             Expires 6 January 2025                 [Page 3]
Internet-Draft            Root CA Cert Rekeying                July 2024

   *  Old and new entities upload both old and new root CA certificates,

   *  Or upload two-way link certificates which introduce old CA to new
      CA and vice versa.

   However, these two solutions do not work if old entities cannot
   upload the new root certificates or the necessary link certificate,
   or old devices are even out of maintenance.  In fact, such worse
   cases are possible, due to either limited prediction fo product
   design such that old devices may do not support adding multiple root
   CA or link certificates (automatically), or still running old devices
   are not maintained well and automatically update is not supported.

   Back a little bit, basically, there are actullay two approaches to
   update root CA certifiate, i.e., renewing and rekeying.  The former
   means to extend the validity of an existing root CA certificate but
   the root CA key pair and the associated cryptographical algorithm is
   still the same.  In this case, the validity of the same (old) key
   pair of the root CA will be extended for a longer period.  So,
   attackers shall have longer time to cryptanalyze the same key pairs.
   Also, as time goes, the secuirty strenth of the associated
   cryptographical algorithm for the root CA certificate may become
   weaker and weaker.  So, soon or later, it still needs to issue a
   brand new CA certificate.

   For the latter, namely rekeying approach, a brand new root CA
   certificate will be issued to replace the old key pair.  In this
   case,no just a new pair of keys, even different key length or new
   algorithm can be used for generating the new root CA certificate by
   considering the progress of cryptoanlysis and potentil security
   threads in the near future, like quantum computing.  However, in this
   situation, a big challenge is to manage two or even multiple root CA
   certificates during the overlapping periods, which could be 20 years
   or more, as mentioned in the above.  In particular, some old devices
   may be not able to install the new root CA or link certificates, such
   that the two solutions given in [RFC4210] do not work.  Therefore,
   old devices may not be able to verify the new certificate chain of a
   new device, though a new device can be intalled all necessary
   certifiates and verify the old certificate chains of old devices.

   Motivated by the above observation, this draft proposes a one-way
   link certificate based solution such that root CA certificate
   rekeying is transparent to old entities:

   *  During the overlapping period of two or multiple root CA
      certificates, without any update in old entities, old and new
      entities can verify each other's certificate chain smoothly.

Wang, et al.             Expires 6 January 2025                 [Page 4]
Internet-Draft            Root CA Cert Rekeying                July 2024

   *  The proposed solution works in the scenario of traditional PKIs,
      pure post-quantum PKIs, and also hybrid PKIs [I-D.D24], as the
      rationale of the solution does not rely on the type of undelying
      cryptographic algorithms.

   *  Esentially, the solution can be viewed as an extension of the
      approach for root CA certificate issuing and managnement
      specififed in [RFC4210] and [RFC5280].

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Design Goals of a New Solution for Root CA Rekeying

   Basically speaking, to design the root CA rekeying solution based on
   one-way link certificate, the following principles are followed to
   maximize the potential employment of the solution in practice:

   *  Requirements on old devices are minimized such that the solution
      is applicable to as many as possible scenarios.

   *  New devices are supposed to do more as they are normally more
      powerful and designed with better prediction.

   *  When possbile, the usage of the new root CA keys will be maximized
      as normally they associated with cryptographically sronger
      algorithms .

   *  The existing standards [RFC4210] and [RFC5280] will be followed as
      much as possible, so that the deployment of the new solution for
      root CA rekeying can be implemented as easy as possile.

   In Section 6.1 of [RFC5280] : the following is sepecified:

   "A prospective certification path (a sequence of n certificates)
   satisfies the following conditions:

   *  (a) for all x in {1, ..., n-1}, the subject of certificate x is
      the issuer of certificate x+1;

   *  (b) certificate 1 is issued by the trust anchor;

Wang, et al.             Expires 6 January 2025                 [Page 5]
Internet-Draft            Root CA Cert Rekeying                July 2024

   *  (c) certificate n is the certificate to be validated (i.e., the
      target certificate); and

   *  (d) for all x in {1, ..., n}, the certificate was valid at the
      time in question. "

   While Link certificates was introduced in Section 4.4.1 for
   specifying CA operator actions to rekeying root CA certificate
   [RFC4210] as follows.

   " To change the key of the CA, the CA operator does the following:

   *  1.  Generate a new key pair;

   *  2.  Create a certificate containing the old CA public key signed
      with the new private key (the "old with new" certificate);

   *  3.  Create a certificate containing the new CA public key signed
      with the old private key (the "new with old" certificate);

   *  4.  Create a certificate containing the new CA public key signed
      with the new private key (the "new with new" certificate);

   *  5.  Publish these new certificates via the repository and/or other
      means (perhaps using a CAKeyUpdAnn message);

   *  6.  Export the new CA public key so that end entities may acquire
      it using the "out-of-band" mechanism (if required).

   The old CA private key is then no longer required. "

   However, as we mentioned in Section 1, the above solution specified
   in [RFC4210] assumes that (new and old) end entities may acquire the
   new CA public key (using the "out-of-band" mechanism, if needed), as
   the above item 6 despicts.

4.  The Proposed Solution Based on One-way Link Certificate

   Here are the basic idea of the proposed root CA key rekeying based on
   One-way Link Certificate:

   *  Use the one-way link certificate, called newWithOld, which is the
      link certificate of the new public signed by the old private key
      of the root CA.

   *  The newWithOld certifies the new root CA key by the old one.

Wang, et al.             Expires 6 January 2025                 [Page 6]
Internet-Draft            Root CA Cert Rekeying                July 2024

   *  So, during the overlapping period, old devices can verify a link
      certificate chain from a new device by using the old root CA
      certificate as the trust anchor.

   *  Other cases are simple …

      Old Device A                     New Device C
   *******************            ***************************
   *    oldCACet     *            * oldCACert     newCACert *
   *       ^         *            *      ^           ^      *
   *  oldSubCACert   *            *  newWithOld      ^      *
   *       ^         *            *          ^       ^      *
   *    oldCertA     *            *         newSubCAcert    *
   *******************            *              ^          *
               ^                  *           newCertC      *
               | B sends its      ***************************
               | link certificate     ^ B sends either of its two
               | chain to A           | certificate chains to C
               |                      |
             *****************************
             *  oldCACert     newCACert  *
             *         ^        ^        *
             *  newWithOld      ^        *
             *         ^        ^        *
             *        newSubCACert       *
             *              ^            *
             *           newCertB        *
             *****************************
                  New Device B

Figure 1. Illustraion to the Solution Based on One-way Link Certificate.

   Figure 1 shows how a new device B can send out its link certificate
   chain, (oldCACert, newWithOld, nweSubCACert, newCertB), to an old
   device A such that A can verify B's certificate chain by using the
   old root CA cerficate, which is A's trust anchor.  To repsond B, A
   just sends its old certificate chain, (oldCACert, oldSubCACert,
   oldCertA), to new device B, which can verify A's certificate chain by
   using the old root CA cerificate, which is one of B's two trust
   anchors, namely, the old or new root CA certificate.

Wang, et al.             Expires 6 January 2025                 [Page 7]
Internet-Draft            Root CA Cert Rekeying                July 2024

   To communicate with another new device C, new device B can send out
   either its link certificate chain, (oldCACert, newWithOld,
   nweSubCACert, newCertB), or the new certificate chain, (newCAcert,
   newSubCACert, newCertB), to new device C, which can verify either of
   them by using one of its two trust anchors, namely, the old or new
   root CA certificate.  In this case, as both B and C are new devices,
   C can do as B does such that B can verify either of C's two
   certificate chains similarly.

   The case of one old device communicates with another old device is
   simple, as they just behaver as normaly by sending their own old
   certificate chain to the other.

   More detailed description will be provided later.

5.  Testing Results

   The proposed solution has been tested using OpenSSL library.

   *  3 generations of root CA cert.: G1 (2016-2025), G2 (2018-2027),
      and G3 (2020-2029).

   *  ross verifying tests among OpenSSL 1.0.1c, OpenSSL 1.0.2u、OpenSSL
      1.1.1g and JDK 8u251.

   The testing results are given in the following table, which show
   positve answers for all the cases considered.

      +========+===============+=============+===============+
      |         | 2015         |    2016     |    2018      |
      +------------------------------------------------------+
      | G1Sever | (TBD)        |   (TBD)     |    (TBD)      |
      +------------------------------------------------------+
      | G2Sever | (TBD)        |   (TBD)     |    (TBD)      |
      +------------------------------------------------------+
      | G2Sever | (TBD)        |   (TBD)     |    (TBD)      |
      +---------+--------------+-------------+---------------+

      Table 1: Testing Results (to be given)

6.  Security Considerations

   Security analysis will be given later.

7.  Acknowledgments

   To be added later.

Wang, et al.             Expires 6 January 2025                 [Page 8]
Internet-Draft            Root CA Cert Rekeying                July 2024

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210,
              DOI 10.17487/RFC4210, September 2005,
              <https://www.rfc-editor.org/info/rfc4210>.

   [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, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

9.  Informative References

   [I-D.D24]  F. Driscoll, F., "Terminology for Post-Quantum Traditional
              Hybrid Schemes", Work in Progress, Internet-Draft,,
              February 2024, <https://datatracker.ietf.org/doc/draft-
              ietf-pquip-pqt-hybrid-terminology/>.

Authors' Addresses

   Guilin Wang (editor)
   Huawei Int. Pte Ltd
   9 North Buona Vista Drive, #13-01
   The Metropolis Tower 1
   SINGAPORE 138588
   Singapore
   Email: wang.guilin@huawei.com

   Yanjiang Yang
   Huawei Int. Pte Ltd
   Email: yang.yanjiang@huawei.com

   Jie Zhang
   Huawei Tech. Ltd

Wang, et al.             Expires 6 January 2025                 [Page 9]
Internet-Draft            Root CA Cert Rekeying                July 2024

   Email: zhangjie184@huawei.com

Wang, et al.             Expires 6 January 2025                [Page 10]