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


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


Home | Date list | Subject list