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

Light-weight certificate revocation lists ?




I like the term "wandering anti-matter"!  I don't want to require that
someone go and fetch the crl, that is a disaster and is, as you suggest,
perhaps better done with an on-line test.  

But there is at least one case where the anti-matter is not wandering,
which is in the relationship between a principal and his server.  Here
it is more like "pushed anti-matter" or "thrown anti-matter".  I think
the SDSI notion of a server for a principal is useful, and there needs
to be some means of communicating a request to drop a certificate from
the database of certificates issued by that principal that the server
is making available to others.  Another related scenario is when you
are in an organization with a small number of servers for the
organization, and you can kill all copies of the cert in their
databases by sending them the crl.  In either of these cases you have
an issuer that is physically separated from the server representing
him to others, and you definitely need a way for the issuer to tell
the server to drop some certificates.  (If we don't put it into
SPKI/SDSI, then the implementors will have to add it on their own.
Maybe this should be entirely "under the covers", but I think it might
be better to be explicit.)  I'd rather not have crls at all, but I think
they are unavoidable in this scenario, and may be useful in others.

What do others think?

Ron Rivest
==============================================================================
To: rivest@theory.lcs.mit.edu (Ron Rivest)
From: Carl Ellison <cme@cybercash.com>
Subject: Re: Light-weight certificate revocation lists ?
Cc: spki@c2.net, blampson@microsoft.com
In-Reply-To: <199704020415.AA23803@swan.lcs.mit.edu>
Mime-Version: 1.0

Ron,

	here I have to disagree with you.

	I believe CRLs are an unqualified disaster.  That's why we
provide for an online test of validity.  A CRL is like a piece of
anti-matter, sent out into the world in the hopes that it will collide
with the appropriate matter and annihilate it.  If you somehow insist
that any cert verifier go fetch an up-to-date CRL, then you have
reinvented the online test, so I take "CRL" to refer to the wandering
anti-matter mechanism.

	To me, the fundamental problem with the CRL idea is that it
violates the cardinal rule of data driven programming: that once you
have emitted a datum, you may not attempt to take it back.  If you
provide for such a mechanism, then you are allowing non-deterministic
behavior.

	On a more practical level, CRLs grow and communicating them
becomes a major pain.  Because their use leads to non-deterministic
results, you have endured the pain in return for nothing in terms of
security.

	As far as a serial number is concerned, I see no use for it
except in the online test.  Therefore, to me, it belongs as a
parameter to the online test specification rather than as a field of
the certificate.

 - Carl


+------------------------------------------------------------------+
|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+



Follow-Ups: