Hi Oli, > 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....
sorry to disagree, but I do not think this is a good idea: The at job handling would introduce a complicated and asynchronous step into the cert status handling. Still there would be a short time frame where the cert status is not actually correct, because the at jobs would not execute the DB update command at exact the required second. Queries in this time frame would return an incorrect state. Worse yet, we would have to handle downtime of the CA system. At jobs that triggered during this downtime would have to be executed when the system is up again. "Forgetting" this update will induce an inconsistent state. If the notBefore and notAfter dates are stored in the DB, selecting e. g. a valid cert is just another query condition, hence I do not think this would impose a performance penalty. And we'd get back the status atomically. Just my thoughts. Martin ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ OpenCA-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openca-devel
