[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIPP and SKIP. 2 subjects.
Ashar Aziz says:
> In designing this scheme, one of the things that I came to
> realize was that although one could negotiate many things easily,
> the public-key algorithm in the certificate was not one of them.
> Ultimately, certificates become part of the infrastructure, and
> negotiating a different infrastructure is quite difficult in
> practice.
You are assuming people will even necessarily have certificates. I
think its a good bet that they will, but many people would like to
extend the use of kerberos on their LANs to do IPSP key
negotiation. I, for one, have sympathy for this notion, and don't want
to make it impossible, although I think that in an inter-organization
application it isn't practical. Some might say that we should not make
these provisions because they will lead to an inability of different
groups to interoperate, but this denies the reality that protocols
evolve through time -- 1984 TCP is not well behaved in a 1994 TCP
environment (no slow start or Van J's algorithm), and the same goes
for almost everything else in our protocol suite. Certainly we need to
mandate some base functionality, but it is not at all unreasonable for
consenting hosts to go beyond it.
Furthermore, from my perspective, I do not think that SKIP or *ANY* of
the protocols proposed thus far is, on its own as proposed,
sufficient. Even ignoring the whole question of management system
selection, there are lots of issues like naming that haven't been
properly addressed.
I agree that it is difficult to choose a new infrastructure once one
is built. That is why I am suggesting that the infrastructure we build
not exclude possible future key management technologies.
Perry
PS. Cryptographic algorithms and the like are the BEST understood part
of our problem. Our difficulty is not in picking a clever and fast
cryptographic algorithm but in embedding it within a good set of
conventions for how to use it, or alternatives to it.
References: