[6733] in cryptography@c2.net mail archive
Re: Slow revocation checks (was: X.BlahBlah...)
daemon@ATHENA.MIT.EDU (Peter Gutmann)
Mon Mar 6 17:59:58 2000
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cryptography@c2.net
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
Date: Tue, 7 Mar 2000 11:10:31 (NZDT)
Message-ID: <95238063103546@kahu.cs.auckland.ac.nz>
lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> writes:
>Peter Gutmann writes:
>>The reason why revocation checking is disabled by default is a pragmatic
>>one, in practice it acts as a "Delay processing each message by a minute
>>or two" facility (or at least it did a year or so back), so by disabling
>>it by default the vast masses (who don't know or care about it) get
>>their PKI warm fuzzies, and those who turn it on get what they asked for
>>(I don't use Outlook but if I did I'd certainly have it turned off).
>Can you explain why it has this delay? Presumably it is because it has
>to fetch a CRL?
I have no idea, as I mentioned I don't run Outlook (the performance problems
were reported by someone else). You could try turning on revocation checking
and seeing for yourself. I can imagine though that it's just something which
doesn't work very well... imagine doing DNS lookups by connecting to a server
in Sweden which responds to every query with a zone transfer for .se. Delta
CRL's are a kludge which may ameliorate this, but from endless discussions
about their semantics on PKI lists it's likely they cause more problems than
they solve.
BTW in my previous message I referred to some papers from FC'99, I've checked
the proceedings and they were actually from FC'98... I'd recommend having a
look at these since they actually present some real, workable solutions rather
than trying to fix something which was broken when it was first introduced
15-20 years ago (although noone knew it then) and hasn't got any better with
time.
Peter.
