[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key distribution
% Certificate chains for online resources should be stored with the
% hosts offering the resources. This includes IP certificates.
%
% Using DNS will only add yet another point of failure. Hosts
% supporting IPSP could easily support an ICMP or UDP based service
% which spits back the hosts certificate or certificate chain on
% request.
%
% DNS is useless for IPSP.
I'm not really sure that "DNS is useless for IPSP". I'm also pretty
sure that it would be nice if we could have a fairly generic key
mgmt protocol that I might be able to re-use with future hypothetical
security protocols (e.g. at the TCP layer).
Clearly the host could store its own certificate and could implement
a to-be-defined key certificate providing protocol and that would work.
It implies defining a standard protocol to use to ask a remote host
for its key certificate and to receive a response back and also getting
that protocol implemented and the implementation deployed.
However, consider that the originating host would normally
make a DNS call to do name-->IP address translation anyway. The
key certificate could be included in the same request/response and
potentially eliminate a round-trip. (Assumes that one caches
certificates just as we currently cache DNS responses; also assumes
modern systems using DNS rather than the deprecated fixed host table
file). In this case, one might just have an extension to an existing
deployed service rather than an entirely new service. It might be
easier to get folks to upgrade their bind(8) than to get/install an
entirely new service. It might be easier to tweak DNS protocol than
to design a new protocol. There are tradeoffs here and it isn't clear
to me which of the two approaches is actually better; I think it merits
further consideration of alternatives (including others that might
be devised).
Ran
atkinson@itd.nrl.navy.mil