W3C home > Mailing lists > Public > www-xkms@w3.org > December 2003

Re: Resolution - XKMS and SOAP Message Security tokens

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 19 Dec 2003 14:00:20 +0000
Message-ID: <3FE30474.7010407@cs.tcd.ie>
To: Frederick.Hirsch@nokia.com
Cc: www-xkms@w3.org

Grand so.

Frederick.Hirsch@nokia.com wrote:
> 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 09:04:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:41 UTC