On 2009.10.13 at 18:20:12 +0200, Dr. Stephen Henson wrote: > > There is some additional logic for CRLs though. In by_dir.c it stores the last > suffix value of a CRL so if you have CRL links:
This logic have to be clearly documented in the X509_LOOKUP_hash_dir manual page. I'd write what I've learned from this letter, but I hope, you'll read and improve it. Because it is critically important information for utilities which update hashed directory - that new CRL should be added, rather than replace outdating ones. Of course, keeping history in the hashed directory makes some sense. > It notes that "r3" is the last CRL looked up if now a new one is added: > > 12345678.r4 > > it only looks for r4 and doesn't reload all the (potentially large) previous > CRLs. The logic is that CRLs change far more regularly than certificates. > > Though in certificates the likelihood of matching hash values is far less. This is place I've not got complete understanding from the code reading. In our case we need to perform root certificate rollover each year. But I'm not sure yet, that if new root certificate would be issued with same DN (but, of course, different subjectKeyIdentifier) certificate chains would be constructed properly. Idea is that root certificate is issued with validity period of two years, but is changed year after. And client certificates are issued with validity period 1 year. So root certificate expires same day as last certificate possible signed by it is expired. Of course, it is possible to add something to DN of new root certificate, such as serialNumber or UID, and increment this field each time new certificate is issued. I also have an idea of issuing certificate for old CA key signed by new CA key, so new client which joined system after rollover have to manually install only one, current, CA certificate (manually install means - compare fingerprint with some printed document), and older certificates are verified with chain of length 2. But this is just marginal usablity improvement. So, if chain of two certificates with identical DN cannot be built, it is not a big problem. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
