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