- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Fri, 8 Jan 2010 10:40:45 -0500
- To: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
- Cc: XMLSec WG Public List <public-xmlsec@w3.org>, "Cynthia E. Martin" <cemartin@mitre.org>
on second thought, is the IETF process such that the IETF 3161 update will be incorporated into RFC 3161 once approved? In that case I suggest we make no change since this will resolve itself. Anyone have any specific advice here? regards, Frederick Frederick Hirsch Nokia On Jan 8, 2010, at 10:35 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote: > 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:41:25 UTC