[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Paul Hoffman / IMC <phoffman@imc.org>
CC: keydist@cafax.se
From: Steve Hanna <steve.hanna@sun.com>
Date: Thu, 03 Jan 2002 12:55:38 -0500
Delivery-Date: Thu Jan 3 18:57:41 2002
Sender: owner-keydist@cafax.se
Subject: Re: From whence we came...

Paul Hoffman / IMC wrote:
> At 10:06 AM -0500 1/3/02, Steve Hanna wrote:
> >I'm pretty sure that we want certs here, not just keys. Putting keys
> >in DNS and relying on DNSSEC to authenticate the keys means that
> >you're tied to the DNSSEC trust model. Top down, single root (per
> >TLD), single certification policy that may not match an application
> >or user's needs, etc. Not good!
> 
> But reasonable for some purposes. This is not an either-or situation.
> Any kind of certs can be handed out. Some certs are PKIX certs where
> you pick the root of trust. Other certs are DNSSEC certs (which is
> really what a signed domain key is). I don't think there is a good
> reason to restrict the certs to a single format or a single trust
> model, but I could be wrong.

Yes, a top-down trust model with a single root may work for some
people. We certainly shouldn't prohibit it. But we shouldn't require
it, either. And using DNSSEC to distribute raw keys forces you into
that trust model. I think we're in agreement about this!

I was trying to focus on your earlier comment:

> Everyone: you have to decide whether you want certs or keys.

My point was that certs have some important advantages over DNSSEC
for key distribution.

> >Of course, using certs brings with it the problem of revocation.
> 
> Why should it? The PKIX world has been in denial about revocation for
> years. :-)

Many people ignore revocation. That's fine as a user decision. But
if you're designing a system that uses certs, you need to make sure
that it's possible (and as easy as possible) to support revocation,
should the user decide to enable it.

-Steve

Home | Date list | Subject list