To:
Derek Atkins <warlord@MIT.EDU>
Cc:
Ted.Hardie@nominum.com, Keith Moore <moore@cs.utk.edu>, Edward Lewis <lewis@tislabs.com>, keydist@cafax.se
From:
Ted Hardie <Ted.Hardie@nominum.com>
Date:
Wed, 9 Jan 2002 13:35:30 -0800
Content-Disposition:
inline
In-Reply-To:
<sjmelkznv62.fsf@indiana.mit.edu>; from warlord@MIT.EDU on Wed, Jan 09, 2002 at 03:09:25PM -0500
Reply-To:
Ted.Hardie@nominum.com
Sender:
owner-keydist@cafax.se
User-Agent:
Mutt/1.2.5i
Subject:
Re: From whence we came...
Derek: > What this means is that any key distribution mechanism needs to > support any random key-data formats. As Mr. Richardson put it: the > keydist protocol needs to ship around types blobs. I define my blob > format, you define your blob format. DNSSec provides the origin > authentication (and integrity protection) of the blobs. However > we leave "what the blob means" up to the applications. I assume you mean "blobs" in the generic sense, and aren't referring to the blobs that Keith means in the RESCAP docs. With that assumption, I'd like to assert that we need at least enough in the keydist protocol to ask for a key of a specific type. "Driver's license and registration" and "Passport, please" are both valid in their contexts, but the results of the query should not be the same. Treating each type of ID as an "identity blob" with a mechanism that returns all "identity blobs" to a query for them won't be a very effective infrastructure. regards, Ted Hardie