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

I don't see the problem that Yassir is raising.

The idea of XKMS is that the client is delegating the concept, idea,
definition, implementation, understanding, comprehension and gestalt of the
trust relationship.

There is no XKMS language to allow the client to describe what the client
understands as 'trust'.

I don't believe that the client dictates security policy scenario is
realistic. I have never known an enterprise, still less a government
organization where individual end users decide the security policy for
themselves.

If the need arises to bridge across multiple trust configurations in the
manner described it is almost certain to arise at the organizational level
and not the whims of the individual end user. contrawise if the case arises
in which some more complex trust association configuration is desirable it
would be easily (and best) supported by means of an individual service port
for that user (URLs are cheap) and some sort of Web browser based GUI-ish
configuration panel.

		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Wednesday, November 28, 2001 5:22 AM
> To: Yassir Elley
> Cc: Rich Salz; Blair Dillaway; Hallam-Baker, Phillip; Mike Just;
> www-xkms-ws@w3c.org
> Subject: URL-level trust (was: Re: XKMS)
> 
> 
> 
> (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
>