On 27/08/10 7:28 AM, [email protected] wrote:
I got the impression, many years ago, that you couldn't rely on systems to check revocation status, even if the system was online.
More or less, this opinion is held by many who've looked closely at the results.
Although the concept works on paper, it lacks agreement in semantics and tends not to suggest reliable engineering. Hence, reliance is somewhat undermined.
I was wondering what the current status was on this for the various implementations (OpenSSL and NSS, in particular). I think I saw in OpenSSL cert generation that you could optionally set a CRL URL in CA certs, but I don't know what the mechanism is for downloading that; if it's up to the client, I suppose you can't rely on the client app to actually do it, and I wonder how failures would get reported - making it a potential case where bit rot may not get noticed.
It's not clear to me whether revocation is considered an application thing or a crypto-library thing. I can see pros & cons for both approaches. I somehow doubt it is mandated, which would give the first clue as to unreliability: the library expects the app to do X and the app ignores X for reasons of its own.
(The alternate, making it mandated in the library, is just as bad.)
I also recall, around the time of the 7th Usenix security symposium, that there were various proposals for protocols to look up revoked certs efficiently (they were also mentioned in Peter Gutmann's crypto tutorial), but I haven't kept up on these. Any links on the subject, or key management generally, would be much appreciated.
Search on OCSP. It is likely to become mandated, and to fully replace file-download revocation (CRLs).
iang _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
