- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Fri, 19 Dec 2003 14:00:20 +0000
- 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