- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Fri, 8 Jan 2010 10:35:20 -0500
- To: XMLSec WG Public List <public-xmlsec@w3.org>, "Cynthia E. Martin" <cemartin@mitre.org>
- Cc: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
Cynthia Thanks for your review of our Best Practices document in December. This document is at: http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/ Unfortunately since I thought the action was for reviewing WS-I BSP 1.1 (currently BSP 1.1 Approval Draft: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1-AD.html is the appropriate reference) I did not handle this properly - my mistake, I should have reviewed the message more carefully at the time. I'd like to complete processing these changes now and update the Best Practices before we agree to publish an update on Tuesday, if we can. My comments are inline - I'll make the changes marked ok immediately since I think they are non-controversial. Can we agree on the other items before Tuesday? Cynthia, are you still planning to review WS-I BSP 1.1, to see what changes if any we need to Signature or Encryption 1.1? Thanks regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG On Dec 7, 2009, at 4:39 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote: > 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. ok, though don't expect much on the grammar side :) Does anyone know of an ispell-like tool that (a) works in emacs , and (b) is smart enough to ignore xmlspec markup (or html etc), or can be configured to ignore specified markup? (b) is the important one, a Unix script would be great as well. I think Oxygen might do this, I'll have to look into it. Spell checking with markup is currently a pain. >> >> Section 2.1, paragraph 1: The use of the word hostile implies >> purposeful, suggest reword to 'harmful' to represent inadvertent or >> purposeful. I disagree with this change. While what you say may be true, the intent is to assume they are hostile so as to prevent against the worst case. >> >> 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." I think we should leave this one as written, since it does suggest considerations related to how the spec is interpreted. >> >> 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." ok >> >> Best Practice 1, paragraph 3: Replace Signed info with SignedInfo. ok >> >> Best Practice 3: The title seems soft, can we remove the word >> "Consider" I agree, suggest changing to "Avoid XSLT Transforms". Do others agree? >> >> 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). I assume this is an implementation dependent error. Any suggestions of specific text, otherwise I suggest no change. >> >> 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. What text does this refer to? I do not understand this comment. >> >> Best Practice 5: Try to avoid or limit XPath transforms: The title >> seems soft, can we remove the words "Try to" I agree, suggest changing to "Limit XPath Transforms". Do others agree? >> >> 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? How specifically would this be done? Should we recommend it? >> >> 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? I suggest we add this reference along with RFC3161 in the first paragraph of 2.5.1. Otherwise the advice seems the same and the requirement does not change. >> >> Best Practice 22, paragraph 3: State why XPath Filter 2.0 is not >> recommended in XML Signature 1.0. XPath Filter 2.0 did not exist when XML Signature 1.0 came out. I don't think we need a change here. >> >> Add Reference: Command Injection in XML Signatures and Encryption, >> Bradley W. Hill/ Information Security Partners, July 2007 Where should this be referenced in the document? Do you have the URL to go with the reference? >> >> Possible further additions: I don't think we should add these, since we advice in Signature 1.1 and I'd rather not replicate possibly creating errors or confusion. We could add a sentence in the introduction noting that the best practices are in addition to those mentioned in the Signature 1.1 document. >> 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 Friday, 8 January 2010 15:36:02 UTC