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


To: Simon Josefsson <simon+keydist@josefsson.org>
CC: Paul Hoffman / IMC <phoffman@imc.org>, keydist@cafax.se
From: Steve Hanna <steve.hanna@sun.com>
Date: Thu, 03 Jan 2002 13:27:01 -0500
Delivery-Date: Thu Jan 3 19:29:06 2002
Sender: owner-keydist@cafax.se
Subject: Re: From whence we came...

Simon Josefsson wrote:
> Steve Hanna <steve.hanna@sun.com> writes:
> > 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!
> 
> For some applications the DNSSEC trust model is sufficient.
> 
> Also, I'd imagine that a department using SSH with keys (not certs)
> stored in DNS protected by DNSSEC would configure their clients to
> trust their own DNSSEC key directly.  Or simply using TSIG protected
> DNS to a local DNS server that knows the SSH keys.  In practice this
> would mean having a separate trust root and a separate policy.

This works OK, as long as you have only one department. What if
you have two? What if math departments at two colleges want to
work together securely? Who's the root then? The DNS namespace
often doesn't match the structure of trust.

> > And certs are often big, so retrieving them from DNS is problematic.
> 
> Right, so applications that use keys instead of certs might be better
> suited to use DNS.  Anyway, IPv6 and DNSSEC will also generate large
> DNS packets, so the size issue is not specific to keys in DNS.

Applications that use keys instead of certs? What do you mean?
Certs are only a mechanism for key distribution. All these apps
end up using keys in the end.

> > Passing the certs in the application protocol (as with TLS) is
> > certainly the easiest way to handle key distribution.
> 
> Yes, but it assumes that you have a separate trust infrastructure
> already in place.  If this is the case, I agree putting certificates
> in DNS buys you nothing.
> 
> But if you don't have a prior arrangement between the parties, using
> keys in DNS might overcome this problem.

Why is it better to depend on the "trust infrastructure" of DNSSEC
than to depend on a PKI? Millions of people use PKI every day (with
HTTPS). Popularity does not equate to superiority, but it's hard to
argue that PKI is not practical.

> Replace IPSEC with S/MIME in the draft and you get another nice
> applications -- secure email between two persons that only knows each
> others email addresses.  Today it isn't really possible to find
> someone's certificate using only the email address other than
> trial'n'error attempted fetches against a couple of likely CAs.

The current practice is for the parties to exchange signed emails
with little content except their certificates. Then they can use
those certificates to send encrypted email. Maybe at some point
email clients will start using SRV records to find an LDAP server
that might contain an unknown recipient's certificate.

-Steve

Home | Date list | Subject list