Hi Martin,
I agree on the problem but not totally on the suggeeste solution :)
I'd like to propose the following change for the next release:
- for each certificate the notBefore and notAfter dates are stored in the database - the following certificate status are kept in the database: - ISSUED (certificate was issued and may or may not be valid) - REVOKED (certificate was explicitly revoked) - maybe we also need RENEWED which might be set for the old cert if the same DN is issued again later - a library function should exist that determines the current and up-to-date certificate status for an ISSUED certificate. This function must be called in order to get the true status of the cert in terms of validity.
My proposal:
We agreed to implement a kind of "batch" daemon for background processes like CRL renewal that runs always. So I would prefer to implement a kind of "at-Job" Handling that sets the certificate state in the case of a "scheduled" state change (expiration). Otherwise you always have to check against more than one crieria to obtain a certificates status what might be a problem on heavy loaded systems.
If a certificates state changes "unscheduled", s by revocation or similar, than we have an action on the certificate and can simply set the status....
Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72
smime.p7s
Description: S/MIME Cryptographic Signature
