OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Summary of issue 3 changes ( was RE: [ws-sx] issue 003: use of the term binding in SecurityPolicy )


On the Feb 8th call, I got an action to summarize the agreed changes
related to issue 3. Here is that summary;

Line 228 - Add "Note that services might accept messages containing more
tokens than those specified in policy" as a second sentence.

Line 229 - Change to read "Any necessary key transport mechanisms"

Line 230 - Change to read "Any required message elements (e.g.
timestamps) in the wsse:Security header."

Line 233 - Remove this bullet.

Add a new bullet ( after line 232 ) that reads;

"Various parameters, including those describing the algorithms to be
used for canonicalization, signing and encryption."

Cheers

Gudge

	

> -----Original Message-----
> From: Martin Gudgin 
> Sent: 08 February 2006 06:40
> To: 'Prateek Mishra'
> Cc: ws-sx@lists.oasis-open.org
> Subject: RE: [ws-sx] issue 003: use of the term binding in 
> SecurityPolicy
> 
> Prateek,
> 
> Thanks for the response. My comments are inline prefixed with [MJG].
> 
> Regards
> 
> Gudge
> 
> > -----Original Message-----
> > From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
> > Sent: 06 February 2006 22:29
> > To: Martin Gudgin
> > Cc: ws-sx@lists.oasis-open.org
> > Subject: Re: [ws-sx] issue 003: use of the term binding in 
> > SecurityPolicy
> > 
> > Hi Martin,
> > 
> > Responses to your note are delimited by XML style 
> delimiters with my 
> > <initials>
> > 
> > >
> > >Regarding Security Binding Property, I note that the title 
> > of Section 6
> > >(line 1242) is 'Security Binding Properties'.
> > >  
> > >
> > <PM>  Agreed, this section does describe properties of security 
> > bindings. </PM>
> 
> [MJG]
> OK. Sounds like we are in agreement here.
> 
> > 
> > >Regarding Security Binding Property Assertion, I note that several
> > >assertions in section 7 indicate that they set property values, e.g
> > >lines 1514, 1517, 1584, 1587, 1590, 1592, 1594, 1596, 1598 et.al.
> > >
> > >  
> > >
> > <PM>  My comment is  that the term "Security Binding Property 
> > Assertion" 
> > does not occur in anywhere
> > in the text. So I am not really sure it helps when reading 
> > the document.
> > 
> > It is interesting to note that all of the usages
> > you cite take the form "Such-and-such assertion populates the 
> > following 
> > property" or "this assertion sets the following
> > property to true". I would leave it up to the TC if they feel 
> > this term 
> > should be retained as it does not receive any use.
> > </PM>
> 
> [MJG]
> I guess my reasoning was that given we had a section called 
> Security Binding Properties, assertions that set those 
> properties would naturally be known as Security Binding 
> Property Assertions. However, if the TC wants to remove the 
> term, I'm not too concerned.
> 
> > 
> > >Regarding the proposed change at line 228, I think this 
> change is OK,
> > >although I'm not certain quite how it differs materially from the
> > >existing text. Please could you clarify what it is you think 
> > is allowed
> > >and/or precluded by your proposed text vs the existing text?
> > >  
> > >
> > <PM> I could not follow what was meant by "minimum set of 
> tokens that 
> > will be used"; is there also a
> > "maximum set of tokens"? If so, how/where is this set described?
> > 
> > This point is mostly editorial so I will leave it at that.</PM>
> 
> [MJG]
> Ah, I think I see the difference. My understanding is that 
> WS-SecurityPolicy defines the minimum (security) requirements 
> for communicating with the service. Clients may choose to do 
> more than the minimum. Some services might accept messages 
> that do more than the minimum. Some might not. For example, 
> with respect to tokens, the service might state a requirement 
> for, say, a Kerberos Protection Token, the client may choose 
> to also provide some form of supporting token.
> 
> > 
> > >Regarding the proposed change at line 229, I believe an 
> encrypted key
> > >token from WSS 1.1 would be such a mechanism. For example, 
> Symmetric
> > >binding with an X509TOken as the [Protection Token].
> > >  
> > >
> > <PM> The standard term for this is "Key Transport" and not "Key 
> > transfer". I would prefer we use the former.
> > </PM>
> 
> [MJG]
> OK. So the bullet at line 229 should read;
> 
> 	"Any necessary key transport mechanisms"
> 
> > 
> > >Regarding the proposed change at line 230, did you mean add 'in the
> > >wsse:Security header'? If not, I don't think I understand 
> > the proposed
> > >change.
> > >  
> > >
> > <PM> Yes, your reading is what I meant. </PM>
> 
> [MJG]
> Great. So the new text (at line 230) should read;
> 
> 	"Any required message elements (e.g. timestamps) in the 
> wsse:Security header."
> 
> 
> > 
> > >Regarding the proposed change at line 233, I'm inclined to 
> > agree as the
> > >signature confirmation aspect of an exchange is covered by 
> the WSS11
> > >assertion.
> > >  
> > >
> > <PM> My concern was that "correlation of messages" could be 
> > interpreted 
> > much more broadly to topics covered
> > under reliable messaging or other messaging protocols</PM>
> 
> [MJG]
> OK. Sounds like we should remove this bullet (line 233) then.
> 
> > 
> > >Regarding the proposed additional text, would 'canonicalization' be
> > >better than 'normalization'?
> > >
> > >  
> > >
> > <PM> Yes, that would improve the proposed text </PM>
> 
> [MJG]
> Great. So we should add a new bullet after line 232 that reads;
> 
> 	"Various parameters, including those describing the 
> 	algorithms to be used for canonicalization, signing and 
> encryption."
> 
> > 
> > >Cheers
> > >
> > >Gudge
> > > 
> > >
> > >  
> > >
> > >>-----Original Message-----
> > >>From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
> > >>Sent: 27 January 2006 18:46
> > >>To: ws-sx@lists.oasis-open.org
> > >>Subject: [ws-sx] issue 003: use of the term binding in 
> > SecurityPolicy
> > >>
> > >>At the F2F, I had asked a question about the use of term security 
> > >>binding in Security Policy
> > >>and as to what was intended by use of this term. My 
> > comments here are 
> > >>limited to this issue.
> > >>
> > >>The policy document does include a definition for this term 
> > >>in Section 
> > >>1.4, 2.3 (definition
> > >>at an abstract level) and a more precise definition for 
> > >>security binding 
> > >>assertion in Section 7.
> > >>
> > >>(1) The terms Security Binding Property and Security 
> > Binding Property 
> > >>Assertion are defined in lines 76 and 79-80
> > >>but not otherwise used elsewhere. I would suggest these terms 
> > >>be removed.
> > >>
> > >>(2) proposed changes to Security Binding defiinition (Section 2.3)
> > >>
> > >>lines 227 - 234 provide a detailed definition of binding. I would 
> > >>propose the following changes:
> > >>
> > >>line 228: replace by "The set of acceptable tokens and 
> the means of 
> > >>their binding to messages"
> > >>
> > >>line 229:  I dont see any "key transfer" mechanisms described 
> > >>in any of 
> > >>the bindings. In any case, I dont
> > >>understand what "key transfer" means and it isn't listed in 
> > >>my copy of 
> > >>the handbook of applied crypto.
> > >>
> > >>line 230: Add "in the SOAP header"
> > >>
> > >>line 233: Delete. I dont believe any of the bindings 
> > >>described in this 
> > >>document provide this facility.
> > >>
> > >>Add new line: Various parameters, including those describing the 
> > >>algorithms to be used for normalization, signing and encryption.
> > >>
> > >>--------------------------------------------------------------
> > >>-----------------
> > >>prateek
> > >>
> > >>
> > >>    
> > >>
> > >
> > >  
> > >
> > 
> > 
> > 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]