[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of DNS to distribute keys
Please forgive the repost, somehow the "l" got left off of
nic.ddn.mil in the first version. Ain't cut-and-paste wonnerful?
========
Forgive the "undergraduate question", but why propose using
the DNS for this when one could just contact the host in
question and ASK for the key/certificate? As I understand
it the choice is between:
A1: Client asks DNS for IP address of server.
A2: Client asks DNS for key/certificate of server.
A3: Client does some client-server transaction with server.
vs
B1: Client asks DNS for IP address of server.
B2: Client asks SERVER for key/certificate of server.
B3: Client does some client-server transaction with server.
For awhile I thought the point was relieving the server of
maintaining its PUBLIC key (in the case of really dumb servers
like laserprinters or something) but given the fact that the
server has to maintain its PRIVATE key in order to evaluate
any incoming transaction, it is not really much more expensive
for it to maintain its PUBLIC key too, since in current
implementations PRIVATE keys are usually somewhat longer than
PUBLIC keys.
Defining some kind of additional TCP or UDP based protocol by
which a client can obtain a public key from a server would also
have the advantage of putting control of key policy in the hands
of the server. For example, a really high-security server might
want to generate a completely new one-time public/private key
pair on the fly for every new transaction.
The only disadvantage I can see with this is that the server
would have to be up and running in order for client to obtain
the key information, as opposed to working with the expectation
that the omnipresent DNS would "always" be able to give this
information. But note: SMTP also requires the destination host
to be up and running, we don't really have any store-and-forward
protocols running on this network.
Am I missing some key point in this?