cdr wrote:
Here is a recent paper related to Key Continuity:
http://www.simson.net/ref/2005/johnny2_usenixsecurity05_submited.pdf
The mistake was made when it was decided that the browser security
solutions will be based exclusively on the "trusted third party" (TTP)
model. It is now obvious that no third party can be trusted in all
circumstances, there are circumstances in which no third party can be
trusted, and there is a murky world in-between with many circumstances
in which TTP model alone just does not perform to our satisfaction.
It is time to accept the obvious: Key Continuity Management (KCM) and
TTP are not exclusive but complementary: both have their place in the
"real world" and both should be supported by a browser.
If you believe that, you should design and propose a standard protocol
that can support KCM and propose it to the IETF . The model of X.509
certs supported by the SSL protocol and RFC3280 cert path validation as
it exists today is not compatible with KCM . Implementing KCM with X.509
and SSL (or S/MIME, as in the paper referenced) would be a violation of
the standards, as it would cause the application to produce errors in
cases the standards state are valid . There are very legit reasons for
changing cert and key, such as to increase security if the old key has
been compromised, or if you simply want a larger key size because you
think the key has become crackable. The KCM model breaks apart in those
cases. The X.509 model has revocation to deal with them.
I browsed through the KCM document and IMO it does not solve the problem
of man-in-the-middle attacks. TTP is not perfect, but has revocation to
recover from mistakes - what does KCM have ?
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
