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