Question

(a)Public key infrastructures employ certificate revocation mechanism using certificate revocation lists (CRLs). In presence of CRLs, why do we include expiration dates in certificates? Envision two advantages of including expiration dates in certificates.

(b)Every CA must reissue its CRL periodically. It is true even when no new certificates have been revoked after the previous issue CRL has been published. Why? Suggest a possible attack if CRLs are not issued periodically.

Answer 1

Answer:

The official reason why certificates expire is because of revocation. A certificate is "revoked" when its issuer asserts that the certificate contents are no longer to be trusted, for some reason which needs not me specified. It is like a "cancel" from the CA: the CA signed the certificate, but now regrets it.

A common reason for revocation is when the private key is suspected to have been stolen (e.g. a smart card was lost, so it might be in the wrong hands).

Revocation works by adding the certificate serial number in the Certificate Revocation Lists that the CA publishes regularly. These CRL are signed (usually by the CA) and people who use certificates (e.g. Web browsers, for SSL server certificates) are supposed to automatically download the newest CRL to see whether the certificate they are about to use has been revoked or not.

Without expiration dates, CRL would grow indefinitely, and become too bulky for usage. With expiration, certificates which are expired are removed from the CRL; in that sense, certificate revocation behaves like an hastened expiry. So there you have it: certificates expire to keep CRL small.

(If certificates were very short-lived, and renewed every week or even every day, then we could get away with no revocation support at all, which would be cool)

Advantages:

* Digital certificates are used to verify identities and affiliations online. People change jobs, students graduate, businesses fail or change ownership, private keys get leaked, and any number of other things may happen that would cause a particular certificate to stop being an accurate way to verify an identity. Certificates expire so that people using them can be sure that the information in them is at least somewhat up to date.

* Without expiration dates, CRL would grow indefinitely, and become too bulky for usage. With expiration, certificates which are expired are removed from the CRL; in that sense, certificate revocation behaves like an hastened expiry. So there you have it: certificates expire to keep CRL small.

Answer : There are three types of attacks that are based on the manipulation of certificate revocation reason codes.The first two cases involve attackers confusing relying parties by tricking certification authorities into providing the wrong reason code when revoking a certificate. In the final case, the attacker’s manipulation of the reason codes leads to a delay in the dissemination of revocation information. While some standards, such as X.509, specify a set of reason codes to be used when revoking certificates, we will not assume the use of any particular set of reason codes in this paper. Instead, we will group reason codes as necessary to describe the attacks. A certificate can be revoked either for a benign reason (e.g., it is no longer needed) or because there is concern that the corresponding private key will be misused (e.g., key compromise). In this paper, we will use Benign to refer to any code that implies a benign reason for revoking a certificate and Malicious to refer to any code that could imply concern that the certificate will be misused. It should be noted, however, that, in practice, partitioning revocation reasons into those that are Benign and those that are Malicious might not be a simple matter. Looking at the X.509 reason codes, it is clear that key Compromise and cACompromise should be classified as Malicious. However, if the reason for revoking a certificate is affiliation Changed, the situation may not be as clear. If a subscriber’s affiliation change is a result of being fired, then there is the chance that the subscriber will attempt to use his/her private key (until the revocation information is distributed) to cause damage to his/her former employer. On the other hand, most of the time when an employee changes jobs (whether within a company or by moving to another company) there is no cause for concern. From a security point of view, however, it may be prudent to treat affiliation Changed revocations as Malicious. Similarly, prudence may require treating unspecified and certificate Hold as Malicious given the lack of information about the reason for the revocation. The Malicious reason codes can be separated into those that allow for repudiation of past actions and those that do not. Revocation reasons such as key Compromise and Compromise suggest that the subscriber may not be responsible for some of the messages signed in his/her name, particularly those signed shortly before the certificate was revoked. Other reason codes that could be classified as Malicious, such as affiliation Changed, are classified as Malicious to imply that the subscriber may attempt to request services that he/she is no longer authorized to request. This would not, however, suggest that someone other than the subscriber was signing the messages. In this paper, we will use Repudiable to refer to reason codes which suggest that someone other than the subscriber may have signed messages using the private key associated with the revoked certificate, and NonRepudiable to refer to all other reason codes