[cryptography] current status of SSL revocation support

Ian G iang at iang.org
Thu Aug 26 20:52:32 EDT 2010


On 27/08/10 7:28 AM, travis+ml-rbcryptography at subspacefield.org 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



More information about the cryptography mailing list