[15217] in cryptography@c2.net mail archive
Re: Verisign CRL single point of failure
daemon@ATHENA.MIT.EDU (Dirk-Willem van Gulik)
Thu Apr 1 11:00:04 2004
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <3FFEFBBE.7050603@datapower.com>
Cc: dave kleiman <davek@netmedic.net>, cryptography@metzdowd.com
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
Date: Thu, 1 Apr 2004 11:22:47 +0200
To: Rich Salz <rsalz@datapower.com>
On Jan 9, 2004, at 8:06 PM, Rich Salz wrote:
> dave kleiman wrote:
>> Because the client has a Certificate Revocation Checking function
>> turned on
>> in a particular app (i.e. IE or NAV).
> I don't think you understood my question. Why is crl.verisign.com
> getting overloaded *now.* What does the expiration of one of their CA
> certificates have to do with it? Once you see that a cert has
> expired, there's no need whatsoever to go look at the CRL. The point
> of a CRL is to revoke certificates prior to their expiration.
Though I have no particular experience with the virus-scan software;
we've seen exactly
this behavior with a couple of medical app's build onto the same
libraries. Once any cert
in the bundle is expired the software -insists- on checking with the
CRL at startup. And it will
hang if it cannot. When it gets the info back - It does not cache the
(negative) information;
nor does that seem to trigger any clever automated roll-over. We tried
tricking it with flags like
'superseded' and cessationOfOperation in the reasons/cert status mask -
but no avail. The
only workaround we've found is to remove all expired certs from the
system asap.
My guess it is just a bug in a library; albeit a commonly used one.
Dw.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
