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

SDSI DNS namespace




Hal Finney raised some questions regarding how a DNS key hierarchy would
work.  SDSI's current design pre-supposes that there is (or will be)
a public-key hierarchy for the DNS name-space.  

I personally believe that a DNS public-key hierarchy is a "given"; the
Internet desperately needs such a hierarchy, just for its own
operational security.  If others can leverage off this hierarchy as
well, so much the better.

Furthermore, there are detailed proposals for how this should work.  Donald
Eastlak (dee@cybercash.com) pointed me at
	draft-ietf-dnssec-secext-09.txt
which I obtained by ftp from
	ftp.isi.edu
This proposal is up for consideration as a Proposed Standard by the IESG
right now.

SDSI doesn't need the DNS public-key hierarchy, but can work with it if
and when it comes into existence.

	Cheers,
	Ron Rivest
	[ SDSI is at http://theory.lcs.mit.edu/~rivest/sdsi.ps or .tex ]
==============================================================================
Return-Path: <owner-spki@c2.org>
Date: Wed, 1 May 1996 20:37:16 -0700
From: Hal <hfinney@shell.portal.com>
To: spki@c2.org
Subject: SDSI DNS namespace
Sender: owner-spki@c2.org
Precedence: bulk

One thing I didn't quite follow was the use of SDSI in the context
of DNS email addresses.  I gather that an email address like
rivest@theory.lcs.mit.edu would be interpreted, lacking any local
overrides, as ( ref: DNS!! edu mit lcs theory rivest ).  This could be
written as DNS!!'s edu's mit's lcs's theory's rivest.

Now as I understand it each element in this chain is a name for a
principal, where the principal can be thought of as either a key or a
wielder of a key.  So there would be a key associated with DNS!! which
everyone would know about (the !! meaning it is a global name).  It would
have a local name "edu" which is mapped to some principal (key), which is
associated with the .edu domain.  That key would have its own mapping
between the local name "mit" and the principal or key for MIT.  That
principal would then have a mapping between the name "lcs" and a key for
that name, which would have a mapping between the name "theory" and that
key.  Finally the "theory" principal would have a mapping between
"rivest" and Ron Rivest's key.

Is this right?  It seems like a lot of keys.  And it's not clear to me
in practice who would own or control each of them.  Also, are there
some kinds of policy statements at each link in the chain to describe
what checking was done for that name binding?

Is there another way of finding the key associated with
rivest@theory.lcs.mit.edu than tracing this certificate chain, and/or
asking each of the principals along the way to verify its link?  For
example, how would a VeriSign certificate binding a key for Ron
Rivest to rivest@theory.lcs.mit.edu be written?  Could it just be
( ref: VeriSign!! rivest@theory.lcs.mit.edu )?

Hal Finney
hfinney@shell.portal.com