Five Theses on Security Protocols
Perry E. Metzger
perry at piermont.com
Sat Jul 31 18:17:42 EDT 2010
On Sat, 31 Jul 2010 19:30:06 +0200 Guus Sliepen <guus at sliepen.org>
wrote:
> On Sat, Jul 31, 2010 at 12:32:39PM -0400, Perry E. Metzger wrote:
>
> > 1 If you can do an online check for the validity of a key, there
> > is no need for a long-lived signed certificate, since you could
> > simply ask a database in real time whether the holder of the key
> > is authorized to perform some action. The signed certificate is
> > completely superfluous.
> >
> > If you can't do an online check, you have no practical form of
> > revocation, so a long-lived signed certificate is unacceptable
> > anyway.
>
> But, if you query an online database, how do you authenticate its
> answer?
With a public key you have in a configuration file, or a pairwise
shared secret key stored in a database.
A key sitting in a configuration file is not the same thing as a
certificate signed by a CA and trusted for that reason. Instead, it is
trusted for the same reason that, say, the /etc/passwd file on a Unix
box is trusted -- because if someone could break in and alter the
file, they could do anything else they wanted anyway.
You do not need a signed certificate.
> If you use a key for that or SSL certificate, I see a
> chicken-and-egg problem.
I don't see why you need a certificate for any purpose whatsoever.
A key, on the other hand, is a very different thing. There's nothing
wrong with keys.
Perry
--
Perry E. Metzger perry at piermont.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list