Re: From whence we came...

[Simon Josefsson <simon+keydist@josefsson.org>]

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.

> Of course, using certs brings with it the problem of revocation.

Yes.  Maybe such applications are better of using LDAP+OCSP.

> 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.

> 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.

A new revision of the "Opportunistic IPSEC" draft is available:

http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic-04-change.txt

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.

> As for revocation, each cert can indicate how to get revocation
> information pertaining to that cert (for X.509 certificates, the CRL
> Distribution Point and Authority Information Access extensions serve
> this purpose).
>
> I know that certs are complicated. But there are libraries that
> handle this stuff now. And I don't want to go back to a single
> root model!

It might be better to think of keys in DNS as a (scalable) alternative
to LDAP, rather than as an alternative to PKIX.