Title: An experiment note about CA key pair changeover (Ver 0.4) Author(s): Mine Sakurai (mine@ax.jp.nec.com) Date: 9/1/2004 This document was written on October 16th in 2000 and registered to a WIDE draft in 2004. Abstract A lot of CAs have been managed for several years, but we've not yet seen a situation where CA key pair was changed due to CA certificate expiration. We had an experiment of CA key pair changeover. In this experiment, we examined how a CA key pair changeover would make influences to existing applications. As a result, we found that some of the existing applications required change of CA distinguished name at the same time of CA key pair changeover for smooth transition. Have you ever discussed whether it is important for a CA management policy to change the CA distinguished name or not? If CA name change is not allowed in some CA management policies, we think existing applications should support the CA key pair changeover without change of CA distinguished name. Please send any comments to "moca-wg@wide.ad.jp". 1. background We have a root CA which is called WIDE ROOT CA and two subordinate CAs. WIDE ROOT CA / \ moCA School of Internet CA(SOI CA) Our subordinate CAs, "moCA" and "School of Internet CA", issue certificates below: * TLS/SSL server certificates - Apache_1.3.9_SSL_1.37+openSSL0.9.5a * TLS/SSL client certificates - Netscape Navigator(Version 4.5-4.7) - Internet Explorer(Version 5.00 or higher) (*) * S/MIME certificates - Netscape Messenger(Version 4.5-4.7) - Outlook Express (*) (*) We don't support directly certification for Internet Explorer, but the pkcs#12 files created by Netscape can be imported and used to Internet Explorer, and Outlook Express. You can get the CA information from the URL, http://www.wide.ad.jp/wg/moca/wide_root_ca-e.html 2. A CA key pair changeover We changed all key pairs of this CA hierarchy on January 2000 to extend key length, and issued the new CA certificates. WIDE ROOT CA(old) WIDE ROOT CA(new) / \ / \ moCA SOI CA ==> moCA SOI CA (old) (old) (new) (new) Using this opportunity, we wanted to investigate if the existing applications such as secure WWW(TLS/SSL) and security enhanced email(S/MIME) could handle CA key pair changeover. Of course, all end-entity certificates were to be re-issued. It is not practical that all end-entity certificates are re-issued at the same time of CA key pair changeover. It is less confused to provide transition period for new and old CA key pairs and allow either key pair in use during the period. One of the issues in the key pair transition is that communications might be failed, because we can't assume that all of the peers have set the new CA key pair during the period. If a CA has multiple certificates and we don't know which one is used for signing an end-entity certificate, we can find the correct key by verifying the end-entity certificate with each CA certificate. RFC2459 provides better way to distinguish multiple CA public-keys using the subjectKeyIdentifier and authorityKeyIdentifier extension field. RFC2510 describes about the root CA key pair transition using NewwithOld and OldwithNew certificate. Does the real world have enough implementations yet? From now on, we focus on the WIDE ROOT CA and the moCA and describe our experiment in detail. We put three assumptions: (a) Both the new and old CA certificates are valid during the transition period below. ---------------------------------------------------> time the old CA cert <======================> the new CA cert <==============================> |-------| the transition period During this period, some of the end-entity certificates are signed by the old CA private key, and the others are signed by the new CA private key. (b) The new and old CAs have the same distinguished name. ex. The WIDE ROOT CA's distinguished name is "CN=ROOT CA, O=WIDE Project, C=JP". The moCA's distinguished name is "OU=members only CA, O=WIDE Project, C=JP". (c) All of the old CA certificates didn't include the subjectKeyIdentifier extension field, and all of the old end-entity certificates didn't include the authorityKeyIdentifier extension field. The goal of this experiment was to examine if the existing applications could handle the new and old CA with the same name during the transition period or to find a way to handle this situation. That means: (1) secure WWW(TLS/SSL) Q1 - Assume that a WWW client (browser) has the new CA certificate. Is it possible for the WWW client to correctly validate both the old WWW server certificates signed by the old CA and the new WWW server certificates signed by the new CA in a TLS/SSL server authentication? Q2 - Assume that a WWW server (Apache+openSSL server) has the new CA and the new WWW server certificates in use. Is it possible for the WWW server to correctly validate both the old WWW client certificates signed by the old CA and the new WWW client certificates signed by the new CA in a TLS/SSL client authentication? (2) security enhanced email (S/MIME) Assume that a User1 has his/her own new key pair and the new CA certificate in his/her certificate database. The new CA certificate is trusted for S/MIME. Q3 - Is it possible for User1 to decrypt an encrypted mail using the User1's old public key? Q4 - Is it possible for User1 to validate a signed mail using the User2's old private key? Q5 - Is it possible for User1 to send an encrypted mail using the User2's old public key? Q6 - Is it available for User1 to send a signed mail using the User1's new private key? 3. The results First, we could not find a way to handle NewwithOld and OldwithNew certificate described in RFC2510 about all of the applications we examined. Those certificates were treated as self-signed certificates. So, we couldn't examine validity of a certificate combination such as NewwithNew->OldwithNew->User1withOld. Secondly, we tried to find other way, but we could not find a common way to solve all of these questions above. The details are below. (1) secure WWW(TLS/SSL) to Q1: The result depended on browsers. We could store both the new and old CA certificates with the same name as trusted CAs in the browsers' certificate database. So, we stored both the new and old WIDE ROOT CA certificates as trusted CAs in the browsers' certificate database and trusted them. Whether we should store the subordinate CA(moCA) certificates or not depended on the browsers. Internet Explorer: Yes, it could correctly validate either, i.e. both the new and old WWW server certificates. We stored both the new and old subordinate CA's certificates in the certificate database at the experiment. Even if we stored only the old subordinate CA's certificate, we got the same result. Since the subordinate CA certificate is given by the WWW server during the TLS/SSL session, IE uses the subordinate CA certificate instead of the one in the certificate database for verification, I guess. Netscape Navigator: Yes, it could correctly validate either ONLY if all of the conditions below are satistied: * the new subordinate CA certificate includes the subjectKeyIdentifier * the new WWW server certificate includes the authorityKeyIdentifier * the old subordinate CA certificate is stored in the certificate database, but the new subordinate CA certificate is NOT stored. Otherwise, it could validate only the new WWW server certificate, but couldn't validate the old WWW server certificate. Thus we couldn't access to the WWW server with old certificate. to Q2: No. If a Apache server uses TLS/SSL client authentication, we must provide two Apache servers with the same contents during the transition period. The one server has the server certificate signed by the old CA, and the other one has the server certificate signed by the new CA. Though we can set multiple CA certificates on the directory specified in the Apache configuration file, we couldn't set both the new and old CA certificates with the same name on the directory. It is the openSSL specification that it searches a CA certificate only on the basis of CA's distinguished name in certificate validation. Using the subjectKeyIdentifier and authorityKeyIdentifier extension field didn't make any effect. We tried to investigate what happened if we put the new and old CA certificates on the CA certificates directory, naming the old one "3bd9fb5a.0" and naming the new one "3bd9fb5a.1". But, "3bd9fb5a.1" was ignored. (2) security enhanced email (S/MIME) Outlook Express and Internet Explorer share the same certificate database. So do Netscape Messenger and Netscape Navigator. Since we could store both the new and old WIDE ROOT CA certificates as trusted CAs in the Internet Explorer and Netscape Navigator, so could Outlook Express and Netscape Messenger. Both Outlook Express and Netscape Messenger needed to store the new subordinate certificate for sending a signed mail using the new private key. Then we assume that both the new and old subordinate certificates are set in the certificate database as well as the new and old root CA certificates when these tools set new key pair. Those CA certificates are trusted for S/MIME. to Q3: Yes, User1 could read the encrypted mail using the User1's old public key if the User1's old private key remained in the certificate database. We should announce to users not remove their old certificates when they set their own new key pair. to Q4: The result depended on the tools. - Outlook Express Yes, the signature using the User2's old private key was valid during the transition period. Since the certificate database which is shared with Outlook Express and Internet Explorer is able to handle either the old or the new CA certificates, Outlook Express can find the validation path for the User2's old certificate. - Netscape Messenger Almost No. The signature using the User2's old private key was valid during the transition period ONLY if all of the conditions below are satisfied: * the new subordinate CA certificate includes the subjectKeyIdentifier * the User1's new certificate includes the authorityKeyIdentifier * the new WIDE ROOT CA certificate is stored in the certificate database, but the new subordinate CA certificate is NOT stored This means that User1 can't correctly validate the signature using User2's old private key after User1 begins to sign using the User1's new private key. to Q5: Yes, User1 could send a encrypted mail using the User2's old public key if User1 had the User2's old certificate in the certificate database. We didn't examine well what happened if both the User2's new and old certificates were stored in the certificate database. In case of Netscape Messenger, User1 couldn't select the User2's old certificate. to Q6: In case of Outlook Express, User1 could send a signed mail using his/her own old private key. In case of Netscape Messenger, User1 could not send a signed mail using his/her own old private key unless the new subordinate CA certificate was removed from the certificate database. 4. Conclusions The way to handle the new and old CA certificates with the same name had some inconsistency between secure WWW and security enhanced email. Since our subordinate, moCA support both secure WWW and security enhanced email, we couldn't find a good solution. We had to give up the support of the old CA certificates. The assumption (b) made the situation more complicated. If we change a CA key pair, it is less problematic to change part of the CA distinguished name. But, we haven't discussed if the CA name should be changed or not in CA key pair changeover. I think that an application should have an ability to trust both new and old CA certificates with the same name if the application could have multiple trusted CAs. We found that Internet Explorer and Netscape Navigator recognized the subjectKeyIdentifier and authorityKeyIdentifier. If the old CA certificates had included the subjectKeyIdentifier, we might have found a good solution. But in the real world, many root CA certificates don't include the subjectKeyIdentifier extension field. If we could add the subjectKeyIdentifier to root CA certificate later, it is difficult to add the authorityKeyIdentifier to all of the end-entity certificates later. We recommend that the subjectKeyIdentifier extension field is used for a CA certificate and the authorityKeyIdentifier extension field is used for new end-entity certificates if you set up a CA from now. Apache+openSSL didn't have an ability to make a validation path using the subjectKeyIdentifier and authorityKeyIdentifier at that time(*). We request that openSSL will support this ability and also handle duplication of CA name hash value. (*)We noticed that openSSL0.9.6 could construct a validation path using the subjectKeyIdentifier and authorityKeyIdentifier. But we know that the new version couldn't have solved our issue because our old CA and end-entity certificates did not include those extension fields. Copyright Notice Copyright (C) WIDE Project (2000-2004). All Rights Reserved. [the End]