To:
Mats Dufberg <dufberg@telia.net>
cc:
<keydist@cafax.se>
From:
Greg Hudson <ghudson@MIT.EDU>
Date:
Mon, 14 Jan 2002 12:57:08 -0500 (EST)
In-Reply-To:
<20020114113507.J86363-100000@padda.telia.net>
Sender:
owner-keydist@cafax.se
Subject:
Re: RESCAP/RC: an alternative to key distribution using DNS
On Mon, 14 Jan 2002, Mats Dufberg wrote:
> On Jan 10, 2002, 20:09 (-0500) Greg Hudson <ghudson@MIT.EDU> wrote:
>
> > I'm a little leery of this approach; it means that the same private key
> > has to be used to sign both DNS and non-DNS data. Maybe that's okay, but
> > it sounds like a violation of
[Hm, I trailed off here. "a violation of good security principles."]
>
> No, you could use a separate key for signing application keys.
Uh, no; you must be misunderstanding something (and you certainly aren't
being very explicit). To recap, here are the incompatible constraints:
1. (Mine) We have to be able to establish a security chain from the DNS
root to the application data, such that a client which starts out
knowing only the public key of the DNS root can securely associate
application data with DNS names.
2. (Mine) We can't use the same key to sign DNS and non-DNS data. (That
is, if a private key is accessible to whoever signs a DNS zone, it
shouldn't also be accessible to whoever signs a RESCAP data set or
whatever.)
3. (Keith's) We can't have any keys or key fingerprints in DNS except
for the KEY records which protect DNS data.
I may be putting words in Keith's mouth with number 3, but he didn't like
the idea of putting key fingerprints in NAPTR records and suggested
instead somehow putting the "tying" data into RESCAP, so I think I made a
reasonable interpretation.
I don't think those constraints are compatible; (2) and (3) together
preclude (1).