RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue

[Jerry Schwarz <jerry.schwarz@oracle.com>]

At 01:05 PM 1/12/2004, Blake Dournaee wrote:
>Jerry,
>
>It was my understanding that this text is going in Section 3.2 of the
>UsernameToken Profile and not the core.

My bad. I saw the 7.1 section reference and though it was being proposed 
for that.


>Blake Dournaee
>Senior Security Architect
>Sarvega, Inc.
>http://www.sarvega.com/
>
>
>-----Original Message-----
>From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]
>Sent: Monday, January 12, 2004 1:02 PM
>To: NISHIMURA Toshihiro; wss@lists.oasis-open.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; wss@lists.oasis-open.org
> > > 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:drsecure@us.ibm.com]
> > > Sent: Thursday, January 08, 2004 9:12 PM
> > > To: wss@lists.oasis-open.org
> > > 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.