| Internet-Draft | Root CA Cert Rekeying | July 2024 |
| Wang, et al. | Expires 6 January 2025 | [Page] |
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.¶
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.¶
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."¶
This Internet-Draft will expire on 6 January 2025.¶
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.¶
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.¶
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]:¶
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:¶
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.¶
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:¶
In Section 6.1 of [RFC5280] : the following is sepecified:¶
"A prospective certification path (a sequence of n certificates) satisfies the following conditions:¶
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:¶
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.¶
Here are the basic idea of the proposed root CA key rekeying based on One-way Link Certificate:¶
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.¶
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.¶
The proposed solution has been tested using OpenSSL library.¶
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)¶
Security analysis will be given later.¶
To be added later.¶