RE: Resolution - XKMS and SOAP Message Security tokens

Stephen,

I think there is a point of confusion - the WS-I would profile down to SecurityTokenReference 
(not ds:RetrievalMethod). SecurityTokenReference allows a variety of reference mechanisms (direct via uri, identitier appropriate to token, embedded).

Communication to the XKMS server could use any ds:KeyInfo mechanism supported by the XKMS spec and server, assuming the client could translate to it.

so I think we are saying the same thing about the client putting the ds:KeyInfo directly into the request.



regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones




> -----Original Message-----
> From: ext Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Friday, December 19, 2003 8:34 AM
> To: Hirsch Frederick (NMP-MSW/Boston)
> Cc: www-xkms@w3.org
> Subject: Re: Resolution - XKMS and SOAP Message Security tokens
> 
> 
> 
> Frederick,
> 
> Fine summary. One nit/query though:
> 
> If ws-i profiled down to a MUST be ds:RetrievalMethod, does that
> mean that (modulo caching and lucky local references) each request
> to the xkms responder requires it (the responder) to issue a
> related outgoing request to resolve the ds:KeyInfo? If so, I
> wouldn't like that from the anti-DoS point of view, or maybe
> I'm confused?
> 
> Basically, I'd like to see the default case being that the SOAP
> aware xkms client puts the actual KeyInfo (cert or key or
> whatever) directly into the xkms request.
> 
> Stephen.
> 
> Frederick.Hirsch@nokia.com wrote:
> > At today's XKMS call we discussed this issue, and came to 
> the following 
> > conclusions.
> >  
> > 1. Clients can map SOAP Message Security SecurityTokenReferences 
> > contained in ds:KeyInfo and associated SOAP Message 
> Security tokens to a 
> > ds:KeyInfo format acceptable to XKMS server using 
> ds:KeyInfo definitions.
> >  
> > 1b. Necessary extensions to ds:KeyInfo will be addressed by 
> the W3C in 
> > the future, but common forms like X.509 should not be a problem now.
> >  
> > 2. Because of this approach, potential profiling by WS-I 
> restricting the 
> > use of ds:RetrievalMethod in a SOAP Message Security 
> ds:KeyInfo context 
> > should not be an issue.
> >  
> > 3. Deeper thought and further exploration of such issues, including 
> > Kerberos token processing, may be considered later as part of XKMS 
> > rechartering after the current work is completed.
> >  
> > If I captured this correctly and there is no objection to this 
> > resolution, I will share this resolution with the Oasis WSS 
> TC and the 
> > WS-I Basic security profile group.
> >  
> > thanks
> > 
> > regards, Frederick
> > 
> > Frederick Hirsch
> > Nokia Mobile Phones
> > 
> > 
> >     -----Original Message-----
> >     *From:* ext [mailto:Frederick.Hirsch@nokia.com]
> >     *Sent:* Friday, December 12, 2003 3:21 PM
> >     *To:* www-xkms@w3.org
> >     *Cc:* wsi_secprofile@lists.ws-i.org; wss@lists.oasis-open.org
> >     *Subject:* [wsi_secprofile] XKMS and SOAP Message 
> Security tokens
> > 
> >     The Oasis WSS technical committee [1] is producing a 
> specification
> >     that outlines how XML Digital Signature and XML 
> Encryption may be
> >     used in the context of SOAP messaging to provide integrity,
> >     confidentiality and origin authentication.
> >      
> >     Part of this work has involved defining new methods for 
> conveying
> >     key information within ds:KeyInfo, specifically, defining a
> >     SecurityTokenReference element that allows a URI reference to a
> >     security token in the SOAP header, this token being 
> used to convey
> >     key information, for example. This specification allows 
> but does not
> >     encourage other uses of KeyInfo to carry keys.
> >      
> >     A SecurityTokenReference may provide a direct reference, very
> >     similar to RetrievalMethod, with URI and Type. A 
> difference is that
> >     the SecurityTokenReference has an id attribute. A
> >     SecurityTokenReference may also provide a key 
> identifier reference, 
> >     allowing  a reference to tokens that do not support an 
> id attribute.
> >     This has no analog in the XML Sig recommendation. A
> >     SecurityTokenReference may also contain an embedded token, one
> >     within it, and in conjunction with a STR Dereference transform
> >     (Security Token Reference Dereference Transform) this allows
> >     references to the SecurityTokenReference's content itself.
> >      
> >     Thus the SecurityTokenReference provides an extensible means of
> >     referencing key information, allowing possibilities not directly
> >     defined in the XML Signature recommendation. The SOAP Message
> >     Security specification also allows for binary security 
> tokens that
> >     may carry keys, providing an extensible means to convey 
> keys in a
> >     security header. An example is an X509 binary token type.
> >      
> >     In discussion at WS-I [2] is the possibility of 
> disallowing certain
> >     methods of conveying keys, such as ds:RetrievalMethod within a
> >     ds:KeyInfo, in favor of supporting SecurityTokenReferences.
> >      
> >     While it seems reasonable to expect to use an XKMS 
> XKISS service to
> >     validate tokens, for example X509 binary security tokens,  will
> >     requiring KeyInfo to use SecurityTokenReferences in 
> conjunction with
> >     security tokens make this difficult with existing or 
> planned XKMS
> >     implementations?
> >      
> >     This raises some questions about the XKMS recommendation [3]
> >      
> >     1. Does it make sense to use an XKMS server to validate key
> >     information associated with SOAP Message Security signatures?
> >     If so, does XKMS require a ds:KeyInfo to be conveyed to 
> the server,
> >     or can an arbitrary security token as defined in SOAP Message
> >     Security (or one of its token profiles) be conveyed as well?
> >      
> >     2. Is there anything to preclude an XKMS implementation from
> >     supporting processing of SecurityTokenReferences within
> >     a ds:KeyInfo. or processing security tokens from a SOAP 
> header block?
> >      
> >     Specifically, should KeyBindingAbstractType (Section 5.1.1) be
> >     extended to allow a BinarySecurityToken (or other 
> security token) to
> >     be conveyed in addition to KeyInfo? Should this type allow
> >     extensibility?
> >      
> >     Second, is the UseKeyWith table in 5.1.3 the correct 
> place to define
> >     identifiers corresponding to WSS security tokens, indicating for
> >     example the soap message security application with an 
> x509 token...
> > 
> >     regards, Frederick
> > 
> >     Frederick Hirsch
> >     Nokia Mobile Phones
> > 
> >     [1] http://www.oasis-open.org/apps/org/workgroup/wss/
> > 
> >     [2] http://www.ws-i.org/
> > 
> >     [3]  http://www.w3.org/TR/xkms2/
> > 
> >      
> > 
> >      
> > 
> >      
> >      
> > 
> > 
> >      
> 
>

Received on Friday, 19 December 2003 08:46:36 UTC