RE: XKMS

Mike,
 
    Good question, one that the spec does not answer at the moment. It would
appear that each service would have to have a separate key, can't be a good
plan eh?
 
    This would appear to argue for some form of trust model identifier in
the signed response. [c.f. the PKCS#1 hash algorithm OID]
 
    The URL of the service would be one approach, some form of service
selector would be another.
 
    The advantage of the different URL approach is that it is simplest
(which is why my co-authors told me to do it that way). The disadvantage is
that it might well just shift the complexity into the WSDL field - who wants
16 different profiles for different varieties of the same service?
 
    The other approach would be to allow the trust model id to be specified
in the request. This then introduces a couple of issues, like how does the
client know what trust models are supported or what they do for her? Should
we add in a query function on the trust models? That would allow the user to
select the degree of trust using a selector dial like a tuning knob on their
handheld (set phasers to VTN class 3).
 
        Phill
 

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


-----Original Message-----
From: Mike Just [mailto:Mike.Just@entrust.com]
Sent: Monday, November 26, 2001 2:15 PM
To: Hallam-Baker, Phillip
Cc: www-xkms-ws@w3c.org
Subject: RE: XKMS



Hi Phill, 

I've heard the proposal for use of "multiple XKMS service point URLs"
before, and always have the same question: Unless the URL (or other "trust
model" identifier) is securely contained in the response, how does the
client know that the correct "trust model" was enforced for their request?
I.e. what stops an attacker from redirecting a request from the "classified"
to "confidential" service point you use in your example below? 

Mike 


> -----Original Message----- 
> From: Hallam-Baker, Phillip [ mailto:pbaker@verisign.com
<mailto:pbaker@verisign.com> ] 
> Sent: Monday, November 26, 2001 11:58 AM 
> To: 'Denis Pinkas'; Hallam-Baker, Phillip 
> Cc: ietf-pkix@imc.org 
> Subject: RE: XKMS 
> 
> 
> All, 
> 
>       The Working Group is currently working on a version 2.0 
> of the XKMS 
> spec. It is (currently) functionally and structurally 
> identical to 1.1 but 
> has a number of important revisions to the schema. These 
> align the schema 
> more closely with the new XML Signature schema and SAML and 
> make for much 
> better extensibility. The other major change is to the 
> structure of the 
> Register function which previously combined 4 functions that 
> are now broken 
> out into separate calls. 
> 
>       To answer Denis' point, XKMS does not define a trust 
> model, the XKMS 
> service defines its own trust model. The client is delegating 
> the definition 
> and concept of trust, not merely the mechanics of processing 
> the trust. 
> 
>       This has lead to debate over whether XKMS should 
> support multiple 
> trust models, so that the client could choose between them. 
> At present this 
> is possible by introducing multiple XKMS service point URLs, e.g. 
> 
>       http://xkms.xmltrustcenter.org/vtn_class_1
<http://xkms.xmltrustcenter.org/vtn_class_1>  
>       http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential
<http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential>  
>       http://xkms.xmltrustcenter.org/us_gov_bridge_ca_classified
<http://xkms.xmltrustcenter.org/us_gov_bridge_ca_classified>  
>       http://xkms.xmltrustcenter.org/bal_keyserver
<http://xkms.xmltrustcenter.org/bal_keyserver>  
> 
>       Philosophically, the reason for taking this approach is 
> that real 
> world trust relationships tend to turn out to be slightly 
> more complex than 
> whatever closed form declarative mechanism is available to 
> describe them - 
> until the closed form becomes turing complete. 
> 
>       It is a separation of concerns issue, by avoiding any 
> commitment on 
> the issue XKMS can support trust models that would probably 
> be impossible to 
> specify completely in a standards forum - providing a bridge 
> CA across the 
> VTN, the federal Bridge CA and BAL's PGP keyserver for 
> example. While a 
> perfectly good and usefull trust service could easily be 
> configured for 
> limited purposes any attempt to completely specify how to 
> interoperate PGP 
> and PKIX for all applications, cert issuers etc. is probably 
> a futile task. 
> 
>       As Steve said, this is the sort of issue we will be 
> debating on the 
> WG list. 
> 
>               Phill 
> 
> Phillip Hallam-Baker FBCS C.Eng. 
> Principal Scientist 
> VeriSign Inc. 
> pbaker@verisign.com 
> 781 245 6996 x227 
> 
> 
> > -----Original Message----- 
> > From: Denis Pinkas [ mailto:Denis.Pinkas@bull.net
<mailto:Denis.Pinkas@bull.net> ] 
> > Sent: Thursday, November 22, 2001 4:59 AM 
> > To: Hallam-Baker, Phillip 
> > Cc: ietf-pkix@imc.org 
> > Subject: Re: XKMS 
> > 
> > 
> > Phill, 
> > 
> > I have XKMS Draft Version 1.1 draft 4. January 30 th, 2001. 
> > 
> > Since the document advertises at a bottom of a page an amendment 
> > for a version 1.2, is there a more recent document available ? 
> > 
> > Is there a document that explains in a few pages the philosophy 
> > besides XKMS in particular in terms of the trust model when 
> > multiple trust points are used (i.e. multiple self-signed 
> > certificates) ? 
> > 
> > Here is a related question: Does XKMS make a difference 
> > between the name 
> > of an entity certified by CA1 and the same name certified by CA2 ?  
> > 
> > Thanks. 
> > 
> > Denis 
> >  
> > > > Now I don't think that the folks working on XML-DSIG 
> and XKMS are 
> > > > really doing it better. There's also the tendency to be most 
> > > > flexible by integrating as many PKI standards as 
> > possible. Same old 
> > > > problems... 
> > > 
> > > I think you are misunderstanding what we are doing. XKMS is an 
> > > interface to a PKI. It is not by itself a PKI. 
> > > 
> > > Although it is quite possible to use XKMS in a network of 
> peer-peer 
> > > real time responders without the support of a backing PKI the more 
> > > usual configuration would be as an interface to a PKI. In 
> most cases 
> > > that PKI would be PKIX based. 
> > > 
> > > The observations that the design of XKMS is based upon are: 
> > > 
> > > 1) Despite every effort, most developers hate, loathe and 
> > detest ASN.1 
> > > 2) Client developers complain that PKIX is too complex to 
> implement. 
> > > 3) We continue to add to the PKIX specification. 
> > > 4) Implementation suggests that inter-organizational trust 
> > justifies the 
> > >         complexity of PKIX. 
> > > 5) XML based applications have a different risk profile 
> to the email 
> > >         messaging applications that X.509 was originally 
> intended to 
> > >         support. 
> > > 
> > > The point is that we have come a long way in 10 years and 
> there are 
> > > occasions when the thing to do is to attack a problem from 
> > a different 
> > > angle for a while. I find it very unhelpful for people to start 
> > > throwing arround the 'do you think you know better' question. 
> > > Clearly the people who put that question think they know better 
> > > or they would not have asked it. 
> > > 
> > > Anyway, the proposal to form an XKMS working group is currently 
> > > before the W3C AC reps. The first face to face is planned for 8th 
> > > December in Salt Lake city. It is an open meeting. 
> > > 
> > >         Phill 
> > 
> 
>