RE: X.BlaBla in PGP??? BWAHAHAHAHAHA!!!!
>Technically speaking it's not really supported by X.509 either because CRL's >don't really work (see for example the FC'99 proceedings for more details on >this, along with suggestions on how to fix it). I think you are probably refering to Ron's paper in FC'98. I presented an alternative and somewhat radical architecture at RSA'99 which demonstrated that it was practical to distribute revocation info in real time for a population of 5 billion certs. There is also the IETF work by Mike Myers and myself on OCSP and OCSP-X respectively. > This isn't a problem with Outlook or MS (for once :-) but a >problem with the whole CRL concept. Agreed, I see CRLs as a draft architecture that was good enough for circa 1990 but not so hot come deployment a decade later. But it is quite possible to provide a workable solution in context. > An option which I like (because >it's efficient and fast) is to have a BIND-style daemon which snarfs CRL's >from wherever[0] every now and then and answers validity check queries very >quickly (millisecond response time, so the user won't even notice it's >happened). I hope to have a paper on this out RSN. I will send you the paper I wrote for RSA '99. I describe precisely that type of architecture. The argument I make is that we should migrate to that type of architecture in the long term. OCSP provides a very usefull staging ground. Phill smime.p7s
Re: Slow revocation checks (was: X.BlahBlah...)
lcs Mixmaster Remailer <[EMAIL PROTECTED]> 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.
Slow revocation checks (was: X.BlahBlah...)
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? Is this because: - CRLs are not cached but fetched every time? - CRLs expire every week or so, and you probably don't get more than one encrypted message a week, so your previous CRL has expired? - CRLs are issued by dozens of different CAs, and you probably don't ever receive two messages from people certified by the same CA, so you don't have a CRL from the CA you need? None of these seem particularly plausible. Is there another reason?
