Internet Draft D. Pinkas, Bull PKIX Working Group J. Kazin, Jefferson Wells expires in six months June 2007 Target Category: Informational Internet X.509 Public Key Infrastructure PKI Disaster Recovery and Key Rollover Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document presents a framework to assist the writers of policy or practice statements and the designers of a Public Key Infrastructure to prepare disaster recovery plans in case of a private key-compromise or a private key-loss. This may happen to end-entity keys, Certification Authorities, Revocation Authorities, Attribute Authorities, or Time-Stamping Authorities. Since certificates have finite validity, CA key-rollover should be planned in advance. In addition, denial of service attacks on Repositories holding CRLs has also to be considered. This framework provides a comprehensive list of potential key- compromise or key-loss conditions that, in the opinion of the authors, should be addressed so that it is possible to quickly recover from exceptional situations. Pinkas et. al. Informational [Page 1] Internet-draft PKI Disaster recovery and key rollover June 2007 TABLE OF CONTENTS 1. INTRODUCTION 1.1 BACKGROUND 4 1.2 PURPOSE 4 1.3 SCOPE 4 2. ABREVIATIONS 4 3. CONCEPTS 5 4. Subscribers (End-Entities) keys 5 4.1. Signature keys 5 4.1.1. Signature key-compromise 5 4.1.1.1. Key used for authentication, access control, and confidentiality 5 4.1.1.2. Key used for short-term non repudiation 5 4.1.1.3. Key used for long-term non repudiation 6 4.1.1.3. Key length considerations 7 4.1.2. Signature key-loss 7 4.1.3. Key rollover 7 4.2 Decryption key 8 4.2.1. Decryption key-compromise 8 4.2.1.1. Key used to decrypt stored data 8 4.2.1.2. Key used to decrypt communications 8 4.2.2. Decryption key-loss 9 4.2.2.1. Key used to decrypt stored data 9 4.2.2.2. Key used to decrypt communications 10 5. Certification Authority 10 5.1. Authority key-compromise 10 5.1.1. Root CA key-compromise 11 5.1.2. Intermediate CA key-compromise 11 5.1.2.1. CA key-compromise during certificate life-time 11 5.1.2.2. CA key-compromise beyond certificate life-time 14 5.2. CA key-loss 15 5.3. Key rollover 15 5.3.1. For root keys 15 5.3.2. For intermediate keys 16 5.3.3. For leaf keys 16 6. Revocation Authority 16 6.1. CA key-compromise within certificate life-time 16 6.2. CRL Issuer key-compromise within certificate life-time 17 6.3. OCSP responder key-compromise within certificate life-time 17 6.4. Revocation Authority key-compromise beyond certificate life-time 18 6.5. Revocation Authority key-loss 18 7. Attribute Authorities 18 7.1. Attribute certificate revocation 18 7.2. Attribute Authority Key compromise 18 7.3. Attribute Authority Key loss 19 Pinkas et. al. Informational [Page 2] Internet-draft PKI Disaster recovery and key rollover June 2007 8. Time-Stamping Unit keys 19 8.1. Time-Stamping Unit Key loss 19 8.2. Time-Stamping Unit Key compromise 20 8.2.1. Compromise during the validity period of the TSU certificate 20 8.2.1.1. Checking during the validity period of the TSU certificate 20 8.2.1.2. Checking beyond the validity period of the TSU certificate 21 8.2.2. Compromise after the end of the validity period of the TSU certificate 22 9. CRL Repositories 22 10. Security considerations 23 11. Acknowledgments 23 12. IANA considerations 23 13. References 23 14. Authors' addresses 24 15. Full Copyright Statement 24 Pinkas et. al. Informational [Page 3] Internet-draft PKI Disaster recovery and key rollover June 2007 1. INTRODUCTION 1.1 BACKGROUND A CA should expect end-entities to experience private key-compromise and/or loss. However, private key-compromise and/or key-loss for Authority keys should not happen, but might occur so, it is prudent to develop procedures for how to recover from such events. As a general rule, to limit the damage caused by a key-compromise, the private key-usage lifetime - not to be confused with the certificate-validity period - should be limited and key-compromise and key-rollover responses should be planned in advance. 1.2 PURPOSE The framework identifies ways to recover from a key-compromise or a key-loss and to restore normal operations: this is known as a disaster recovery plan. While recovery times may vary based on implementation factors, shorter recovery times are better. The framework also provides guidance for key-rollover. 1.2 SCOPE The scope of this document covers the loss of use of a private key due to the actual destruction of the key-material (key-loss), the actual or suspected theft of key-material (key-compromise), and key- rollover for subscribers (leaf certificates issued to end-entities) as well as for PKI Authorities. It is assumed that the reader is familiar with the general concepts of public-key cryptography, public-key infrastructure and its artifacts and protocols: digital signatures, digital certificates, the Online Certificate Status Protocol (see [OCSP]), Attributes Certificates (see [AC]) and the Time-Stamp Protocol (see [TSP]), etc., as used in X.509 and RFC 3280 (see [PKIX-1]) or its successors. The framework as presented assumes use of the PKI as described in RFC 3280 or its successors, as well as RFC 2560. 2. ABREVIATIONS This document makes use of the following abbreviations: AA : Attribute Authority AC: Attribute Certificate ARL: Authority Revocation List CA: Certification Authority CRL: Certificate Revocation List HTTPS: Hyper Text Transfer Protocol Secure OCSP: On line Certificate Status Protocol SSL: Secure Socket Layer TSU : Time-Stamping Unit Pinkas et. al. Informational [Page 4] Internet-draft PKI Disaster recovery and key rollover June 2007 3. CONCEPTS Key compromise needs to be considered for two different time periods: 1) during the validity period of the certificate (and of all superior certificates in its certification chain), but also before the beginning of the validity period of the current certificate in case of certificate renewal; 2) after the end of the validity period of the certificate. The first case applies to the use of certificates for the following security services: authentication, message-integrity, short-term non-repudiation (i.e. during the validity period of the certificate) and message-confidentiality. The second case applies to the use of certificates for long-term non-repudiation security services (i.e. beyond the validity period of the certificate). 4. Subscribers (End-Entities) keys 4.1. Signature keys 4.1.1. Signature key-compromise Should a signature creation key be lost or compromised, then the corresponding certificate shall be revoked. A new key pair shall be generated and a new certificate shall be issued. The certificate corresponding to the lost/compromised private-key shall be revoked and its serial number placed in a Certificate Revocation List (CRL) or communicated to an OCSP responder. 4.1.1.1. Key used for authentication, and message-confidentiality During real-time use, such as authentication to protected resources, and message-confidentiality, relying parties will be able to check the revocation status of a certificate using CRLs or OCSP responses. 4.1.1.2. Key used for short-term non-repudiation Digital signatures created during the certificate-validity period, and before certificate-revocation shall continue to be valid. When verifying a signature, it will be necessary to prove to an arbitrator that the signer?s digital signature was, indeed, created before the certificate was revoked. There are two ways to provide that evidence: - Time-Stamping, or - Time-Marking. Pinkas et. al. Informational [Page 5] Internet-draft PKI Disaster recovery and key rollover June 2007 When using Time-Stamping, a time-stamp token will be applied over the digital signature, which demonstrates that the digital signature was created before the date included in the time-stamp token. If the date and time contained in the Time-Stamp token is during the validity period of the certificate (and as close to the digital signature time as possible), and the signer?s certificate has not been revoked, then it can be asserted that the digital signature was, indeed, created while the certificate was valid. In order to be guarded against the possible revocation of a signer?s certificate, it is advisable to obtain a Time-Stamp token as soon as possible after the signature has been created. When using Time-Marking, i.e., an audit trail from a Trust Service Provider, it is necessary to disclose the format of the audit trail, the procedures used to create it, to produce the physical media and to reveal other records that are in the audit trail. It would be extremely difficult to standardize the format of such audit trails as well as that of physical media . Additionally, the Trust Service Provider should be independent of any parties involved in a dispute, otherwise there might be an allegation of collusion between one of the parties and the Trusted Service Provider. For these reasons, time-stamping is recommended. For the rest of this document, only the use of Time-Stamping is assumed. 4.1.1.3. Key used for long-term non repudiation When used in the context of a long-term non-repudiation security service, it is necessary to prove that the digital signature was created while the certificate was valid. CAs are not required to manage revocation information of digital certificates beyond the end of the validity period of that certificate (see section 3.3 Revocation from [PKIX-1]: ?An entry may be removed from the CRL after appearing on one regularly scheduled CRL issued beyond the revoked certificate's validity period"). In other words, if, beyond the end of the validity period of the certificate, it was reported that a private key had been compromised during or after the validity period of the certificate, the revocation request will not be honored by the CA and the serial number of the certificate will NOT be added to the CRL or communicated to an OCSP responder. So, in order to prove that the signature was created during the validity period of the certificate, a Time-Stamp token should be applied to the signature at a time as close as possible to the creation of the signature, and at latest before the end of the validity period of the certificate. Pinkas et. al. Informational [Page 6] Internet-draft PKI Disaster recovery and key rollover June 2007 4.1.1.3. Key length considerations The use of a Time-Stamp token has an important side benefit. Most of the time, it is believed that that for a digital signature to remain valid for 10 years, a key size that can resist attacks during 10 years is needed. If Time-Stamping is being used to assert the validity of the digital signature, this is no longer critical. The rule is that the signer's signature key must only resist to attacks during the validity period of the certificate (usually a couple of years). Only the signature applied by the time-stamping unit must resist to attacks and remain valid for the period in question, as that proves that the service in charge of the TSU saw the digital signature at the indicated time in the past. 4.1.2. Signature key-loss Should a signature creation key be lost, and where a compromise or theft of key-material is not suspected, then if a back-up copy of that key exists, that back-up copy should be installed. Otherwise, the corresponding certificate shall be revoked. A new key pair shall be generated and a new certificate shall be issued. However, the TSU's signing key should be able to resist attacks during the entire period in which the signature is expected to be validated. If the TSU's signature key is close to becoming vulnerable to cryptographic attacks, then it is necessary to apply an additional and stronger time-stamp token before the private key from the previous TSU can be cracked. It is important to remember that Time-Stamping enables the use of smaller keys for signers which speeds up the signature generation process. 4.1.3. Key rollover Revocation information about certificates need only be posted from the first CRL issued after the time of reporting the loss/compromise of a subscriber's key, until the next CRL following the end of the validity period of the lost/compromised certificate. If a digital signature was issued close to the end of the validity period of the corresponding certificate of that signature key, then there would be no posting of CRL information beyond once following the end of the validity period of the certificate. However, a digital signature used in the context of a non- repudiation service is not necessarily verified immediately after it has been created, but in some cases a few days later. In order to avoid disputes about the validity of a signature, it is recommended not to use the keys close to the end of the validity period of the corresponding certificate. To this respect, new leaf keys should be made available before the end of the validity period (e.g. one month) of the corresponding certificate and the current Pinkas et. al. Informational [Page 7] Internet-draft PKI Disaster recovery and key rollover June 2007 leaf keys should not be used close to the end of the validity period of the corresponding certificate. This means that leaf certificates should have overlapping validity periods (e.g. of one month). 4.2 Decryption key 4.2.1. Decryption key-compromise Two cases need to be considered whether that key was used to decrypt stored data or to decrypt communications. 4.2.1.1. Key used to decrypt stored data In this case, if encrypted data is not protected by an access control scheme, then it would be possible for an attacker to access the encrypted data, and decrypt that data with the compromised key. For that reason, it is recommended to use an encryption service with an access control scheme controlling access to the ciphertext. Otherwise as soon as the key-compromise is detected, the stored data shall be placed under access control. Since asymmetric decryption is computationally intensive and slower in comparison to symmetric-key decryption, data is generally first encrypted under a working key using a symmetric-key algorithm and the working symmetric-key is, in turn, encrypted under a public key. To decrypt data, each working symmetric-key shall be first decrypted and the symmetric-key is then used to decrypt ciphertext data. It should be noticed that, in some cases, a legitimate user will both experience a key-compromise and a key-loss, and if it still needs an encryption key to encrypt further data, it will have to follow the recommendations for key-loss. 4.2.1.2. Key used to decrypt communications If an encrypted communication session has been previously recorded, and if an encryption key is being used to encrypt a session key, with the aid of the compromised decryption key, then it may be possible for an attacker to decrypt the intercepted communications. Note: If the communication was encrypted using a session key built using a signed Diffie-Hellmann exchange, then this kind of attack does not apply. If the communication line has not been tapped, then there is no risk of transient data being compromised from a lost/compromised key and no further action is necessary with respect to communication data. Pinkas et. al. Informational [Page 8] Internet-draft PKI Disaster recovery and key rollover June 2007 4.2.2. Decryption key-loss If a decryption key is deemed lost (but not compromised), then two cases need to be considered: 1) whether that key was used to decrypt transient communications (Data-in-Transit), or 2) it was used to decrypt stored data (Data-at-Rest). 4.2.2.1. Key used to decrypt stored data (Data-at-Rest) If it is still necessary to decrypt stored ciphertext, two techniques may be used to recover from lost keys: - Key-escrow, or - Key-recovery. Note that there exists a spectrum of variations between these two techniques. When using key-escrow, a backup of every decryption key is kept by a Key Escrow Center (KEC). When the key is lost, a copy of the private key is retrieved from escrow and provided to the subscriber. The certificate is not revoked. When using key-recovery, data is stored encrypted under a working symmetric-key that is encrypted under the public encryption key of the subscriber, and one or more asymmetric Recovery Keys. In this case, since the private key is lost, the certificate shall be revoked, so that the public encryption key will not be used for further encrypting data. A new key pair, as well as a new certificate, shall be generated. Recovery Keys may be specific to each subscriber, common to a set of subscribers, or common to all subscribers. The extent of recovery key diversification is important. If one or more Recovery Keys are specific to an individual subscriber, they may be communicated to the subscriber, so that the subscriber can recover the working symmetric-key using the recovery key and then replace, in each key recovery field (KRF): a) the working symmetric-key encrypted under the (old) public recovery key by the same working symmetric-key re-encrypted under the new public recovery key, and b) the working symmetric-key encrypted under the (old) public encryption key of the subscriber by the same working symmetric- key re-encrypted under the new public encryption key of the subscriber. Pinkas et. al. Informational [Page 9] Internet-draft PKI Disaster recovery and key rollover June 2007 If the Recovery key is common to a set of subscribers, it cannot be communicated to any one of them, as it could compromise the keys of the others in that set. However, a Key Recovery Center (KRC) is able to recover the common recovery-key. That common key recovery key must not be communicated to the subscriber or used an environment that is not known to be secured. So each set of KRF data shall be communicated to the KRC and processed in the KRC premises. Each key recovery field (KRF) that contains : a) the working symmetric-key encrypted under the (old) public recovery key, will be processed by the KRC and replaced by the same working symmetric-key re-encrypted under the new public recovery key, and b) the working symmetric-key encrypted under the (old) public encryption key of the subscriber by the same working symmetric- key re-encrypted under the new public encryption key of the subscriber. The processed KRF data shall then be transferred back to the subscriber. In this way, using its new private key, the subscriber will be able to decrypt its data as usual. All the policies, procedures, and tools for making these operations possible should be prepared in advance. 4.2.2.2. Key used to decrypt communications (Data-in-Transit) The corresponding certificate shall be revoked. A new key pair shall be generated and a new certificate shall be issued. 5. Certification Authority 5.1. Authority key-compromise At a first level of granularity the following Authorities need to be considered: Certification Authorities, Revocation Authorities, Attribute Authorities, and Time-Stamping Authorities. At a finer level of granularity, three kinds of Certification Authorities need to be detailed: - Root Certifications Authorities (Root CAs), - Intermediate Certifications Authorities (Intermediate CAs), - Leaf Certifications Authorities (Leaf CAs). Finally, three kinds of Revocation Authorities need to be detailed: - Authority Revocation Lists (ARLs), - Leaf Certificate Revocation Lists, and - Online Revocation Status authorities (OCSP). Pinkas et. al. Informational [Page 10] Internet-draft PKI Disaster recovery and key rollover June 2007 5.1.1. Root CA key-compromise A root key is a key from a CA ? a Root CA - that is directly trusted by some relying parties to issue certificates for some period of time and possibly under a stated certification policy and/or name constraints. A Root CA signs its own digital certificate, thus anchoring the ?root? of the top-entity's certificate chain. The self-signed certificate issued by a root CA specifies, the name of the trusted CA, the value of the public key and the associated algorithm and the validity period of that root key. The authority key identifier of the new self-signed certificate should either be the same as the previous one or should be omitted. If a root key is compromised, then it shall be changed and all relying parties using it should be informed using out-of-band communication methods. The new key may then be provided using various out-of-band communication methods, such as: - Publishing the hash of the new self-signed certificate and pushing or pulling the new self-signed certificate. - Providing a patch to the software application that makes use of that root key, so that the new root key is installed when installing the patch. The patch may be downloaded from a trusted server. - Providing a new version of the software application that makes use of that root key, so that the new root key is installed when installing the software. The new version may be downloaded from a trusted server or obtained from a trustworthy CD-ROM. A root key from a CA may also be trusted because it is part of a validation policy. See [RFC3379]. If one of the root keys recognized under that validation policy is compromised, then the validation policy shall be updated. Signature policies used in the context of non-repudiation is a special case of a validation policy. See [RFC3125]. All the certificates issued by the compromised Root CA must be re-issued. 5.1.2. Intermediate CA key-compromise 5.1.2.1. CA key-compromise during certificate life-time All certificates issued by the compromised Intermediate CA must be revoked. Since this CA's key is no longer trustworthy, this cannot be done by the CA itself, and must be done by the CAs that issued a CA certificate to the compromised Intermediate CA. Pinkas et. al. Informational [Page 11] Internet-draft PKI Disaster recovery and key rollover June 2007 All CAs which issued a CA certificate to the compromised CA must revoke such certificates. This implies that the operators of the compromised Intermediate CA must maintain good configuration management procedures so they are aware who to contact quickly to request revocation of the compromised CA's certificate. Revocation by the Issuing CAs will usually occur using ARLs (Authority Revocation Lists). All certificates issued by the compromised Intermediate CA are no longer valid, implying that new certificates must be issued to affected subscribers. If the number of currently valid certificates issued by the compromised CA is relatively small, e.g. 10.000, and depending on the Issuance practices adopted for such certificates, this may be done rapidly. However, if that number is large, e.g. 10 millions, without advance planning it may not be feasible to re-issue all certificates within a reasonable amount of time, even with simple issuance practices. For these reasons, it is necessary to establish a disaster recovery plan prepared in advance, so that CA operations staff may be ready to react promptly. The following plan is recommended: When establishing the PKI, the CA will generate two issuing key pairs: - a primary issuing key pair that will be used to issue certificates to the subscribers, - a backup issuing key pair that will only used to issue backup certificates for any certificate issued under the primary issuing key. These backup certificates will be released to subscribers in case of a compromise of the primary issuing key. The backup issuing public key will NOT be divulged to the public or subscribers unless the primary issuing key is compromised. Consequently, a brute force attack to compromise the backup key pair cannot be attempted before the existence of the backup public key value is divulged. Should the primary issuing private key be compromised then the public key part of the backup key pair is presented to its issuing CAs so it can be certified by them. The validity period of each new Intermediate CA certificate for the backup signing keys will be established as follows: - the start of the validity period will be the current date of issuance of the new Intermediate CA certificate, - the end of the validity period will be the original end of the validity period of the original Intermediate CA certificate. Pinkas et. al. Informational [Page 12] Internet-draft PKI Disaster recovery and key rollover June 2007 Note that longer dates would be possible, but a detailed analysis of the validity period of the upper CA certificates would be required, which may not be appropriate in an emergency situation. It should be noted that even if the primary issuing private key is compromised and the certificates issued to subscribers are too, the private keys of the subscribers are not compromised. Subscribers? backup certificates signed with the secondary CA key will be escrowed in a repository under the sole control of the CA and are not made available to anyone unless the primary issuing private key is deemed compromised. It should be noted that these escrowed certificates are useless until the validation path (which has an open end) is linked to complete the certificate path. If the primary issuing private key is compromised then the secondary (backup) CA will be certified, its certificate placed online and made accessible to the public. Subscribers will, typically, not be aware of the revocation of the of their CA, unless they get complaints from relying parties. CA operators should use information obtained at the time of registration to contact them promptly (e.g. an e-mail address or a phone number). In addition, subscribers should be informed, at the time of registration of the procedure that will be used in case of an emergency situation, in particular the means to be used to obtain the new certificate, e.g. an HTTPS address, or a piece of software delivered at the time of registration. When the subscriber is part of an organisation in direct contact with the CA, the organisation may directly inform the employees of that organisation using electronic means such as a workstation management software Either by connecting to a server (using HTTPS or SSL) or using a dedicated piece of software made available in advance, the subscriber will use a protocol which basically performs the following exchanges: 1. a signed request identifies the serial number(s) of the certificate(s) that the subscriber is willing to retrieve. These certificates may be used for authentication purposes, signature purposes or encryption purposes. This request will be signed using the private key of an authentication or a signature certificate (which is still valid for the issuing CA only). The reference of this authentication or signature certificate will be included in the signed request. Pinkas et. al. Informational [Page 13] Internet-draft PKI Disaster recovery and key rollover June 2007 2. a server in charge of exercising access control on the certificate repository will use the reference of the authentication certificate or of the signature certificate included in the request to identify the subscriber and then will verify the digital signature using the current authentication or signature certificate. If the signature is correct, then the backup certificates referenced in the request and stored in the repository will be released. 3. in addition, new CA certificates that have been created by other CAs, may also be released to the subscriber. The client software may then update the certificates. The access to the repository containing the backup certificates should remain open during some reasonable period of time, e.g., one month. It is expected that it will be heavily accessed close to the time of compromise of the primary issuing key. For that reason, it is recommended to duplicate the content of the repository on multiple servers and to identify the various points of access. When the subscriber is using a smart card that contains his certificates, then he should be able to replace the current certificates by the new certificates without the need to change the private keys. If certificate chains are also supported, the upper certificate should be changed as well. Relying parties will, typically, not be aware of the revocation of an Intermediate CA certificate, until they attempt to validate a certificate of a subscriber in the context of some business transaction. The validation process using the certificate chain that includes the compromised Intermediate CA certificate will result in failure due to the revocation status of the compromised CA. As soon as the operator of the compromised CA will have executed the recovery plan, the situation will become normal again. 5.1.2.2. CA key-compromise beyond certificate life-time Since revocation information is not honored by CAs nor posted beyond the first CRL after the end of the validity period of a certificate, it will be necessary to prove that the certificate was issued before the end of the validity period of the CA certificate. This could be provided using an individual time-stamp over every certificate. However, current Internet protocols, whether there are infrastructure protocols or application protocols, have not been designed to be able to handle time-stamped certificates. Therefore this solution would require major changes to these protocols. Pinkas et. al. Informational [Page 14] Internet-draft PKI Disaster recovery and key rollover June 2007 Instead of time-stamping every certificate, the same benefit can be obtained by using a single time-stamp over the certification path (and the associated revocation information) obtained at the time of initial verification, i.e. while all the certificates from the certification path are still valid. This solution has been chosen in the Electronic Signature Formats for long term electronic signatures (see [ES-F]), where both the certification path and the associated revocation information may be protected under a single time-stamp using an additional unsigned attributed in the CMS structure (see [CMS]). 5.2. CA key-loss A CA key may be lost as the result of a hardware failure or an unsuccessful attack on the cryptographic module holding the issuing key (which may have zeroized its contents as a result). If the lost CA key is a root key, it is important that staff reloads the same CA key-pair from their backup. If the lost CA key is that of an Intermediate or a Leaf CA, the key could technically be superseded with a new key-pair. However, it is recommended that the same key-pair be reinstated to avoid the lookup of a new CA certificate and the revocation status of the earlier certificate. A backup cryptographic module may also be necessary in case the cryptographic module is damaged after a physical attack. While implementation details will vary amongst cryptographic module vendors, the staff in PKI Operations shall ensure that the backup key is not, activated, available, or accessible on the backup module until and unless it is necessary. No single individual should ever has full control of the CA's private key. The key protection may be implemented with M of N control over the key. 5.3. Key rollover According to [PKIX-1], a certificate is valid only if it is within the validity period of all the CA certificates within its certificate chain. In order to avoid a synchronous change to all certificates within a certificate chain, when the root key expires, it is recommended to generate a new key pair and issue a new self-signed certificate before the end of the validity period of the current Root CA certificate. 5.3.1. For Root CA keys If a certificate issued by a trust anchor is supposed to have a validity of X years, then it is necessary to issue a new self-signed certificate at least X years before the current self-signed Pinkas et. al. Informational [Page 15] Internet-draft PKI Disaster recovery and key rollover June 2007 certificate expires, otherwise the issued certificate would have a life time shorter than X years. This means that root key self-signed certificates should have overlapping validity periods. A consequence of this strategy is that, at any given time, two root public keys will be usable by a relying party to verify a certificate from a given CA. The installation of the new root key may be done using [CMP]. See section 2.4 Root CA key update. The NewWithOld and NewWithNew certificates will be used. If the root CA issues itself the CRLs, then two CRLs should be maintained: the first one for the certificates issued under the old key and the second one for the certificates issued under the new key. 5.3.2. For intermediate keys If a certificate issued by an intermediate CA is supposed to have a validity of Y years, then it is necessary to issue a new certificate at least Y years before the current certificate expires, otherwise the issued certificate would have a life time shorter than Y years. This means that a new issuing key should be used to issue new certificates. If the CA issues itself the CRLs, then two CRLs should be maintained: the first one for the certificates issued under the old key and the second one for the certificates issued under the new key. 5.3.3. For leaf keys Confidentiality keys and encryption keys may be used up to the very end of the validity period of the corresponding certificate. However, this should not be the case for non repudiation keys, since a relying party might wait a few days (or even weeks) before verifying an electronic signature. For this reason it is recommended to issue a new non repudiation key (signature key) about one month before the end of the validity period of the current certificate, and ask the signer to use the new key rather the current key. 6. Revocation Authority 6.1. Revocation Authority key-compromise within certificate life-time A CA has two ways to advertise revocations: using CRLs or using OCSP responders (see [OCSP]). Pinkas et. al. Informational [Page 16] Internet-draft PKI Disaster recovery and key rollover June 2007 In a closed environment, it is possible to configure client software with responder information. This not only allows the requester to trust the responder, but also to know from where to fetch revocation information. In an open environment, the CA typically indicates in each certificate which revocation status mechanism is supported (i.e. CRLs or OCSP) and designates the authorities responsible for handling revocation status information. A CA may choose either mechanism or both mechanisms to publish revocation information by using either: - a CRLDistributionPoint extension for CRLs, or - an AccessInformationAuthority extension for OCSP. In an open environment, the CA may nominate Revocation Authorities by issuing certificates to them. Should the private key of such Revocation Authorities itself be compromised, it would be necessary for the Issuing CA to revoke the signing key certificate of such revocation authorities. This may be achieved using ARLs (Authority Revocation Lists) or using OCSP. When using ARLs, the ARLs must be signed with the CA?s issuing key. CRLs containing only leaf certificates may be signed by one or more CRL Issuers whose certificate was issued by the CA. When using OCSP, the responses for the revocation status of Authorities are usually signed by the CA issuing key. However, OCSP responses for leaf certificates may be issued by a Designated Responder (Authorized Responder), which holds a specially marked certificate, issued directly by the Issuing CA, indicating that the subject responder may issue OCSP responses for that CA. In practice, different AccessInformationAuthority extensions should be used for Authority certificates and leaf certificates. 6.2. CRL Issuer key-compromise within certificate life-time Should the CRL Issuer's signing key be compromised, then either the corresponding certificate shall be added to the ARL, or OCSP responses signed directly by the CA shall be used to provide revocation status for the CRL Issuer's certificate. 6.3. OCSP responder key-compromise within certificate life-time Should the signing key from an OCSP responder (providing revocation status information for leaf certificates or attribute certificates) be compromised, either the corresponding certificate shall be added to the ARL or OCSP responses signed directly by the CA shall be used. Pinkas et. al. Informational [Page 17] Internet-draft PKI Disaster recovery and key rollover June 2007 6.4. Revocation Authority key-compromise beyond certificate life-time In the same way as for leaf certificates, since revocation information for Authorities is not honored by CAs nor posted beyond the end of the validity of a certificate, it will be necessary to prove that the certificate was issued before the end of the validity period of the certificate. 6.5. Revocation Authority key-loss Should a Revocation Authority key (i.e. a CRL Issuer key) be lost but NOT compromised, then a backup copy of the key may be installed if one exists. Otherwise, the corresponding certificate shall be revoked. A new key pair may be generated and a new certificate may be issued if the PKI operators choose to replace the revocation authority. 7. Attribute Authorities 7.1. Attribute certificate revocation In many environments, the validity period of an Attribute Certificate (AC) is less than the time required to issue and distribute revocation information. Therefore, short-lived ACs typically do not require revocation support and may be marked as such, using the noRevAvail extension (see [AC]). However, long-lived ACs and environments where ACs enable high value transactions will require revocation support. Such ACs do not contain the noRevAvail extension and, if used in an open environment, shall include either an authorityInfoAccess extension or a crlDistributionPoints extension. If used in a closed environment, it is possible to configure the clients so that they directly trust a Trusted Responder whose public key is trusted by the requester but also so that they know where to fetch the revocation information. Should an AC needed to be revoked then either the corresponding attribute certificate identifier shall be added to a CRL from the CRL Issuer nominated by the AC (using the crlDistributionPoints extension) or a OCSP server nominated by the AC (using the authorityInfoAccess extension) shall be used. 7.2. Attribute Authority Key compromise Attribute certificates are signed by indicating either the name of a CA (using GeneralNames for v1 or v2 ACs) or a certificate serial number from a CA (using baseCertificateID for v2 ACs). That information is part of the AttCertIssuer field. Pinkas et. al. Informational [Page 18] Internet-draft PKI Disaster recovery and key rollover June 2007 Attribute Authorities may either be directly trusted by a verifier or be indirectly trusted because part of a trusted certification path. In the first case, verifiers directly know the name and public key from the AA and shall be informed from the revocation conditions using out-of-bands means. In the later case, Attributes Authorities obtain a certificate from a CA. When using GeneralNames, the name(s) of the CA(s) that is (are) trusted to issue a certificate to that AA is left undefined and has to be defined locally using out-of-bands means. In that case, the CA that has been locally defined shall revoke the AA using either an ARL or an OCSP responder. When using baseCertificateID, the CA that is allowed to issue a certificate to that AA and thus also able to revoke that certificate is explicitly indicated in IssuerSerial. In that case, the CA shall revoke the AA using either an ARL or an OCSP responder. When verifying the certification path, verifiers will be automatically notified of the revocation condition. Thereafter a new certificate with a new private key shall be issued for the Attribute Authority. 7.3. Attribute Authority Key loss Should a Attribute Authority Key (i.e. a AC Issuing key) be lost, then if there is a back-up copy of the key, that back-up copy should be installed. Otherwise, the corresponding certificate shall be revoked. Then a new key pair shall be generated and a new certificate shall be issued. 8. Time-Stamping Unit keys The public key of a TSU (Time-Stamping Unit) is trusted because the certificate from the TSU is part of a certification path trusted for that purpose. This certificate may be issued by a trusted CA that only issues TSU certificates or may be part on a broader certification forest. Once it has been verified that the key generation process has been followed correctly, then the public key shall be exported from the hardware module to be certified by a CA. 8.1. Time-Stamping Unit Key loss Should the private key inside a TSU hardware module be destroyed (e.g. as the result of tampering or a hardware failure), then the TSU hardware module should be replaced by a spare one. Pinkas et. al. Informational [Page 19] Internet-draft PKI Disaster recovery and key rollover June 2007 The use of a back-up key is deprecated because, this there is a risk that the back-up key could be installed in a new module, but initialized with an incorrect time. It is recommended to synchronize the reference clock with UTC, generate a new key pair on the TSU module itself, certify the new public key and finally install the new certificate in the TSU module. This operation shall be done at least under dual control. Since this may take some time, it is also recommended to use two TSUs. While one TSU is being fixed, the other TSU can handle the service. Each TSU should be dimensioned to reach the global performances awaited from the system. The TSU module should be unable to import and export of any private key. In this way no private key ever exists outside the security module and therefore cannot be compromised. 8.2. Time-Stamping Unit Key compromise 8.2.1. Compromise during the validity period of the TSU certificate Should such a condition occur, then the TSU certificate shall be revoked and a new certificate shall be issued. However all the time-stamps that have been issued by the TSU become invalid, whatever their issuing date. If an additional time-stamp has been applied, because the validity of the TSA certificate was near its expiration, then this time-stamp provides the protection; provided that in addition it can be proven that the TSA key was not compromised when the additional time-stamp was applied. 8.2.1.1. Checking during the validity period of the TSU certificate In order to make sure, during the validity period of the TSU certificate, that a time-stamp token is indeed valid, the revocation status information at the time of the verification (i.e., at the current time) shall be fetched, which means that the revocation status information obtained at the time the time-stamp was generated is not sufficient. In the case of a key-compromise, any time-stamp issued under a compromised key brings no proof anymore. In order to be prepared for such a situation, relying parties should be advised, for critical situations, to get two time-stamps, instead of one, from two different TSUs, either in parallel or embedded; in the later case, the second time-stamp token is protecting the first one. Pinkas et. al. Informational [Page 20] Internet-draft PKI Disaster recovery and key rollover June 2007 8.2.1.2. Checking beyond the validity period of the TSU certificate Usually, a time-stamp token becomes unverifiable beyond the end of the validity period of the certificate from the TSU, because the CA that has issued the certificate is no more recording key revocations, including key-compromises for expired certificates. There are two ways to address this issue: 1 - capture the current CRL applicable for the TSU and verify that the serial number of the TSU certificate is not present, and then apply an additional time-stamp token from a different TSU over the previous one. This will demonstrate that the key of the TSU was not compromised at the time the new time-stamp token was applied. 2 - rely on a specific time-stamping policy, which mandates a specific design of the TSUs and appropriate procedures to handle the TSUs: - the TSU key pair shall only be generated by the TSU. The export and the import of TSU private keys shall be forbidden. In this way, no copy of the private may ever exist outside the TSU. - the TSU private key shall be zeroized in case of an attempt to attack the physical enclosure of the TSU. - the TSU private key shall be zeroized at the end of the private key usage. - the TSU certificate shall only be generated once the key pair has been generated on the TSU and security officers have verified that the TSU is in synchronization with UTC. In that case, it is first necessary to capture any CRL applicable to the TSU between the end of the validity period of the TSU private key and the end of the validity period of the TSU certificate and verify that the serial number of the TSU certificate is not present. This will demonstrate that the TSU certificate was not revoked before the TSU private key was zeroﺥd. It is then necessary to make sure that the hash algorithms used in the time-stamp token exhibits no collisions, and that the key size of the signature algorithm under which the time-stamp token has been signed is still beyond the reach of cryptographic attacks. If both conditions are met, then the time-stamp token is valid. Pinkas et. al. Informational [Page 21] Internet-draft PKI Disaster recovery and key rollover June 2007 8.2.2. Compromise after the end of the validity period of the TSU certificate This case may happen if the key length originally used by the TSU is no more beyond attack. Before such a situation happens, an additional time-stamp token shall be applied to protect the previous time-stamp token. 9. CRL Repositories CRL Repositories may be subject to denial of service attacks. It is extremely difficult to guard against all types of denial of service attacks. Additionally, repositories may become inaccessible due to hardware or software failures. Replication of a repository on multiple servers may provide increased availability, in particular when combined with network controls capable of detecting abnormal numbers of requests and to throttle them while allowing other requests to be serviced. Since PKI-related repositories typically contain only digitally signed information (Certificates, CRLs, ARLs) they are susceptible -at worst- only to denial of service attacks. However some denial of service attacks on CRLs may lead to unexpected results and security problems, as it will now be explained. It is a common practice that many CAs issue "emergency CRLs" as soon as the PKI operators become aware of, or are notified of a key compromise. However, there is no guarantee that this emergency CRL will ever be seen by a relying party for two reasons: a) If a relying party has a currently valid CRL (where the current time is less than the nextUpdate field from that valid CRL), then most validation policies do not require to check for most recent CRL. b) Even if a relying party periodically checks for a new CRL then it is possible to mount a denial of service attack on the CRL distribution point(s) of the Issuing CA, thereby preventing the emergency CRL from being retrieved. In this case, the RP will see only the CRL in its cache, if one exists. Even such a guarantee cannot be obtained, it is recommended to adopt the following strategy: whenever a CRL is needed, look for it in a cache : - if not present, fetch the CRL as usual and place it in the cache with the time when it was fetched, and use it, - if present, look for the time when it was fetched, and use it if it was fetched earlier than x minutes, otherwise, look for a new CRL, and use it. Pinkas et. al. Informational [Page 22] Internet-draft PKI Disaster recovery and key rollover June 2007 10. Security considerations This document is all about security. 11. Acknowledgments Special thanks are due to Ernst Giessman from T-Nova for his valuable inputs and support and to Arshad Noor from StrongAuth, Inc for his review and comments on the initial draft. 12. IANA Considerations No action by IANA is necessary for this document or any anticipated updates. 13. References [PKIX-1] Internet X.509 Public Key Infrastructure. Certificate and CRL Profile. RFC 3280 R. Housley, W. Ford, W. Polk, D. Solo. [OCSP] X.509 Internet Public Key Infrastructure. Online Certificate Status Protocol ? OCSP. RFC 2560 M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. [AC] An Internet Attribute Certificate Profile for Authorization S. Farrell, R. Housley. RFC 3281. [TSP] Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161. C. Adams, P. Cain, D. Pinkas, R. Zuccherato. [ES-F] Electronic Signature Formats for long term electronic signatures D. Pinkas, J. Ross, N. Pope. RFC 3126. [CMS] Cryptographic Message Syntax. RFC 3852. R. Housley July 2004. Pinkas et. al. Informational [Page 23] Internet-draft PKI Disaster recovery and key rollover June 2007 [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. 14. Authors' addresses Denis Pinkas Bull SAS. Rue Jean-Jaures 78340 Les Clayes sous bois CEDEX FRANCE e-mail: Denis.Pinkas@bull.net Joel Kazin Jefferson Wells Penthouse 99 Park Avenue New York, New York 10016 USA e-mail: Joel_Kazin@jeffersonwells.com 15. Full Copyright Statement Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Pinkas et. al. Informational [Page 24] Internet-draft PKI Disaster recovery and key rollover June 2007 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Pinkas et. al. Informational [Page 25]