- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 8 Jan 2010 16:58:45 +0100
- To: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Cc: Thomas Roessler <tlr@w3.org>, XMLSec WG Public List <public-xmlsec@w3.org>, "Cynthia E. Martin" <cemartin@mitre.org>
RFCs are immutable once published, but new RFCs can obsolete old ones. -- Thomas Roessler, W3C <tlr@w3.org> On 8 Jan 2010, at 16:40, Frederick Hirsch wrote: > 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:58:48 UTC