----- Unsent message follows -----
Received: by us3rmc.bb.dec.com; id AA15546; Fri, 17 Sep 93 17:40:44 -0700
Received: by inet-gw-1.pa.dec.com; id AA09024; Fri, 17 Sep 93 17:39:46 -0700
Received: from magellan.tis.com by magellan.TIS.COM id aa00897;
17 Sep 93 19:57 EDT
Received: from tis.com by magellan.TIS.COM id aa00893; 17 Sep 93 19:55 EDT
Received: from azalea.tis.com by TIS.COM (4.1/SUN-5.64)
id AA28116; Fri, 17 Sep 93 19:54:58 EDT
Received: by azalea.tis.com; id AA12156; Fri, 17 Sep 93 19:53:37 EDT
Received: from decvax.zk3.dec.com/16.140.0.3 via smap
Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92)
id AA05616; Fri, 17 Sep 1993 19:53:58 -0400
Received: by abyss.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA29369; Fri, 17 Sep 1993 19:53:56 -0400
Message-Id: <9309172353(_dot_)AA29369(_at_)abyss(_dot_)zk3(_dot_)dec(_dot_)com>
To: Jueneman(_at_)gte(_dot_)com
Cc: pem-dev(_at_)tis(_dot_)com, kaufman(_at_)zk3(_dot_)dec(_dot_)com
Subject: Re: Certificate revocation
Date: Fri, 17 Sep 93 19:53:56 -0400
From: kaufman(_at_)zk3(_dot_)dec(_dot_)com
X-Mts: smtp
However, I have concluded that the current CRL system is a snakepit
of problems masquerading as solutions.
I agree.
(Gentlemen, start your flamethrowers! But first hear me out.)
Who could pass up an invitation like that?
I believe the PEM community has spent way too much time trying to
solve the revocation problem. I believe that your proposed
"CRL service" is the first technically sound proposal for dealing with
revocation, but I also believe in the context of PEM it is overkill.
Consider, for example:
I wanted to include language that would make it clear that the user
has no oblication or liability for any document allegedly signed after
the user's certificate has been posted as revoked by the PCA.
What about things signed with my key between the time it is
compromised and the time I find out about it? If the thief is
discreet, that could be a very long time. Further, compromise of my
key compromises *all* previous messages addressed to me, not just
those sent after the compromise.
Basically, with PEM if someone learns your private key, you're hosed.
CRLs and mechanisms like yours are attempts at papering over a
disaster; they don't really help enough to allow PEM to be used in any
context that it couldn't be used in even if there were no revocation
mechanisms at all.
I think that's OK. PEM is a great leap forward for what it is.
Contexts needing higher security are important too, and experience
with PEM will make us wiser when we try to address them.
If we really wanted to deal with revocation, there would be a number
of things we should do:
1) We should have notary services so that messages sent could carry a
mark from one or more trusted third parties asserting that the
signature existed at time 'x'. Those stamps should be able to be
applied by either sender or recipient or both. We would have to deal
with compromised notary services and how to revoke them too. We would
probably want to create automated notaries with physical hardware
packaging making it practically impossible to compromise them even if
you own them.
2) Users should be able to use but not know their private keys. They
should be encapsulated in smart cards so that it is practically
impossible for someone to obtain your private key without your
noticing that it's missing. This would also make it possible to
convincingly "turn in" your private key when you leave a company.
3) Double encryption of messages should be supported so that they can
only be decrypted with a user's private key and the private key of an
agent of the user's employer working in concert. This would require a
double failure to compromise a message. The agent might refuse to
decrypt messages more than 'x' days old or that it remembers it has
decrypted before.
...and finally,
4) We should have a timely revocation service. I don't believe in
CRLs. They can't work because in any scheme were revocation is
important, it is likely to have to be effective within hours if not
minutes. You can't be assured that a CRL is current unless it is
reissued every revocation time. CRLs reissued every few hours means
that the CA is not locked in a vault and is probably on-line, losing
you the benefits that public key technology was supposed to give you.
I believe the only solution is to have an on-line revocation service
that tells you what certificates have been revoked and will sign and
timestamp the guarantee. It could tell you by delivering a CRL,
though that gives little additional value over the signature of the
on-line agent.
- --------
If what you're trying to do is enhance the PEM certificate hierarchy
so that it can be used in non-PEM applications with security better
than PEM can provide, then I think you're on the right track. But
unless we're going to address the first three issues, I don't think we
can pretend it's important for PEM itself.
--Charlie
(kaufman(_at_)zk3(_dot_)dec(_dot_)com)
------- End of Forwarded Message