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