Kaufman>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.
As I said in my message to John Lowry, a digital signature is a digital
signature.
Without a physically-secure smart-card implementation, the risk of key
compromise
is ever-present, whether the key was intended for use with PEM or not. Even
with a tokenized implementation, there is the risk of physical theft unless some
type of biometrics are included on the smart card.
I don't think a user can avoid the possible liability for statements that might
have been forged using his stolen private key before he reported the possible
compromise. In fact, if digital signatures are to convey even a whiff of
nonrepudiation,
the user should not be allowed to repudiate messages signed before the
certificate was
revoked, hence the need for a trusted timestamp server, as I think everyone
understands.
And I agree that if his private key is compromised all messages previously sent
are
potentially compromised. We may be locking the barn after the horse has
escaped, but
at least we may stop the rest of the horses from leaving as well. I therefore
can't agree
this is overkill, or that PEM could meaningfully be used without a revocation
service.
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.
Agree. From the standpoint of merely establishing the fact that a message was
received after the certificate issuance date and before the expiration or
revocation
date, a sequencing mechanism like that being offered by Bell Labs would suffice.
But in many instances the date and time itself is of the essence, in order to
correlate
it with some external event that might not have otherwise been synchronized.
It may not be a PEM function, but a trusted date/time stamp is a practical
necessity.
From a legal standpoint, however, this is not the equivalent of notarization,
because the
user is not appearing in person before a human who can testify, if necessary, as
to the apparent competance and lack of duress of the originator and the fact
that he
was personally responsible for the signature (independent of any claim of
compromise).
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.
Agree. But I certainly don't want to "turn in" my private key, unless I can be
assured
that the key will then be destroyed. And I am a mite concerned that the
government
will impose a "CLIPPER" type of solution on any smart card implementation. Being
in a position where I don't know my private key but someone else does would not
be
helpful!
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.
I disagree. Other than a key escrow system, I don't see any purpose for
encrypting the message with the key of one's employer. Because the threat of key
theft is significantly less than the possibility that my personal computer is
compromised
or the backups misappropriated, I would expect to keep all of my messages in
encrypted
form, decrypting them each time I needed to refer to them again. (This implies
that I either keep all of my old private keys, or that I reencrypted messages
in my new
key. I don't think that either of these alternatives have been explored
seriously yet.)
...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.
Whether we use a positive or negative scheme (i.e., "this certificate is
valid," vs.
"the following list of certificate have been revoked"), it is clear that we
need a very
timely system for handling revocation -- once a month just won't cut it.
However, I'm not sure that implies that the CA has to be on line. Clearly the
PCA
has to be on line, but the CA shouldn't have to be. Now the issue is how best to
replicate the PCA's database of certificate revocations, so as to avoid the
denial of service problem
I'm not averse to having CAs exchange CRLs directly, as Anish Bhimani suggested,
but I am not sure how to find a given CA electronically given the current DN
naming conventions. I think we need to think about this a little more.
Bob