Subject: Re: Re[2]: Huge CRLs

From: "David P. Kemp" <[email-masked]>
Date: Fri, 10 Sep 1999 14:38:16 -0400 (EDT)

"Centers around one, impractical model"???

Perhaps you mean one impractical implementation.  A CRL is just an object
signed by a revocation authority listing the certs within a specific
scope that have been revoked.  If your CRLs are "Huge", perhaps your
scope needs to be narrowed.  If your window is too short, perhaps the
revocation authority's nextUpdate period needs to be tuned.  If you can't
find the right CRL in a directory, perhaps the schema needs adjusting,
or perhaps the CRL should be distributed via http or pushed with the
transaction rather than being looked up via LDAP.

Look at your requirements, look at the CRL object, and then ask yourself
what it is about the object that is preventing you from meeting the
requirements.  My guess is that you will find ... nothing.

> Date: Fri, 10 Sep 1999 13:48:43 -0400
> From: Michael Versace <[email-masked]>
> Subject: Re[2]: Huge CRLs
> To: [email-masked], [email-masked], [email-masked], 
[email-masked]
> Cc: [email-masked], [email-masked], [email-masked], [email-masked]
> 
>      Timing is important.  In payment systems, for example, there are 
>      certain time windows within which users can revoke authorization 
>      and processors can deny payment transactions.  Some payment systems 
>      have very short windows (fedwire), some have very long windows 
>      (checks, ACH, cards).
>      
>      It seems that most theoretical talk about CRLs centers around one, 
>      impractical model, as Kawika points out.  That is - as soon as I 
>      get a cert in a transaction, I need to immediately determine if it 
>      is fresh.  Building infrastructure to support new business 
>      practices 
>      like this are difficult to justify.
>      
>      Public key, no infrastructure, yet
>      
>      Mike Versace
> 
> 
> ______________________________ Reply Separator 
_________________________________
> Subject: Re: Huge CRLs 
> Author:  <[email-masked]> at Internet
> Date:    9/10/99 10:29 AM
> 
> 
> Good point!
> But...
> CRLs in any form are a fundamentally inadequate approach to solving practical 
> problems and in most cases cannot meet business requirements for even small 
> scale infrastructures.  CRLs were a good idea when the terribly impractical 
> people who developed them were working on paper and not such a great idea 
> when you have to turn paper into production systems.   CA revocations 
> experiments done on practical deployments (real world machines, apps, and 
> users) of even small PKIs will demonstrate that complying with your own 
> policy won't happen in the real world if you base your revocation hopes on 
> CRLS.
> Why are you messing with them?
>      
> ..kawika daguio...
>      
>