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