Andreas Jaekel queried:
Wouldn't it be CA- and config specific how to implement revocation lists? Maybe dovecot wants to do real time checks via LDAP and use an internal cache with weekly updates. A cron job would be easiest, thought, and the fastest way to get there.
this is one of those cases where theory and practice in certificates collide rather unpleasantly. In theory, the entity receiving a certificate should query the CA's revocation list each and every time it sees a certificate. To be most accurate, this query should go directly to the CA and receive an answer directly from their primary copy of the revocation list. Unfortunately, this model doesn't scale beyond something like a few thousand certificates. Implementation assumptions might get you better scaling on the order of a few tens of percent but you won't see the order of magnitude scaling that is frequently needed.
The suggestion you gave is more practical but does create an opportunity for a revoked certificate to still be used. This opportunity is the latency between the time the certificate is revoked and the time the revocation list is propagated. If you can use a push model (from CA to certificate receiver), it will keep the latency to a minimum.
Personally, I think the whole PKI idea is fundamentally flawed as do many cryptographic and security experts in the world. It works in the small. It doesn't work in the large and as long as you recognize that and are willing to accept the limitations of the implementation, you will be OK. Just never forget the limitations.
---eric