Re: Best Practices review (was Action-441 Completed)

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