Subject: Re[2]: Huge CRLs

From: Michael Versace <[email-masked]>
Date: Fri, 10 Sep 1999 13:48:43 -0400

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...

---

From: Stephen Kent <[email-masked]>
Date: Sat, 11 Sep 1999 11:48:47 -0400

Mike,

I think one encounters different perspectives on CRL use in different quarters.

For example,  I never suggest that ALL relying parties should try to fetch
ALL relevant CRLs frmo directories in conjunction with processing EVERY
blob of digitally signed data, establishing every secure connection, etc.
Instead, I usually suggest that an RP acquire certs and CRLs and cache them
locally.  Since CRLs have explicit lifetimes, one may often decide that
there is no need to see if a new (emergency) CRL has been issued before the
next scheduled issue date.

Not all uses of certificates involve NR, e.g., certs used in SSL and IPsec
for authentication and/or authorization, of for authentication in S/MIME.
In these environments one is already accustomed to some delay in
propogation of changes of authentication data.  Also, servers receiving
certs as part of a user authentication process may have especially good
access to the CRLs for those user certs, because they may be locally
issued, thus changing the complexion of CRL distribution dramatically.

In these contexts, claims that models for CRL use are unrealistic don't
strike me as valid.  Yes, I have heard others make unrealistic suggestions
re CRL use models. Everyone is free to make bad suggestions all the time;
we have to be selective in whose suggestions we pay attention to.

Steve