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

Re: Light-weight certificate revocation lists ?



At 12:45 AM 4/2/97 EST, Ron Rivest wrote:
>
>I like the term "wandering anti-matter"!

..glad you like it :)


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

Ron,

	you have postulated a operation with 3 entities, if I read you correctly:  
a cert issuer, a cert database server for that issuer and a cert user.  The 
user would fetch certs from the database server.

	Do you want CRLs to go from the issuer to the server?  I believe the term 
is traditionally used for a communication from server to user.

	It's clear that there needs to be a protocol for communicating new certs 
and revocation of old ones from the issuer to the server.  There also needs 
to be a way to communicate current certs from server to user.  The server 
might also implement an online test for the user to check.

	The issuer to server mechanism is an interesting area of study, but I would 
do something more like nntp to handle it.  That is, an issuer might have a 
private copy of a cert database (of certs he has issued), but because he's 
offline much of the time and wants to provide fault tolerance besides, he might
replicate his DB of certs among multiple servers.  To do that replication, 
you need to propagate any changes.  Some changes are new certs and some are 
deletions (which we call revocations).  This is handled nicely by USENET news.
Because we care about security, we need a version with signed messages, but
other than that it shouldn't be much different.

	I would suggest that we consider the design for such a distributed, 
replicating server and write it up as a separate I-D.

	Now, if you're suggesting the CRL for communication from server to
user, I stand by my previous mail.

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


References: