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


To: Simon Josefsson <simon+keydist@josefsson.org>
CC: Edward Lewis <lewis@tislabs.com>, keydist@cafax.se
From: Steve Hanna <steve.hanna@sun.com>
Date: Mon, 14 Jan 2002 14:51:29 -0500
Sender: owner-keydist@cafax.se
Subject: Re: looking for draft volunteers

Good summary. A few comments on your text:

>    "Store referral in DNS, retrieve keys via other protocols"
> 
>       This is possible now using, e.g., SRV and LDAP.
> 
>       Requires LDAP over TLS or similar.

Plain LDAP is fine if you're retrieving certs instead of raw keys.
When using certs, the application's trust in the key comes from
the fact that the cert was signed by a trusted party, not that it
came from a particular repository.

Since you're trying to be even-handed and discuss how each mechanism
would work with certs *or* keys, I suggest you change the last
sentence here to say "If raw keys are used, DNSSEC and LDAP over
TLS or something similar is required. If certs are used, plain
DNS and LDAP are fine."

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

>   "MUST be possible to secure locating and retrival of the key"
> 
>   Interpretation: Either via DNSSEC, TSIG, or referral from DNS with a
>   key fingerprint in DNS similar to WPKI [14], CMS [7], TLS [15] or
>   something completely different.

How about including PKIX [8]?

-Steve

Home | Date list | Subject list