[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CRLs versus short Validity periods


Carl Ellison wrote:
> At 05:10 3/1/96, Frank O'Dwyer wrote:
> >cme@cybercash.com (Carl Ellison) wrote:

> The one departure from my model is the one you cited above -- with
> VeriSign issuing a CRL covering its thousands of certificates and every
> consumer of certificates caching VeriSign's CRL.  In this case, the
> verification of the CRL's signature and its receipt might be amortized
> in the verifier over a number of different certificates.
> 
> This assumes one thing I don't necessarily agree with:  that there will be
> only a few CAs [few enough that any cert user is likely to have many hits
> on each CA's CRL during the CRL validity period].

The assumption is really only that there will be a few CAs (relative
to number of CA users) _for_some_applications_.  I think this is a 
reasonable assumption (we can't all be banks). It's also reasonable to 
assume that other applications will involve millions of CAs (with 
individuals, in effect, acting as their own CAs, for example). The 
VeriSign example I gave is just a special case where this is not true, IMO.
I think we basically agree here?
  
I think that the 'no-CRL' model is just a special case of 
the CRL model (and a strict hierarchy is just a special case 
of the PGP-style graph model, for that matter). I would like to
see a solution that (within reason) handles the general cases and lets it 
find its own level.  In cases where the CRL stuff can be optimised out, 
it will be.  Ideally this sort of tuning would be automatic in a 
good system.  But I'm not convinced that not having CRLs at all 
will work in all cases, even though I could imagine a lot of apps
being compiled -DNO_CRLS.

> In my model of the future world, there will be a vanishingly small percentage
> of certificates which are identity-based.  The vast majority will be
> attribute-based (Rivest's "type II") and those will be issued by owners
> of the attribute being allocated.  Every public key will become its own 
issuer
> and each such issuer will generate only a few certificates.  Therefore,
> unless the CRL validity period is very long, the probability of a second hit
> on a validated CRL is very small.  Meanwhile, there will be as many issuers
> (or more) as any cert verifier is likely to have certificates to verify
> -- so it is not practical to cache the CRLs of each one.  In fact, some
> verifiers will be stateless code, in which case CRL's can not be cached
> at all.

I agree (if I've understood), and I really like the key-centric nature
of what you have proposed.  However I'm a little confused about how 
you bootstrap into this key-centric scheme, since most applications will start 
out with some kind of identifier in hand, not a key.  Applications are 
right now doing application things, after all, not key things, and users
don't type keys.  (By identifier I mean IP address, RFC822 address, FQDN, 
URL, or whatever--a CS identity if you like.)  Suppose, for example, 
all my application has is its own key pair and out of the blue is given
something's IP address.  It wants to connect to some resource that 
'really is' at that IP address (leave ports out of it for the moment), for 
some value of 'really is' (this might only work for local IP addresses).  
How does my app get to the key or keys that it needs for this?  That is 
really a basic PKI question--how do you map something or other (usually 
some text string?) to a key, securely?

In your model, I assume that my app pulls out its own key (or one of the 
keys it's been physically configured with), and searches the net (how?) 
for attributes bound to it (signed by it). I assume that certain special 
types of attributes would allow the search to recurse using attributes 
signed by other keys (i.e. usual certificate chaining).  Other attributes 
might perhaps require the search to come up 3 or 4 'lesser' keys vouching 
for some information (cf. PGP's 'marginal' signatures).  But do you 
envisage some general algorithm for this search, or is it entirely 
a per-application thing?   In other words, how much of this sort of PKI 
(the actual code, as well as the actual certificates) do you envisage 
being reusable across different applications? 

Cheers,
Frank O'Dwyer.
References: