Well, here's the overview: The CRL is a mechanism used by the attesting entity (the CA) to change the validity status of a previously-issued certificate (digitally-provable statement of authority by a particular named entity, i.e. the CA).
The certificate, which is best viewed as a record of the act of certifying, is a mathematically-hard transformation of the output of a (universally) lossy compression algorithm over a particular form and style of data structure, and the data structure itself. The function of the data structure is to assert the ownership of a secret number, as witnessed by the ability to perform transformations with the counterpart public number which is included in the data structure. The purpose is to "strongly bind" the legal identity of the entity applying for the certificate and the public half of an asymmetric keypair (the private key of which is kept private, but evidence of its possession and ability to perform the trapdoor operation is provided). In order to create this, under X.509 there must be a trusted entity (the certifier) whose credential is predistributed in some manner to all systems that will need to rely on the identity claims it makes. (X.509 is limited in two fatal (in my opinion) ways: First, everything is reliant on the Distinguished Name... which isn't distinguished enough to individually distinguish between all entities. Attributes are asserted as relating to a particular DN, not a particular key. Second, it relies on the concept of a single attestor, a single Source of Authority -- when nothing in the Real World can rely upon any single identity document to open an account, it's ludicrous to believe that banks or merchants would accept the single word of a CA as to the identity provided. This causes problems not only for the customer side, but also for the business side: if the Authority that the business chooses to attest to its identity suddenly becomes untrusted, then there is no help but a manual intervention that involves an entire assurance of identity with another CA. No wonder most places choose to go with domain-validated certificates. :( ) To generate keys and obtain certificates, every browser except IE appears to support the old Netscape <keygen> HTML tag, which creates and puts into a form submission what's called a SPKAC (Signed Public Key And Challenge) to the CA, and the CA may either return a signed certificate immediately, turn down the submission immediately, or hold the submission for manual intervention. The CA is *solely* responsible for what shows up in the certificate. (Best current practice seems to be, the CA drops everything that comes in the same structure (SPKAC or CSR), and generates its own data structure with what it knows to be true, and taking only your public key from the structure you submit after verifying the signature. These certificates have an expiration date, after which they are no longer useful. (i.e., the CA's policy may say something like "the private key to any certified public key cannot be in use for more than 24 months before being retired, because we won't accept the risk of it being completely fatigued after that time".) The CRL is one of two standardized mechanisms that the CA has to promulgate the fact that a certificate's status is in abeyance. (The other is OCSP.) For this to work, the end system must update its local copy of the CRL before it can put any trust in it. It is important to note that OpenSSL does not provide a means to *retrieve* CRLs (it doesn't have an HTTP client implementation), but it does provide a mechanism to *use* CRLs that have already been retrieved. (Usually, I use 'curl' or 'wget' to retrieve CRLs that I need to verify against in scripts.) Notably, the name "Certificate Revocation List" is a bit of a misnomer. It is legitimate for a CA to put a certificate in abeyance, and then at some later point decide that the certificate is actually valid and remove the certificate in question from the CRL, thus indicating that the certificate is in fact good. It's more of a "Certificate Status List". (This is at least partly because of necessity -- the EU's Qualified Certificates are invalid until they are "accepted by the subscriber". Thus, the Partial CRL profile has a specific bit named: "removeFromCrl". For a good place to learn more about how this is supposed to work, I would recommend reading RFC 5280 (OpenSSL doesn't claim conformance to this version, but it's the latest standard for the Internet PKI and explains what the various standardized certifiate extensions mean, as well as describing the CRL processing algorithm). For a very good place to learn about how to implement this with OpenSSL, I would recommend Carillon's excellent "How to set up an OpenSSL TEST CA for interoperability with CertiPath" document, available at http://www.carillon.ca/library/openssl_testca_howto_1.3.pdf . Also, it's a bit dated, but _Network Security with OpenSSL_ by John Viega, Matt Messier, and Pravir Chandra (O'Reilly and Associates 2002) is still a good reference. There are some very deep flaws in how the revocation processing is handled according to the RFC, most notably that the CRL location is in the end-entity certificate, not in the CA certificate. If a valid X.509-formatted 2nd preimage can be found that has the same hash as the valid certificate, and the signature on the valid one then applied to the invalid one, the signature will verify on the alternative content. This means that certificate processing *must* be hardened against content-based attacks, because it only takes one failure to compromise the system. (The MD5 hash algorithm was found to be weak enough that such an attack was successfully mounted in 2009. This isn't idle and paranoid speculation, this is a known and demonstrated weakness.) I hope this helps! -Kyle H On Fri, Sep 24, 2010 at 1:13 PM, Hasan Rezaul-CHR010 <chr...@motorola.com> wrote: > Hi All, > > Would anyone kindly point me to literature that CLEARLY explains exactly > how: > > Certificates and CRLs may be used in conjunction such that certificate > CSRs are generated, signed by an authority, then signed certs downloaded > and being used on a system. > > At a later time, the certificate is revoked in the CRL, the CRL.pem file > is downloaded on the system, and then the corresponding cert becomes > unusable due to its mention in the CRL. > > Is there a good place for me to educate myself on this whole mechanism, > and a place where it shows exactly how to implement all this with > examples... Oh I am running on Linux, with openssl 0.9.8g. > > Thanks a bunch in advance. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
