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)
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
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
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
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
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 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)
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?)
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 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.
"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)
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)
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.