Re: looking for draft volunteers

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

On Mon, 14 Jan 2002, Steve Hanna wrote:

> > > > Requirements on a Solution
> > > >
> > > >   "MUST be possible to locate application keys given only IP address
> > > >   or hostname"
> > >
> > > You also need *some* sort of trusted key (DNS or PKI). Otherwise,
> > > you're wide open for impersonation. Note that the first use case for
> > > SSH above seems to suffer from this problem. You only brought one
> > > key, the SSH host key for beagle. Now that machine is down. You're
> > > SOL unless you also have another trusted key.
> > 
> > I think the assumption is 'some DNSSec key'...
> 
> If there's a built-in assumption here, it should be made explicit.
> The use case should say "Fortunately, I have the key of the DNS
> root or a PKI trust anchor." The requirements should say "MUST be
> possible to locate application keys given only IP address or
> hostname *and* a trusted key (DNS or PKI)"
> 
> Simon, was there a built-in assumption there?

No.  I separated the issues into two requirements:

  "MUST be possible to locate application keys given only IP address
  or hostname"

  "MUST be possible to secure locating and retrival of the key"

I did not want to restrict the mechanism of locating and retrieving keys 
by assuming the locating/retrieving mechanism is secure.

If DNSSEC never happens, it still can be useful to distribute, e.g., SSH
keys using DNS as long as you have some other mechanism to secure the
retrieval afterwards.  The retrieved key might contain information that
lets you contact whatever trust point you may have to make sure it is the
right key.  Clients in general should not have to be manually configured
to point at one LDAP server, lets make the application find this out
themselves.  (Of course, trust points should (only) be manually
configured.)

Given the state of DNSSEC, I believe we should include this model as well
(or at least not exclude it).