Internet DRAFT - draft-pinkas-pkix-pki-drkr
draft-pinkas-pkix-pki-drkr
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
<draft-pinkas-pkix-pki-dr&kr-00.txt>
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]
