RE: URL-level trust (was: Re: XKMS)

Mike,

If the client initially trusts a root rather than a response signing key
from an XKMS service, won't we need to add some authentication model for
XKMS response signing keys that's analgous to that of OCSP?

I wouldn't necessarily consider an "XKMS root", but rather some sort of
trust relationship... where the client is required to initialy trust the
public key of the XKMS service (which of course is analagous to a root).
Perhaps some standard mechanism to more dynamically exchange trusted keys
will evolve, which would allow a client to more easily manage multiple
"trusted relationships".  

Also, policies and trust models may very well be enforced by a root or some
sort of central entity, however, this doesn't mean the client needs have a
relationship with the root.  I think that, generally, we'll likely have many
more options regarding the structure of relationships that hold together a
trust domain... with the direction we've already headed in with XKMS.


-----Original Message-----
From: Mike Just
To: www-xkms-ws@w3c.org
Sent: 11/29/01 8:01 AM
Subject: RE: URL-level trust (was: Re: XKMS)

I think Daniel raises a good point.  However, while this may be an
ultimate goal and usage of XKMS, there exist many installments today
that have and choose to rely on one or more root (CA) certificates and
won't shift to trusting XKMS servers overnight. In addition, users will
likely not operate under a single "policy" or "trust model". So the way
you've described it, a user may have to have many XKMS roots (I'm not
saying this is bad, I'm just drawing a potential conclusion from your
statement).  I think the model of fewer roots where each root can
enforce several policies or models is also likely.
 
Mike



-----Original Message-----
From: Daniel Ash [mailto:Daniel.Ash@identrus.com]
Sent: Wednesday, November 28, 2001 5:27 PM
To: 'Yassir Elley'; www-xkms-ws@w3c.org
Subject: RE: URL-level trust (was: Re: XKMS)



I like to think of XKISS (as opposed to PKIX) as a shift in the trust
relationship... from client-to-root to client-to-trust service.  The
"initially trusted public key", therefore, would be that of the trust
service rather than a root (of course the trust service may be a root...
but the point is that the client doesn't know or care).  The client only
needs to know about a particular service... not of a PKI, or PKIs from
which hundreds of different service may be derived.  Maybe certificate
policies will become service policies.  

The trust service is not necessarily a means to delegate path
processing, revocation checking, etc, it is a means to delegate trust
decisions all together.  The trust service/client relationship would
therefore likely be 'tighter', or more specific than between a root and
a client.  I think it should be a goal of ours for the client to be
entirely ignorant of roots or any PKIX concepts altogether.       

From the trust providers' perspective I think we should focus on two
trust management technologies for use with XKMS (both of which the
client should be ignorant of): (1)PKIX, and (2)Something that doesn't
exist yet... the something that doesn't exist yet being the replacement
for X509 certificates.  Certainly, with trust managed by the
infrastructure only, there will be no need to carry trust parameters
around in a certificate.

-dan           


-----Original Message----- 
From: Yassir Elley [ mailto:yassir.elley@sun.com
<mailto:yassir.elley@sun.com> ] 
Sent: Wednesday, November 28, 2001 3:38 PM 
To: www-xkms-ws@w3c.org 
Subject: Re: URL-level trust (was: Re: XKMS) 

Hi Stephen, 

Since XKMS is meant to support a variety of underlying PKIs, 
I agree that it would be overly complex to allow the client to 
specify in the request every possible parameter for every possible 
underlying PKI. However, the concept of an initially trusted public key 
(trusted root) is probably common to every PKI. 

One suggestion is to allow the client to optionally pass the set of
trusted 
roots as part of each request and have the service use 
those public keys (or some default if no trusted roots are passed in) 
when constructing chains. However, we will still need to additionally
use service URLs 
as trust selectors for other parameters which are specific to a
particular PKI 
(like X.509 certificate policies). 

Having said that, since we are going to need service URLs as 
trust selectors anyway, and for the sake of simplicity, it is probably
adequate to use 
service URLs for both purposes (trusted roots and PKI-specific
parameters). 

-Yassir. 

Stephen Farrell wrote: 

> (Changed the subject again:-) 
> 
> Hi Yassir, 
> 
> Yes, the proposal is as you describe. Do you think that the "4th 
> root" scenario you presented is a real & common problem? (For 
> those applications likely to be xkms clients, that is.) 
> 
> This is definitely something we have to make sure we get concensus 
> on. 
> 
> Stephen. 
> 
> PS: The background to this for me, is that I'm really concerned that 
> as soon as we let "advanced" PKI concepts (e.g. n-th root CA, cert 
> policy qualifiers, PGP introducer, SPKI-tuple-thing) through the xkms 
> blood-brain barrier, then we're in danger or loosing the plot and 
> ending up with xkms being the union of all the bad/hard bits of 
> all current PKIs! An example might make this clearer: there'll be 
> an xkms nonRepudiation bit only over my dead body! :-) 
> 
> Yassir Elley wrote: 
> > 
> > I want to make sure I understand the proposal. 
> > 
> > If the underlying PKI is X.509/PKIX, I am particularly interested in

