[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue
Jerry, It was my understanding that this text is going in Section 3.2 of the UsernameToken Profile and not the core. Blake Dournaee Senior Security Architect Sarvega, Inc. http://www.sarvega.com/ -----Original Message----- From: Jerry Schwarz [mailto:email@example.com] Sent: Monday, January 12, 2004 1:02 PM To: NISHIMURA Toshihiro; firstname.lastname@example.org Subject: Re: [wss] HMAC Key Derivation in UsernameToken Profile Issue At 07:00 PM 1/9/2004, NISHIMURA Toshihiro wrote: >Blake, > >I agree. Something should be mentioned about key derivation. > >Section 7.1 of the core spec says about <wsse:SecurityTokenReference> >element as follows and our current discussion is about this case: >| This element can be used as a direct child of <ds:KeyInfo> to >| indicate a hint to retrieve the key information from a security >| token placed somewhere else. > >So, how about including sentenses such as: > When a UsernameToken is referenced from <ds:KeyInfo> element, > it can be used to derive a key. The detail will be specified > elsewhere. > (Please give us better English wording!) >in Section 3.2 of UsernameToken profile? I don't like it. If we want to specify the use of UsernameToken to define a key then we should do so in the UsernameToken profile, not in the core. The sentence above would be just as valid if it began "When a security token is referenced ..." In other words it is essentially vacuous. >Now, I wonder about other tokens: > When SAML Token is references from <ds:KeyInfo>, what does it mean? > Should we say something about it in SAML Token profile? If we want to specify it then yes it needs to go in the SAML Token profile. >--- >Toshi > > >At Fri, 09 Jan 2004 10:43:12 -0800, >Blake Dournaee wrote: > > All, > > > > This comment by Srinivas echoes my sentiments exactly. We should say > > something about key derivation for the Username Profile, even if it is > > to say that it is specified elsewhere. Not all developers may be > > familiar with the WS-I BSP at first and this issue is a major > > interoperability stumbling block if left open. > > > > Blake Dournaee > > Senior Security Architect > > Sarvega, Inc. > > http://www.sarvega.com/ > > > > > > -----Original Message----- > > From: Srinivas, Davanum M [mailto:Davanum.Srinivas@ca.com] > > Sent: Friday, January 09, 2004 5:05 AM > > To: Anthony Nadalin; email@example.com > > Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue > > > > Anthony, Team, > > > > My 2 cents...We should address this issue in WSS-TC as there is already > > a precedent (WSE 2.0 Tech Preview) and is one of the first stumbling > > blocks a customer would face when doing an interop. A customer will find > > that 2 toolkits claiming to support the same version of the WSS spec and > > profiles from OASIS will NOT work out of the box and the customer will > > find out that he needs to request information from the Vendors about not > > just WSS spec compliance, but also WS-I BSP compliance which will reduce > > the importance of this spec. > > > > thanks, > > dims > > > > PS: FYI, i ran into this in may of last year, see attached email on how > > difficult it was to get details if the spec is not complete. > > > > _____ > > > > From: Anthony Nadalin [mailto:firstname.lastname@example.org] > > Sent: Thursday, January 08, 2004 9:12 PM > > To: email@example.com > > Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue > > > What do others think? I still feel strongly that this issue is a bane > > on interoperability for the Username Token profile. > > > > It seems like this would be best handled by the WS-I BSP since there are > > many different mechanisms that could be used. Now is the prime time > > to bring this up since we are in early phase of the BSP. > > > > Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 > >To unsubscribe from this mailing list (and be removed from the roster of >the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou p.php. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup .php.