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

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