Hi Oli, > I thought about the problems before posting - but I think that the > status flag in the DB can not be used for such a time-critical or > high-security application - you have a similar problem with just the > "runtime" of a revoke action. I think that an application should verifiy > the timestamp for itsself and does not need the OpenCA System for it - > so I see the "expired" state as not that time-critical as we cannot > accept the lag...
I didn't want to imply abusing the cert expiry information for these purposes. It's just about consistency concerning the user frontend output and certificate status handling. I still think it's a bug to keep an 'expired' or 'valid' flag in the database in the first place, even if it's updated automatically by the system. The cert notBefore and notAfter information is accurate, easy to evaluate and allows to deduce the exact status without much overhead. So why have this asynchronous process? It's the same effort to query it from the DB and I do not believe it will induce performance problem even for extremely high volume CAs. 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
