Certificate Revocation


Certificate is used to bind subject dn to their corresponding public key

Binding might become invalid when an issued certificate is no longer valid (key compromise, etc)

The frequency with which revocation information is updated and posted is an extremely important consideration

Revocation delay is defined as the delay between the knowledge that the certificate should be revoked and the actual posting of the revocation information

Two common methods are Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP)


Pre-publication techniques includes

Complete Certificate Revocation List (CRL)

Authority Revocation Lists (ARL)

CRL Distribution Points (aka Partioned CRLs)

Delta CRLs

Indirect CRLs

Enhanced CRL Distribution Points and Redirect CRLs

Certificate Revocation Tree (CRTs)



Signed data structures that contains a list of revoked certificates

Integrity and authenticity provided by digital signature appended to CRL

Signer of CRL might be the same as the certificate issuer

CRL can be cached


CRL v1 is widely used

But, scalability is an issue, since v1 crl could glow very big

Limitation of extending v1 crl

crl substitution attack could be done with v1 crl

v2 crl solves these problem by introducing the notion of extensions (compared with v3 x509 certificate)

A critical extension should be processed, and understood by related parties.

Non-critical extensions could be ignored


Version 2 CRL structure

The whole crl is signed by Authorized Issuer (CA in most of the case)

Version (identify the crl version, v2)

Signature (Algorithm ID used to sign the crl, Message Digest 5 hash with RSA encryption)

Issuer (Unique name of the crl issuer, the dn, cn=xxx,o=...)

This Update (Date/Time this CRL was issued, UTC or generalized time)

Next Update (Date/Time this CRL expires)

List of revoked certificates (Certificate serial number, revocation date/time, and crl entry extensions (optional))

Extensions (Per CRL extensions available with v2 crls)



Per-entry extensions vs Per-CRL extensions

Per-entry extensions

Reason code - reason of revocation: CA compromis, affiliation change, superseded, cessation of operations, certificate hold, remove from CRL, and unspecified

Certificate issuer - dn of the certificate issuer, only required for indirect crl

Hold instruction code - userd to support the temporary suspension of a certificate. Could be reinstated or permanently revoked later on. (No implementation at this point)

Invalidity date - The known (or suspected) time that the certificate was no longer considered valid


Per-crl extensions

Authority Key identifier - unique identifier of the key that will be used to verify the digital signature calculated over the CRL. Used because multiple keys might exist for the crl issuer during CA key rollover.

Issuer alternative name - alternative name to id the issuer, could be ip address, dns name, rfc-822 email address, etc.)

CRL number - unique serial number relative to the issuer for this crl. Monotonically (increase by one everytime), allows the detection of missing CRLs

Issuing distribution point - indicates name of crl DP (if any) and the types of certificates (end-user only, ca only, and/or certs revoked for this reason only). Also indicates if crl is indirect or not.

Delta crl indicator - indicates if this crl is delta crl or base crl



Private extensions could be defined for domain specific use. As recommended by rfc2459, private extension should not be marked as critical unless absolutely essential

Only reference of revoked certificates (serial number) are included. Expired revoked cert will not be included in subsequently issued crls. Revoked cert, however, appears on at least one crl


Complete CRLs

Complete CRLs of all revoked certificate in a domain

Concern of issue of scalability (becomes too big)

Concern of timeliness of the posted certificate revocation information

(download of new voluminous crls lead to unacceptable performance degradation)


Authority Revocation Lists (ARL)

A crl devoted exclusively to revocation information with CAs, built by using issuing dp extension

Use to revoke public key of ca certificates

Used by superior (vs subordinate) ca, or cross-certificed ca



Distribution Points (or Partitioned CRLs) allow revocation information within a single CA domain to be posted in multiple CRLs

Large crl data could be partitioned into more manageable pieces

Certificate can point to the location of the crl, no need to know where a crl is before hand (CRL partitions in this case is fixed or static ... what do we do?)


Enhanced CRL distribution points and redirect CRLs

CRL partition in dp is static, ca has a prior knowledge regarding how the crl information should be partitioned, and partitioning cannot change over time.

Partitioning could be based on cert serial number range, revocation reason, cert types, etc, need a flexible way of making the cut


Redirect CRLs

Redirect crls can be used to indicate where each crl partition can be found

(based on existing standards and protocols)

A single redirect crl can be used to point ot multiple crls

Think of it as an array of pointer

Certificate with crl dp extension ---> redirect crl with scope statement extension ---> crl partition with crl and revoked certificates

crl scope extension syntax is similar to the existing issuing distribution point extension syntax, addition includes name of ca, ranges of serial number, subtree name constraint, etc.


Delta CRLs

"Changed only" crl

Enhance timeliness without significantly impacting performance Incremental postings of certificate revocation information (without complete generation of full crl)

Does not eliminated full crl posting

Based on some previously posted revocation information

Smaller delta crl could be distributed easier

(Could post multiple delta crl against the same base crl, only the latest delta crl is needed to check revocation information)


Indirect crl

Used when multiple CAs support revocation information

No need to retrieve multiple crls

One indirect crl would be square

(In real implementation, the usage is wrapped with api)


Certificate Revocation Tree (CRT)

Valicert invented crt Based on merkle has trees

Tree contains certificate revocation information

Represent large amount of revocation information in a very efficient manner

CRT will be on the order of Log N where N is the number of revoked certificates Delta could be used with full crl posting, crl distribution point.