[186] in WWW Security List Archive
Re: what are realistic threats?
daemon@ATHENA.MIT.EDU (Bob Smart)
Wed Oct 5 07:41:41 1994
To: www-security@ns1.rutgers.edu
In-Reply-To: Your message of "Tue, 04 Oct 1994 13:21:11 CDT."
<9410041821.AA10773@krypton.mcc.com>
Date: Wed, 05 Oct 1994 15:03:16 +1000
From: Bob Smart <smart@mel.dit.csiro.au>
Reply-To: Bob Smart <smart@mel.dit.csiro.au>
> to how certificates are obtained and validated, given the potential
> need for certificate revocation (e.g. a key pair is compromised, or
> routinely changed, or ...).
A certificate asserts a property of a public key and is signed by
other public keys. A lot of different things get lumped into
revocation:
1. Key compromise. If the private half of your key has been compromised
(stolen, broken) then you want to revoke all use of the key, not the
specific certificates which have been created making assertions about
that key.
2. If you have previously signed a certificate you may wish to cancel
your signature. I.e. say "I no longer assert this". This is subtly
different from:
3. You have previously signed a certificate and now wish to assert that
it is not true. E.g. You signed that somebody works for xyz.com and
they have left the job.
Perhaps the difference between (2) and (3) isn't important, but certainly
the difference between key revocation and certificate revocation is.
It is natural for certificates to include some mechanism for their
revocation. E.g. x.509 certificates have an implicit mechanism by looking
at well defined attributes in the X.500 entry for the certificate signer.
Key revocation should be easy. We just define a key revocation certificate
which should be signed by the key in question. Such a certificate would
prove that a key had been compromised whether it is signed by the owner or
the compromiser. The trick is to define a sensible way of checking whether
a particular key has such a certificate. In fact there aren't likely to
be many cases of key revocation and a simple single flat database replicated
by flooding would do the trick. Trouble is this would be liable to denial
of service attacks by generating lots of revocation certificates. Perhaps
this could be handled by charging, or maybe some more sophisticated
distributed directory system is needed.
> service, I'm not convinced that the approach of using certificate
> revocation lists (CRLs) will be adequate for on-line electronic
> commerce applications, at least with respect to the timeliness of the
> CRL information and the efficiency with which it can be processed.
I agree that there are some applications where an on-line check of
the status of a key might be needed. But certainly not for the small
amounts of money that will be needed for purchasing most information
through the WWW. On the other hand if you are buying something physical
which has to be physically delivered then an on-line check is again
not needed, as long as the check is made sometime before final delivery.
Bob Smart