> > how the X-KISS Validate service knows which trusted public keys 
> > and certificate policies to use when constructing a certificate
chain 
> > on behalf of a certain client. 
> > 
> > I think the proposal I am hearing from members 
> > of the list is that a particular XKMS service point URL 
> > (e.g. http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential
<http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential> ) 
> > would be configured to use particular trusted public keys and
certificate 
> > policies (in this case, the bridge CA's public key and a certificate
policy 
> > of confidential) and would declare these trust semantics on some web
page. 
> > 
> > An XKMS client would have to be familiar with the trust semantics 
> > for a particular XKMS service (by going to the web pages of several 
> > XKMS services where the semantics are described) and the client
would 
> > invoke the particular service that happened to use the trust anchors
and 
> > cert policies he wanted to use. 
> > 
> > So, if a client wanted to use three particular trusted roots, they
would have to find a service 
> > that would have those three trusted roots. If they wanted to use
four trusted roots, 
> > they would have to find a different service that used those four
trusted roots. If 
> > they wanted to use four trusted roots and wanted every certificate
in the chain 
> > to have a particular certificate policy, they would have to find a
third service that 
> > supported that permutation. 
> > 
> > Is my understanding of the proposal correct? 
> > 
> > -Yassir. 
> > 
> > Stephen Farrell wrote: 
> > 
> > > All, 
> > > 
> > > I'd tend to agree that the URL level "trust" model is the thing to
go 
> > > with for xkms. 
> > > 
> > > Two further questions:- 
> > > 
> > > 1. Is there a specific issue with preventing replay of a reponse
from a 
> > > different service URL (but the same responder key etc.), or, is
there a 
> > > general issue with correlating requests and responses? That is, is
the 
> > > fix likely to be alongs the lines of "include the service URL in a
signed 
> > > response" or "include a random value in the request and that same
value 
> > > in the corresponding response" 
> > > 
> > > 2. Could anyone who disagrees with using service URLs as "trust
selectors" 
> > > or who thinks we *need* to specify a finer-granularity of
something (whether 
> > > in request or response) please speak up in the next couple of
days? 
> > > 
> > > Stephen. 
> > > 
> > > Rich Salz wrote: 
> > > > 
> > > > > You wouldn't actually need to have a different WSDL
description per URL. 
> > > > 
> > > > No, you don't HAVE to have them; I was putting too much on the
"private" 
> > > > notation made in the current spec about the service URL. 
> > > > 
> > > > I'd expect someone who was providing an outsourced service would
want to 
> > > > keep each binding in a separate file, but that's just a guess. 
> > > > 
> > > > > Either suggested approach for handling multiple trust models
would work. 
> > > > > I think the real issue is whether the folks planning to build
such 
> > > > > services believe one of them makes their life simpler.  I tend
to favor 
> > > > > the URL model, but admit this view is based on fairly limited
thinking 
> > > > > about how I might want to deploy such a system. 
> > > > 
> > > > Same here. 
> > > > 
> > > > > I can't imagine clients trying to deal 
> > > > > dynamically with what trust models are supported by a given
service. 
> > > > > Going to web page to get info on supported trust models (like
current 
> > > > > CPS docs for CAs) seems adequate to me. 
> > > > 
> > > > Agreed. 
> > > >         /r$ 
> > > > -- 
> > > > Zolera Systems, Your Key to Online Integrity 
> > > > Securing Web services: XML, SOAP, Dig-sig, Encryption 
> > > > http://www.zolera.com <http://www.zolera.com>  
> > > 
> > > -- 
> > > ____________________________________________________________ 
> > > Stephen Farrell 
> > > Baltimore Technologies,   tel: (direct line) +353 1 881 6716 
> > > 39 Parkgate Street,                     fax: +353 1 881 7000 
> > > Dublin 8.               mailto:stephen.farrell@baltimore.ie
<mailto:stephen.farrell@baltimore.ie>  
> > > Ireland                            http://www.baltimore.com
<http://www.baltimore.com>  
> 
> -- 
> ____________________________________________________________ 
> Stephen Farrell 
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716 
> 39 Parkgate Street,                     fax: +353 1 881 7000 
> Dublin 8.               mailto:stephen.farrell@baltimore.ie
<mailto:stephen.farrell@baltimore.ie>  
> Ireland                            http://www.baltimore.com
<http://www.baltimore.com>  

Received on Thursday, 29 November 2001 10:36:30 UTC