Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4EFC5D51.5050302@qcg.nl>
Date: Thu, 29 Dec 2011 13:30:09 +0100
From: Simon IJskes - QCG <simon@qcg.nl>
Organization: Quality Consultancy Group b.v.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: WOT: trust bootstrapping
References: <4EF98422.6090401@qcg.nl> <4EFBBF65.7000305@zeus.net.au>
  <4EFC3913.4030309@qcg.nl> <1325159198.2424.11.camel@Nokia-N900-51-1>
In-Reply-To: <1325159198.2424.11.camel@Nokia-N900-51-1>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 29-12-11 12:46, Peter wrote:

> By self signing your own certificates, the people at the other end still need a way to id you're cert.
> This is the hardest part of cryptography to solve.
> There may not always be a user or person on the other end, so there needs to be a programmatic alternative also.

Yes, this problem is what i tried to adress, or to avoid, by stating:

> One could have the trustmanager offer the unknown certificate for
> acceptance to the user, in order to allow authentication via external
> channels.

Authenticating the self signed certificate by electronic means from 
within the jini domain is unsolveable imho. Thats why i want to leave it 
up to the implementor of the application to solve the problem. User 
interfaces like bluetooth authentication spring to mind. The 
authentication problem is quite similar to bluetooth.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397