Agility Loop

The Certificate Revocation List Distribution Point (CRLDP or CDP) is the attribute in a PKI certificate that tells a relying party where to retrieve the signed binary file that contains a list of revoked certificates (there are other reason codes that can be used, be most clients essentially still interpret those certificates as revoked).  This file is generated by the Certificate Authority (CA) on a regular basis.  This is one way that applications and systems can verify the revocation status of a certificate (there are other methods as well). The challenge associated with CRLs, and the CRLDP for that matter, is getting those files down to each relying party.  This is mainly a problem is larger PKIs.  In smaller PKIs, the CRLs are small enough that clients and server shouldn't have too much trouble downloading the files (although some CRL retrieval implementations are very brittle).  For larger PKIs, this becomes more and more of problem as the PKI grows.  The CRL files get larger, and since each CA issues a CRL and larger PKIs may have multiple CAs, there may be multiple files to contend with.  As your users use your PKI more, more relying parties have to verify those certificates.  The bandwidth demands can grow exponentially, stressing your infrastructure and potentially preventing some relying parties from actually retrieving the information. Early on in PKI, LDAP was used for many CRLDPs.  However, LDAP is actually blocked at some firewalls.  In addition, as LDAP is an older protocol, it doesn't offer you the same advantages as using a HTTP reference.  By using HTTP in the CRLDP, you can take full advantage of HTTP 1.1 enhancements like resumption and compression. However, one must be cautious to not get too fancy on how they actually serve the CRL content.  Most PKI implementations on the relying party side are fairly simple.  There is typically no user interaction when retrieving the CRL...it happens in the background. In my experience, it is best to take advantage of what web servers do best...serve static content.  It is tempting to make use of scripts or applets in serving CRLs.  One not make the reference a "dynamic" URL that includes the passing of a parameter to Java App?  That is certainly an option, but I truly believe that in PKI where you can make it simple, keep it simple. In addition, many web proxies will actually not be able to cache this content without manual intervention (although to be fair, many PKI implementations use http conventions like pragma: no cache to force the retrieval of the freshest CRL). So instead of http://pki.company.com/crlscript?CA11, use http://pki.company.com/crls/CA11.crl.  Local users and networks can then easily replicate this directory through mirroring using standard scripts, FTP clients, and/ordownload managers.  By locally caching the content, the Infrastructure piece of your PKI will incur less bandwidth stress and you'll have less headaches.