Return-Path: Delivered-To: apmail-incubator-river-dev-archive@minotaur.apache.org Received: (qmail 93272 invoked from network); 4 Oct 2010 12:25:55 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Oct 2010 12:25:55 -0000 Received: (qmail 39854 invoked by uid 500); 4 Oct 2010 12:25:55 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 39701 invoked by uid 500); 4 Oct 2010 12:25:52 -0000 Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: river-dev@incubator.apache.org Delivered-To: mailing list river-dev@incubator.apache.org Received: (qmail 39686 invoked by uid 99); 4 Oct 2010 12:25:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Oct 2010 12:25:51 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [89.161.231.213] (HELO v046695.home.net.pl) (89.161.231.213) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 04 Oct 2010 12:25:43 +0000 Received: from 87-205-150-195.adsl.inetia.pl [87.205.150.195] (HELO mkleczek-laptop.localnet) by xpro.home.pl [89.161.231.213] with SMTP (IdeaSmtpServer v0.70) id 1e1fea767bb6b7e5; Mon, 4 Oct 2010 14:25:20 +0200 From: Michal Kleczek Organization: XPro Sp. z o. o. To: river-dev@incubator.apache.org Subject: Re: Towards Internet Jini Services (trust) Date: Mon, 4 Oct 2010 14:25:19 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.31-22-generic; KDE/4.4.2; x86_64; ; ) References: <4C9DB5BF.8090307@zeus.net.au> <201010041354.59557.mkleczek@contour-technology.com> <4CA9C3E2.7050105@qcg.nl> In-Reply-To: <4CA9C3E2.7050105@qcg.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010041425.19581.michal.kleczek@xpro.biz> On Monday 04 of October 2010 14:09:06 Sim IJskes - QCG wrote: > On 10/04/2010 01:54 PM, Michal Kleczek wrote: > >> This is why TLS is so important. With TLS you have authentication and > >> encryption in one solution. You can configure the level of encryption > >> and the mechnisms for authentication differently for each application. > >> > >> It provides you with an end-to-end solution, so you can use any insecure > >> path you like. > > > > So you meant TLS between the client and the service in your previous > > post? But how can the client communicate with the service before > > unmarshalling the service proxy? > > Before i can start unmarshalling, i need to load the class from the > classloader. This classloader connects to the code providing server. The > classloader and server handshake, and exchange certificates. If anything > is fishy, the connection is severed, and whe only have lost the few > bytes from the handshake. Sure - I understand that. My point is actually that it requires trust relationship with the code server. In other words - for me to securely communicate with you we both have to trust a single third party (the code server). I don't want that - I just trust you but neither you nor I have the necessary infrastructure to have a trusted code server - can we still securely communicate using GMail as our code server?. Michal