Fwd: Action-441 Completed (BSP review)

reposting to public list, technical discussion

regards, Frederick

Frederick Hirsch
Nokia



Begin forwarded message:

> From: "ext Martin, Cynthia E." <cemartin@mitre.org>
> Date: November 24, 2009 10:46:21 AM EST
> To: 'XMLSec WG Member List' <member-xmlsec@w3.org>
> Cc: Scott Cantor <cantor.2@osu.edu>, Thomas Roessler <tlr@w3.org>,  
> "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>,  
> "Martin, Cynthia E." <cemartin@mitre.org>
> Subject: Action-441 Completed
>
> All,
>
> Here are my comments and input for Action-441.  I do have some  
> recommended additions.  Please let me know how we should address  
> them.  Thank you,
>
> Regards, Cynthia
>
>
> ACTION-441, Cynthia Martin
> Review BSP 1.1 (http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html 
> ) with respect to Signature 1.1 and Encryption 1.1
>
> General comment: run the document through grammar and spell checker.
>
> Section 2.1, paragraph 1: The use of the word hostile implies  
> purposeful, suggest reword to 'harmful' to represent inadvertent or  
> purposeful.
>
> Section 2.1, paragraph 2: "Implementation of the XML Signature  
> specification should not always be literal" is misleading.  It is  
> either literal or not literal, I believe we discussed this and the  
> examples are representative.  Suggest reword to "The examples in the  
> XML Signature specification are representative."
>
> Best Practice 1: Add the word successfully to the sentence:  
> "Mitigate denial of service attacks by executing potentially  
> dangerous operations only after successfully authenticating the  
> signature."
>
> Best Practice 1, paragraph 3: Replace Signed info with SignedInfo.
>
> Best Practice 3: The title seems soft, can we remove the word  
> "Consider"
>
> Best Practice 4, paragraph 1: If you disable user-defined  
> extensions, what is the expected result if someone sends a user- 
> defined extension?  Do you disable it or block it (e.g. when you see  
> it drop it at the interface).
>
> Best Practice 4, paragraph 3: Of the various risk mitigation  
> techniques described, is one stronger than the other and if so why?   
> They are references as options, not risk mitigation techniques.
>
> Best Practice 5: Try to avoid or limit XPath transforms: The title  
> seems soft, can we remove the words "Try to"
>
> Best Practice 12: Unless impractical, sign all parts of the  
> document. I have a question about this, we were discussing signing  
> the namespace last week, does this best practice include namespace?
>
> Best Practice 16:  X.509 Public Key Infrastructure Time-Stamp  
> Protocol, RFC 3161 [RFC3161], there is an update ID for this (http://www.ietf.org/id/draft-ietf-pkix-rfc3161-update-09.txt 
> ), does it change the requirement?
>
> Best Practice 22, paragraph 3: State why XPath Filter 2.0 is not  
> recommended in XML Signature 1.0.
>
> Add Reference: Command Injection in XML Signatures and Encryption,  
> Bradley W. Hill/ Information Security Partners, July 2007
>
> Possible further additions:
> 1) Use of text based canonicalization of SignedInfo is NOT  
> RECOMMENDED.  See DSIG v1.1 Section 4.3.1
> "Use of text based canonicalization of SignedInfo is NOT RECOMMENDED."
>
> 2) URI attributes containing fragment identifiers must/should not be  
> allowed. See DSIG v1.1 Section 4.3.3.2
> "Consequently, we RECOMMEND in this case that the URI  attribute not  
> include fragment identifiers and that such processing be specified  
> as an additional XPath Transform or XPath Filter 2 Transform [XPath- 
> Filter-2]."
>
> 3) Same-document XPointers must/should be supported. See DSIG v1.1  
> Section 4.3.3.2
> "The original edition of this specification [XMLDSIG-2002]  
> referenced the XPointer Candidate Recommendation [XPTR-2001] and  
> some implementations support it optionally. That Candidate  
> Recommendation has been superseded by the [XPointer-Framework],  
> [XPointer-xmlns] and [XPointer-Element] Recommendations, and -- at  
> the time of this edition -- the [XPointer-xpointer] Working Draft.  
> Therefore, the use of the xpointer() scheme [XPointer-xpointer]  
> beyond the usage discussed in this section is discouraged."
>
> 4) The MgmtData child element of the KeyInfo element must/should not  
> be allowed. See DSIG v1.1 Section 4.4.7
> "The MgmtData element within KeyInfo is a string value used to  
> convey in-band key distribution or agreement data. For example, DH  
> key exchange, RSA key encryption, etc. Use of this element is NOT  
> RECOMMENDED."
>
> 5) Signature applications must/should create, read, and verify XML  
> content in Normalization Form C. See DSIG v1.1 Section 7.0
> "We RECOMMEND that signature applications create XML content  
> (Signature elements and their descendants/content) in Normalization  
> Form C [NFC, NFC-Corrigendum] and check that any XML being consumed  
> is in that form as well; (if not, signatures may consequently fail  
> to validate)."
>
> 6) When processing, XML parsers must expand all non-character  
> entities. See DSIG v1.1 Section 7.1

Received on Monday, 7 December 2009 21:40:05 UTC