river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: Towards Internet Jini Services (trust)
Date Mon, 04 Oct 2010 15:49:54 GMT
I think that we need to decide what the requirements are?  Anyone else thinking this?  NSA
has a tee shirt saying, "We trust in trust".

Sent from my iPhone

Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365

On Oct 4, 2010, at 5:04 AM, Sim IJskes - QCG <sim@qcg.nl> wrote:

> 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

View raw message