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:32:55 UTC