- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Fri, 8 Jan 2010 11:02:43 -0500
- To: ext Thomas Roessler <tlr@w3.org>
- Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, XMLSec WG Public List <public-xmlsec@w3.org>, "Cynthia E. Martin" <cemartin@mitre.org>
Yes, Does an obsoleted one indicate the new RFC to be used, I think so. Regardless, it sounds like we should not make a change here to the reference until RFC 3161 is superseded. Referencing the update draft does not sound like the correct change. regards, Frederick Frederick Hirsch Nokia On Jan 8, 2010, at 10:58 AM, ext Thomas Roessler wrote: > 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 16:03:21 UTC