Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Michal Kleczek <michal.kleczek@xpro.biz>
Organization: XPro Sp. z o. o.
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (trust)
Date: Tue, 5 Oct 2010 13:52:32 +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> <4CAB06F7.60407@zeus.net.au>
 <4CAB0BB6.6040605@qcg.nl>
In-Reply-To: <4CAB0BB6.6040605@qcg.nl>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201010051352.33212.michal.kleczek@xpro.biz>

Hmm...

1. I am not really sure if you need to mess with classloader to achieve that.
Wouldn't something I proposed earlier allow you to postpone unmarshalling to 
after you made your trust decision?

2. I am not sure either whether principal based trust decisions is not enough 
as a basis for certification friendliness - isn't it just a matter of either:
a) dynamic retrieval of certified principals from a trusted certification 
service
b) in its simplest form just require the service to authenticate and rely on 
authentication mechanism to keep track of certified principals (IOW x509 
certificates get revoked or kerberos principals removed from KDC)
c) require ProxyTrust to authenticate not as a target service principal but as 
a certifying authority principal - IOW proxy verification is not implemented by 
the service itself but rather delegated by the service to a third party.

Michal

On Tuesday 05 of October 2010 13:27:50 Sim IJskes - QCG wrote:
> On 10/05/2010 01:07 PM, Peter Firmstone wrote:
> > Yes I think Sim is talking about making trust decisions and Michal and I
> > are talking about the handshake, we need both, I don't think we're
> > having an issue of agreement, just understanding.
> 
> No, i'm talking about both.
> 
> Before you can unmarshall, you need code. This code is loaded by a
> classloader. The ONLY place where we can check code, is this classloader.
> 
> For every trust decision i've made, the classloader should check if what
> is loaded is consistent with the trust decision i've made.
> 
> I want this trust system to be exclusive. Only when trust is granted am
> i willing to perform code i have been given.
> 
> I want this trust system to be dynamic. I want to be able to change my
> mind.
> 
> I want this trust system to be automated only in removing trust. I dont
> want to have a machine surprise me by downloading a trojan.
> 
> I want this system to be certification friendly. So not only based on
> Principal alone.
> 
> Eh, would this constitute a requirements definition? :-)
> 
> Gr. Sim