See also: IRC log
<trackbot> Date: 04 January 2011
<fjh> ScribeNick: pdatta
<fjh> May publishing moratorium
<fjh> 6 May: Deadline for publication requests before moratorium [12pm ET]
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2011Jan/0000.html
<fjh> Approve minutes, 21 December 2010
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0078.html
<fjh> Proposed RESOLUTION: Minutes from 21 December are approved.
RESOLUTION: Minutes from 21 December are approved.
<fjh> XML Signature 1.1 and XML Encryption 1.1 Last Call
<fjh> Last call ended 22 December. No comments received
<fjh> Next steps before bringing 1.1 to CR
<fjh> Requirements met?
<fjh> Review and updates to change explanation documents
<fjh> Additional external review needed? IETF?
<fjh> ACTION: tlr to send notice of pending CR of XML Signature 1.1 and XML Encryption 1.1 to IETF [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-755 - Send notice of pending CR of XML Signature 1.1 and XML Encryption 1.1 to IETF [on Thomas Roessler - due 2011-01-11].
<fjh> ACTION: fjh to share notice of pending CR with OASIS [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-756 - Share notice of pending CR with OASIS [on Frederick Hirsch - due 2011-01-11].
<fjh> ISSUE-91?
<trackbot> ISSUE-91 -- ECC can't be REQUIRED -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/91
<fjh> ISSUE-178?
<trackbot> ISSUE-178 -- Highlight additional text constraints on XSD schema as such. -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/178
<fjh> this was not a problem with 1.0, so keep as is for consistency
scantor: this issues was rasied by Makoto, when creating thr RNG schema
<fjh> ISSUE-178: this was not a problem with 1.0, so keep as is for consistency
<trackbot> ISSUE-178 Highlight additional text constraints on XSD schema as such. notes added
<fjh> ISSUE-178 closed
<trackbot> ISSUE-178 Highlight additional text constraints on XSD schema as such. closed
<fjh> ISSUE-216?
<trackbot> ISSUE-216 -- Whether and how to test denial of service cases in test suite -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/216
mjensen: don't see the DoS as a test
<fjh> ISSUE-216 closed
<trackbot> ISSUE-216 Whether and how to test denial of service cases in test suite closed
<fjh> ACTION: fjh to review section references in 1.1 [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-757 - Review section references in 1.1 [on Frederick Hirsch - due 2011-01-11].
fjh: did bunch of updates to XML Signature 2.0
<fjh> Updated to move compatibility mode to new section, remove "2.0 Mode" phrases, add tool generated section referencing, add conformance section
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0081.html (Frederick)
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0082.html (Frederick)
<fjh> ACTION-750?
<trackbot> ACTION-750 -- Scott Cantor to implement change to schema and document for Verification element proposal as noted in message 47 for ACTION-741 -- due 2010-12-21 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/750
<fjh> ACTION-751?
<trackbot> ACTION-751 -- Scott Cantor to implement change for ACTION-742 -- due 2010-12-21 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/751
<fjh> ACTION-742?
<trackbot> ACTION-742 -- Scott Cantor to propose text regarding 6.7.1.1 and use of c14n2 -- due 2010-12-14 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/742
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0002.html
<fjh> change made for Verifications element.
<fjh> change for selection remains
<fjh> changes to selection types/algorithms also needed
scantor: need to make changes to selection framework to account for the fact that there are no ID references in XPath
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0003.html
<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/ Version 03 Jan 2011
<fjh> Proposal - revise abstract and intro to make c14n2 stand alone
<fjh> clarify the relationship in intro
pdatta: can we say this is the new version of canonical xml 1.1 because it is not inclusive not all?
fjh: leave out references to inclusive and exlcusive in abstract. position it as canonicalization for 2.0
<fjh> ACTION: pdatta to update abstract and intro of c14N2 to remove relationship to C14N1 and exclusive in abstract and explain relationship in intro [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-758 - Update abstract and intro of c14N2 to remove relationship to C14N1 and exclusive in abstract and explain relationship in intro [on Pratik Datta - due 2011-01-11].
<fjh> concern #2, " Section "2.4 The need for Exlcusive Canonicalization" needs to be moved to a different location and also modified."
<fjh> suggest we add to requirements section topic of context and exclusive c14N as reference
concern #3, Currently the behavior of TrimTextNodes parameter depends on xml:space= "preserve" . But this doesn't make sense in exclusive mode. Because we are not supposed to rely on ancestor context in exclusive mode.. I say that we completely ignore xml:space
<fjh> ACTION: pdatta to update requirements section of c14n2 with context/exclusive c14n requirement and description [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-759 - Update requirements section of c14n2 with context/exclusive c14n requirement and description [on Pratik Datta - due 2011-01-11].
<fjh> scantor asks that parameter would signal whether xml:space is observed or not
scantor: TrimTextNodes is for the whole reference, xml:space is for finer grained control
<fjh> scantor: distinguish ignoring xml:space versus ignoring inheritance
<fjh> scantor: we need to understand implications of dropping inclusive c14N and other simplifications
<fjh> ISSUE: whether to ignore xml:space and relationship to TrimTextNodes
<trackbot> Created ISSUE-225 - Whether to ignore xml:space and relationship to TrimTextNodes ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/225/edit .
<fjh> ISSUE-225: Currently the behavior of TrimTextNodes parameter depends on xml:space= "preserve" . But this doesn't make sense in exclusive mode. Because we are not supposed to rely on ancestor context in exclusive mode.. I say that we completely ignore xml:space
<trackbot> ISSUE-225 Whether to ignore xml:space and relationship to TrimTextNodes notes added
<fjh> scantor: if ignoring xml:space then should have TrimTextNodes off by default
<fjh> scantor: white space is significant in XML
pdatta: no indication if inherited xml:space is considered while signing , because xml:space is value is not emitted
scantor: xml:space's default value is preserve
<fjh> http://www.w3.org/TR/xml11/#sec-white-space
pdatta: this is most surprising thing in c14n, people expect canonicalization to remove white space, and are surprised to hear that it isn't
<fjh> this is the issue of whether a canonicalized doc is a reference doc
Hal: the issue is whether whitespace is semantically significant
<fjh> if xml space is used to preserve, then it means white space is significant, so shouldn't signature capture that?
<scantor> I feel like we should honor xml:space in conjunction with trying to allow for trimming whitespace, and we could use the current trim option to control the "initial" state of the xml:space value at the root of the subtree
scantor: it is one thing to say that we can't inherit it, but we should honor xml:space if it is in the subset that is to be signed
<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#sec-Canonicalization-Parameters
<fjh> if intending to inherit xml:space preserve state than set TrimText Nodes to off
scantor: Proposal, we don't inherit xml:space from context, but honor xml:space if it is the subtree. And the TrimTextNodes really gives the xml:space setting that should be taken if nothing is specified
<fjh> proposed RESOLUTION: keep TrimTextNodes as defined in current C14N editors draft, rely on application to set it as needed , no inheritance of xml:space explicitly supported
<fjh> scantor: default value of xml:space would be whatever TrimTextNodes is set to
<fjh> who uses xml:space with default value, and why?
<fjh> Add to TrimTextNodes description: Where xml:space is used with value of default, the setting of TrimTextNodes defines the default. No inheritance of xml:space is performed as the application can set TrimTextNodes appropriately as needed"
scantor: in xml signature 2.0, do we need to track the state of the xml attributes
... currently we say that if you know that canonicalization does not need xml attributes, then don't track the state as an optimization
RESOLUTION: in xml signature 2.0. assume that any canonicalzation algorithm used does not rely on context. So XML signature never tracks the state of the xml attributes
<fjh> http://www.w3.org/TR/curie/
concern #4, CURIE doesn't make sense in exclusive mode also. First of all we removed such a basic thing like Inclusive canonicalization. Should we even put in something like CURIE in C14N 2.0? Secondly we don't have the CURIE context in C14N 2.0, so how do we even do visibly utilized. E.g. in the following snippet <a prefix="cc: http://creativecommons.org/ns#" rel="cc:license"> the "cc:license" is a compact way for saying " http://creativecommons.org/ns#li
http://www.w3.org/TR/2010/WD-rdfa-core-20100422/
<fjh> http://www.w3.org/TR/2010/WD-rdfa-core-20100422/#s_curieprocessing
<fjh> QNameAware parameter description is "set of nodes whose entire content must be processed as QName-valued or [CURIE]-valued for the purposes of canonicalization, including prefix rewriting and recognition of prefix "visible utilization""
<fjh> why can't Curie be dealt with a pre-processing stage
<fjh> and thus not deal with explicitly in C14N2
<fjh> proposed RESOLUTION: limit Curie awareness support to only prefix rewriting when processed in XML
<fjh> ACTION: tlr to help simplify and clarify processing for Curie in C14N2 [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-760 - Help simplify and clarify processing for Curie in C14N2 [on Thomas Roessler - due 2011-01-11].
<fjh> scantor: Curies are not always valid QNames
<fjh> scantor: proposal, not refer to QNames in QNameAware, but focus text on prefix rewriting
<fjh> By the Way, Curies are a Note, not a REC
<fjh> proposedResolution: reframe QNameAware parameter to be in terms of prefix rewriting, rename parameter
scantor: generalize qnames in content, to not only qnames, but genral prefixes in content - prefix: anything
<fjh> ACTION: tlr to explain importance and need for Curie support [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-761 - Explain importance and need for Curie support [on Thomas Roessler - due 2011-01-11].
pdatta: having a list of qnames in content is a more valid use case than a curie in content
... just use preprocessing to resolve CURIEs and get them out of the way
<fjh> +1 preprocessing can make sense for a workflow and avoid the issue
<fjh> possible conclusion: no need to support a feature at only Note status
Hal: Point 1: since it is a note, we don't have a strong reason to support it.
concern #5, We are down to 4 parameters, and we are saying that only the default values are MANDATORY to implement. Non defaults are OPTIONAL. I suggest we make them all MANDATORY, otherwise certain basic things like the solution to the XPAth wrapping attack will not be available.
<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#sec-Canonicalization-Parameters
<fjh> "For all of these parameters the behavior for default value must be implemented, non default values are optional."
<Gerald-E> un
<scantor> +1 to make them MTI
<fjh> +1 to proposal
<Gerald-E> no I do not have a concern..
<Cynthia> +1 agreed
RESOLUTION: all the 4 canonical xml 2.0 parameters are mandatory to implement
<fjh> Updated 2.0 Requirements, http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0080.html
<fjh> Converted to use ReSpec, moved section "Enable higher performance and streamability" up level as it is an important topic in its own right, Added subsection "Streaming XPath Profile for XML Signature 2.0" per ACTION-754
<fjh> Please review this document including the new section at http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs2/Overview.html#xpath-profile
<fjh> ACTION-717?
<trackbot> ACTION-717 -- Pratik Datta to document the Performance improvements with 2.0 -- due 2010-11-09 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/717
<fjh> ACTION-729?
<trackbot> ACTION-729 -- Pratik Datta to highlight potential issue with non-support for xml:base through removal of inclusive in xml signature and c14n2 drafts -- due 2010-11-23 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/729
<fjh> need to clarify what this means
<fjh> ACTION: fjh to clarify ACTION-729 [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-762 - Clarify ACTION-729 [on Frederick Hirsch - due 2011-01-11].
<fjh> ACTION-747?
<trackbot> ACTION-747 -- Pratik Datta to update XPath profile for Option 1 in proposal associated with ACTION-737 -- due 2010-12-21 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/747
<fjh> ACTION-748?
<trackbot> ACTION-748 -- Scott Cantor to update XML Signature 2.0 for Option 1 as proposed for ACTION-737 -- due 2010-12-21 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/748
<fjh> ACTION-753?
<trackbot> ACTION-753 -- Scott Cantor to work on creating 2.0 example for Signature 2.0 -- due 2010-12-21 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/753
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0000.html
<fjh> ISSUE-140?
<trackbot> ISSUE-140 -- Clarify how XPath is interpreted relative to entire document and ds:Reference -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/140
<fjh> ISSUE-140: current draft addresses concern
<trackbot> ISSUE-140 Clarify how XPath is interpreted relative to entire document and ds:Reference notes added
<fjh> ISSUE-140: see ACTION-748
<trackbot> ISSUE-140 Clarify how XPath is interpreted relative to entire document and ds:Reference notes added
<fjh> ISSUE-140 closed
<trackbot> ISSUE-140 Clarify how XPath is interpreted relative to entire document and ds:Reference closed
<fjh> ISSUE-198?
<trackbot> ISSUE-198 -- How to determine if arbitrary text content contains prefixes? Might need to do a lot of searching because text content can be large -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/198
<fjh> does this belong in Signature 2.0 or C14N2 or where?
<fjh> ACTION: pdatta to review ISSUE-198 and where algorithm should be placed [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-763 - Review ISSUE-198 and where algorithm should be placed [on Pratik Datta - due 2011-01-11].
<fjh> ISSUE-202?
<trackbot> ISSUE-202 -- How to define parameter sets in document, vs conformance criteria -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/202
XML Signature 2.0 must implicitly pass in the dsig2:IncludedXPath and dsig2:ExcludedXpath as QNameAware, even if they are not explictly present in the Signature element.
<fjh> ISSUE-204?
<trackbot> ISSUE-204 -- Integrated recognition of QName content -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/204
<fjh> same as ISSUE-202 concern
<fjh> ISSUE-206?
<trackbot> ISSUE-206 -- For c14n20 profile - clarify that conformance implies support, but also changes to xml or what must be explicitly specified -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/206
<fjh> change issue to require conformance section to C14N2
<fjh> scantor: without subsetting etc don't need explicit conformance section
<fjh> ISSUE-206: moot, reflected earlier version with profiling etc
<trackbot> ISSUE-206 For c14n20 profile - clarify that conformance implies support, but also changes to xml or what must be explicitly specified notes added
<fjh> ISSUE-206 closed
<trackbot> ISSUE-206 For c14n20 profile - clarify that conformance implies support, but also changes to xml or what must be explicitly specified closed
<fjh> ISSUE-208?
<trackbot> ISSUE-208 -- List 2.0 algorithms in algorithms cross-reference -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/208
<fjh> ISSUE-210?
<trackbot> ISSUE-210 -- Restructuring of Signature 2.0 "uncomplicate" section 4.4.3 by -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/210
<fjh> ISSUE-210: document has been restructured
<trackbot> ISSUE-210 Restructuring of Signature 2.0 "uncomplicate" section 4.4.3 by notes added
<fjh> ISSUE-210: closed
<trackbot> ISSUE-210 Restructuring of Signature 2.0 "uncomplicate" section 4.4.3 by notes added
<fjh> ISSUE-208: want to have 1.1 algorithms cross-reference, for 2.0 would need to include section and verification URIs
<trackbot> ISSUE-208 List 2.0 algorithms in algorithms cross-reference notes added
<fjh> ISSUE-211?
<trackbot> ISSUE-211 -- Stand alone version of Streaming XPath Profile versus diff, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0055.html -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/211
<fjh> ISSUE-211: document was restructured to be stand-alone
<trackbot> ISSUE-211 Stand alone version of Streaming XPath Profile versus diff, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0055.html notes added
<fjh> ISSUE-211 closed
<trackbot> ISSUE-211 Stand alone version of Streaming XPath Profile versus diff, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0055.html closed
<fjh> ISSUE-213?
<trackbot> ISSUE-213 -- XML Signature 2.0 needs precise definitions of Included/ExcludedXPath elements -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/213
<fjh> ISSUE-213 closed
<trackbot> ISSUE-213 XML Signature 2.0 needs precise definitions of Included/ExcludedXPath elements closed
<fjh> ISSUE-215?
<trackbot> ISSUE-215 -- C14N2 conformance - optional parameters, profiles, etc -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/215
<fjh> ISSUE-215 closed
<trackbot> ISSUE-215 C14N2 conformance - optional parameters, profiles, etc closed
<fjh> ISSUE-217?
<trackbot> ISSUE-217 -- XML Signature 2.0 needs 2.0 mode examples, e.g. , verification, selection etc. -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/217
<fjh> ISSUE-218?
<trackbot> ISSUE-218 -- For canonical xml 2.0 is eliminating inclusive c14n an issue for xml:base etc (which use cases are impacted), and should QName aware be mandatory -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/218
<fjh> ISSUE-219?
<trackbot> ISSUE-219 -- Status of Reference Type attribute in 2.0? -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/219
<fjh> ISSUE-220?
<trackbot> ISSUE-220 -- Clarify handling of comments and processing instructions in 2.0 mode , currently in terms of C14N -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/220
<fjh> ISSUE-221?
<trackbot> ISSUE-221 -- Clarify xml:space and xml:base, section 6.7.1.1 , http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-subtrees-with-exclusions -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/221
<fjh> ISSUE-222?
<trackbot> ISSUE-222 -- Review URI definitions in Signature 2.0 , also consider indicating usage in URI, e.g. /transforms -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/222
<fjh> ISSUE-223?
<trackbot> ISSUE-223 -- Requirement to "respect XML architecture" may lead to issue related to simplification and vs need to implement -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/223
<fjh> ISSUE-224?
<trackbot> ISSUE-224 -- why is base64 listed in algorithms section, is this for transform? where is it described in document, and does this belong in 1.1 or 2.0 mode. -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/Issue Review/224
<fjh> base64 should probably be moved under transforms
<fjh> ACTION: bal to review placement of base64 alg in 1.1/2.0, should it be under transforms? [recorded in http://www.w3.org/2011/01/04-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-764 - Review placement of base64 alg in 1.1/2.0, should it be under transforms? [on Brian LaMacchia - due 2011-01-11].