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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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


Subject: Re: [wss] Issue 399: Proposed Security Consideration Text


My take(s) inline:

Granqvist, Hans wrote:

>Hi all, quite good text. Just some proof-reading comments:
>
>General comment: There seems to be too many capitalized words, e.g., 
>Shorthand, References, Body, Absolute Path, Document, and so on, which 
>are not found capitalized in the specs.
>
>  
>
>>XML Signatures using Shorthand XPointer References (AKA 
>>IDREF) protect 
>>against the removal and modification of XML elements; but do 
>>not protect 
>>the location of the element within the XML Document.
>>    
>>
>
>"the element" is undefined in this sentence. Should it be 
>"this element/these elements"?  
>  
>
DN - I perceived this as referring to the "xml elements" noted just 
above it.  Grammatically correcting it to "the elements" would be correct.

>  
>
>>Whether or not this is a security vulnerability depends on 
>>whether the 
>>location of the signed data within its surrounding context has any 
>>semantic import. This consideration applies to data carried 
>>in the SOAP 
>>Body or the Header. 
>>    
>>
>
>What does "...within its surrounding context has any semantic 
>import" mean?  Does it mean "has semantic imports within its 
>surrounding context?"  If so, what the heck does that mean? :)
>Can we exemplify?
>
>The sentence is a bit heavy. Can it be rewritten to begin "Use of 
>IDREFs is a security vulnerability if the location of the referenced 
>signed data..."?
>  
>
DN - I think the concept here is "determinism".  If the schema itself is 
deterministic, then there should be no problem however if the schema is 
not and there are potential issues arising from that, to me that 
indicates a fault in the actual data model itself or the process someone 
used to derive the schema from the data model.  Such is worthwhile 
noting but out of scope for rectifying in a this spec.  We cannot 
constrain people to write good schemas ;-)

Cheers.

Duane

>  
>
>>...
>>    
>>
>
>  
>
>>In the general case of XML Documents and Signatures, this 
>>issue may be 
>>    
>>
>
>Unclear what "this issue" relates to here. 
>
>  
>
>>resolved by signing the entire XML Document and/or strict XML Schema 
>>specification and enforcement. However, because elements of the SOAP 
>>...
>>    
>>
>
>Strict schema checking won't catch all SOAP header wrapping attacks
>outlined in email threads/TC calls (I believe), so "and/or" seems too 
>loose, but I may be way off here.
>
>Thanks,
>Hans
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>


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