On 10/04/2010 01:42 PM, Michal Kleczek wrote:
A possible solution might be, to enforce code download to use TLS and
verify if the othersides ceritificate matches the downloaders trustlist.
We can extends this by enforcing the downloaded jars/classes to be
signed with a similar certificate.
A "once bitten measure" could be, if a server violates this rule, it
will automatically be taken of the trustlist.
I am not sure how it would bring me closer to "The Ultimate Goal" which is to
make it possible for two parties to securely communicate without relying on
third parties being trusted or even related with the two parties in any way
regarding trust - but still allow _using_ those untrusted third parties to
exchange information.
You don't need to trust a third party. If i have got your certificate in
my trustlist, and i trust you to do the right thing, i can download your
code and execute it whenever i want it. And i can continue doing this,
as long as i trust you or your organisation.
I can also delegate this trust to the 'apache foundation jini code
clearing house' for instance and trust that if you abuse this trust,
someone from the crowd will inform the clearing house, and they revoke
their trust.
The only thing that we need, for environments where certification is
important, that we allow for specific baselines to be trusted by a
clearinghouse (for example the cerification organisation). So that if a
malicious party provides an update, with malicious code inserted, the
new certificate+codehash does not match an existing entry in my trustlist.
Gr. Sim
