- From: Pratik Datta <pratik.datta@oracle.com>
- Date: Mon, 3 Oct 2011 23:00:07 -0700 (PDT)
- To: frederick.hirsch@nokia.com
- Cc: public-xmlsec@w3.org
- Message-ID: <b5121145-b643-482b-ad94-17fa3772c33b@default>
New proposed text: When serializing a <code>Signature</code> element or signed XML data that's the child of other elements using these data models, that <code>Signature</code> element and its children may have in-scope namespaces inherited from its ancestral context. In addition, the Canonical XML and Canonical XML with Comments algorithms define special treatment for attributes in the XML namespace, which can cause them to be part of the canonicalized XML even if they were outside of the document subset. Simple inheritable attributes (i.e. attributes that have a value that requires at most a simple redeclaration such as xml:lang and xml:space) are inherited from nearest ancestor in which they are declared to the apex node of canonicalized XML unless they are already declared at that node.This may frustrate the intent of the signer to create a signature in one context which remains valid in another. These are the changes I made 1) removed the comma before "may" 2) changed "may contain namespace declarations from its ancestor context", to "may have in-scope namespaces inherited from its ancestral context" 3) changed defines to define 4) put in a definition of simple inheritable attributes - (i.e. attributes that have a value that requires at most a simple redeclaration such as xml:lang and xml:space) Pratik -----Original Message----- From: Grosso, Paul [mailto:pgrosso@ptc.com] Sent: Monday, September 26, 2011 12:27 PM To: frederick.hirsch@nokia.com Cc: public-xmlsec@w3.org; public-xml-core-wg@w3.org Subject: RE: FW: FW: Last Call for XML Signature 2.0, Canonical XML 2.0 and XML Signature Streaming Profile of XPath 1.0 ( LC-2488) I am satisfied enough with the latest wording to suggest that the XML Security WG close this issue. By way of editorial suggestions, I'll point out that "may contain namespace declarations from its ancestor context" doesn't make sense. What I think you mean is "may have in-scope namespaces inherited from its ancestral context". Also, the comma in "Signature element and its children, may contain" is wrong and misleading assuming "Signature element and its children" is the subject and "may contain" is the verb. I leave it to the editors to consider these editorial suggestions. paul > -----Original Message----- > From: frederick.hirsch@nokia.com [mailto:frederick.hirsch@nokia.com] > Sent: Monday, 2011 September 19 15:25 > To: Grosso@jessica.w3.org; Grosso, Paul > Cc: public-xmlsec@w3.org > Subject: Re: FW: FW: Last Call for XML Signature 2.0, Canonical XML 2.0 > and XML Signature Streaming Profile of XPath 1.0 ( LC-2488) > > > Dear Grosso, Paul , > > The XML Security Working Group has reviewed the comments you sent [1] > on > the Last Call Working Draft [2] of the XML Signature Syntax and > Processing > Version 2.0 published on 21 Apr 2011. Thank you for having taken the > time > to review the document and to send us comments! > > The Working Group's response to your comment is included below, and has > been implemented in the new version of the document available at: > http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec- > NamespaceContext. > > Please review it carefully and let us know by email at > public-xmlsec@w3.org if you agree with it or not before 26 September > 2011. > In case of disagreement, you are requested to provide a specific > solution > for or a path to a consensus with the Working Group. If such a > consensus > cannot be achieved, you will be given the opportunity to raise a formal > objection which will then be reviewed by the Director during the > transition > of this document to the next stage in the W3C Recommendation Track. > > Thanks, > > For the XML Security Working Group, > Thomas Roessler > W3C Staff Contact > > 1. > http://www.w3.org/mid/9B2DE9094C827E44988F5ADAA6A2C5DA02EE3A07@HQ- > MAIL9.ptcnet.ptc.com > 2. http://www.w3.org/TR/2011/WD-xmldsig-core2-20110421/ > > > ===== > > Your comment on the document as a whole: > > 1 XML Signature Syntax and Processing Version 2.0 > > > > http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/ > > > > Specification uses term "XML namespace URI" instead of "namespace > name" > > > > Although this probably doesn't create confusion, such informal term > > shouldn't appear in W3C spec. Either proper term "namespace name" > should > > be used (see http://www.w3.org/TR/xml-names/#dt-NSName) or at least > "XML > > namespace URI" should be put into Appendix A - Definitions and be > > properly defined here as a synonym of "namespace name". > > Insufficently defined context for XPath evaluation in "10.6.1 > > Selection of XML Documents or Fragments" > > XPath 1.0 specification defines the following properties for context > > a node (the context node) > > a pair of non-zero positive integers (the context position and the > > context size) > > a set of variable bindings > > a function library > > the set of namespace declarations in scope for the expression > > > > Only the context node is defined in this specification, other > > properties should be defined as well. > > > > Typo in "11.3 Namespace Context and Portable Signatures" > > In addition, the Canonical XML and Canonical XML with Comments > > algorithms import all XML namespace attributes (such as xml:lang) > from > > the… > > There shouldn't be xml:lang, but namespace declaration attribute like > > xmlns:foo. > > > > Also using entity references in examples as content of namespace > > declarations looks quite confusing. > > > > "B.7.2 Base64" > > Transformation as described assumes that operates on text node -- > > otherwise it will always return empty string. I'm not sure whether > this > > is correct assumption. Omitting operation 1) will fix this problem > > > Working Group Resolution (LC-2488): > Details of original XML Security WG response (and corresponding > changes) > is here: > http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0026.html > > Feedback with continued concern with "XML Namespace Attributes" > language > (other changes accepted) in section 11.3: > http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0029.html > (and > http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0030.html ) > Formal endorsement of XML Core WG: > http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0038.html > > XML Security WG resolution of issue, changing the language: > http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0040.html > > Agreed at XML Security WG teleconference, > http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/att- > 0044/minutes-2011-09-13.html#item04 > > This change should address the concern by adopting revised text as > follows: > > Original text: > > In addition, the Canonical XML and Canonical XML with Comments > algorithms **import** **all** **XML namespace attributes** (such as > xml:lang) from the nearest ancestor in which they are declared to the > apex > node of canonicalized XML unless they are already declared at that > node. > This may frustrate the intent of the signer to create a signature in > one > context which remains valid in another. > > Revised text: > > [[ > In addition, the Canonical XML and Canonical XML with Comments > algorithms > define special treatment for attributes in the XML namespace, which can > cause them to be part of the canonicalized XML even if they were > outside of > the document subset. Simple inheritable attributes are inherited from > nearest ancestor in which they are declared to the apex node of > canonicalized XML unless they are already declared at that node. This > may > frustrate the intent of the signer to create a signature in one context > which remains valid in another. > ]] > > See http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0046.html > > ---- >
Received on Tuesday, 4 October 2011 06:00:50 UTC