W3C home > Mailing lists > Public > www-xkms-ws@w3.org > November 2001

URL-level trust (was: Re: XKMS)

From: Stephen Farrell <stephen.farrell@baltimore.ie>
Date: Wed, 28 Nov 2001 10:21:37 +0000
Message-ID: <3C04BAB1.CB249688@baltimore.ie>
To: Yassir Elley <yassir.elley@sun.com>
CC: Rich Salz <rsalz@zolera.com>, Blair Dillaway <blaird@microsoft.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, Mike Just <Mike.Just@entrust.com>, www-xkms-ws@w3c.org

(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)
> 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
> >
> > --
> > ____________________________________________________________
> > 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
> > Ireland                             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
Ireland                             http://www.baltimore.com
Received on Wednesday, 28 November 2001 05:21:25 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 13:51:42 EDT