Kyle Rose <kr...@krose.org> writes: >What Peter said isn't quite right, since (for example) you wouldn't want to >be obliged to distribute revocations for compromised but long-expired >certificates under the assumption that a properly-functioning client wouldn't >accept them anyway
Ah, good point. However, you also need to look at what problem is being solved. The OP mentioned systems without real-time clocks, which most of the time means systems outside of the web PKI - try starting a PC whose clock is too far off and lots and lots of things break badly, at which point you ask the user to set the time correctly regardless of NTP availability. So we're down to mostly non-web-PKI devices and/or the ten year problem, of which I've encountered the latter several times with gear that sits on a shelf for years and then when it's time to provision it all the certificates have long since expired, which is another reason why you ignore expiry dates (or at least you ignore them after you get hit by the first major outage caused by this because until then no-one realised that it was an issue, a ticking time- bomb that may take years to detonate). That leaves revocation, which alongside ignoring expiry dates is another thing that's commonly ignored in SCADA, both for the same reason as expiry dates are ignored, you don't want to DoS yourself, and because in many cases there's neither a logical nor a practical basis for revocation or revocation checks. For example in typical SCADA networks a device is removed by shutting off its access, not by adding an entry to a CRL somewhere and hoping someone notices. In fact it's not even clear what certificate would be revoked in order to achieve some effect, or why. In addition since revocation checking assumes online access to a CA, which typically isn't the case (I know of one setup where CRL delivery is by USB key once a year or so, and AFAIK the CRL is always empty because you don't want to knock a system offline with a revocation), there's no practical revocation checking done even if someone can figure out a logical reason for performing one. So I think before jumping in with a solution, we'd need to look at actual real-world usage cases to determine what actually needs to be solved. Ignoring CA billing-cycle^H^H^Hexpiry dates seems to be the simplest solution for many cases, and is more or less necessary for the ten-year problem. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
