See also: IRC log
<trackbot> Date: 02 November 2010
<mjensen> ScribeNick: mjensen
fjh: what would be left in 2.0 if we remove the options as discussed yesterday?
... we were basically removing our requirement of backward compatibility (which wasn't written)
pdatta: xml:ancestors and xml:space affect trimTextNodes
fjh: if we set the trimTextNode parameter to "true", this would violate xml:space. Is this an issue? Would it matter if the only difference is in the hash value?
<fjh> we reviewed requirements section and noted with the changes yesterday we removed the implicit requirement for compatibility but did not lose the benefits listed in that section
fjh: what about having trimTextNodes invisible? If xml:space is present, it works implicitly, otherwise trimTextNodes is always set to true
... xml:space is the switch,why introduce our own?
... what if xml:space is set in the ancestors? Would cause the same issues as with namespace declarations there, so it should be pulled down to the apex nodes.
<pdatta> question to xml community? is xml:space widely adopted or do people use alternative means to imply if space is significant? If so then we cannot only rely on xml:space as the switch
<fjh> one goal in our charter is to work with the XML Environment, so that means respecting xml space in documents
<pdatta> xml schema: has "mixed" content model to indicate significant whitespace
<fjh> proposed RESOLUTION: remove TrimTextNodes parameter, trim by default, yet respect xml:space and not trim when it is specified
<fjh> resolution contingent on current use of xml space, note inheritance issue
<fjh> will make resolution on next call
<fjh> performance impact would be low, have to scan for namespace declarations anyway
<fjh> ACTION: scantor to indicate if there are alternative means to xml:space to indicate preserving space, and to comment on actual use of xml:space [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-704 - Indicate if there are alternative means to xml:space to indicate preserving space, and to comment on actual use of xml:space [on Scott Cantor - due 2010-11-09].
<fjh> pratik notes that if schema indicates mixed content would not want to trim spaces but we don't assume access to schema
<fjh> proposed RESOLUTION: retain TrimTextNodes parameter to support mixed content cases, but change default to true, unless xml:space is in effect
RESOLUTION: retain TrimTextNodes parameter to support mixed content cases, but change default to true, unless xml:space is in effect
pdatta: xml:lang has been discussed with Canonicalization 1.0 and it was decided not to include it like namespace declarations on ExcC14N
fjh: it would be wrong to ignore xml:lang for our convenience
<fjh> question - what is requirement for xml:lang inheritance support, is assumption that everyone is using exclusive c14n correct?
<fjh> we know that it is yes for web services due to BSP, but not sure about document use cases, including medical records
<fjh> ACTION: jcc to confirm suitability of exclusive [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-705 - Confirm suitability of exclusive [on Juan Carlos Cruellas - due 2010-11-09].
<fjh> goal, find out if exclusive c14n used widely
pdatta: let's leave XmlAncestors option in
<fjh> proposed RESOLUTION: retain XmlAncestors parameter
(reviewing minutes from yesterday for determining removed and remaining options of C14N2.0)
<fjh> ISSUE-204?
<trackbot> ISSUE-204 -- Integrated recognition of QName content -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/204
<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> will discuss in wrapping attack section
<fjh> issue can be solved in c14n or in signature itself
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/
<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> need section that describe Included/ExcludedXPath elements
<fjh> ACTION: scantor to propose definition section text for Included/ExcludedXPath elements for XML Signature 2.0 [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-706 - Propose definition section text for Included/ExcludedXPath elements for XML Signature 2.0 [on Scott Cantor - due 2010-11-09].
<fjh> ACTION: pdatta to remove EnvelopedSignature from section 6.7.1, http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-Type-xml [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-707 - Remove EnvelopedSignature from section 6.7.1, http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-Type-xml [on Pratik Datta - due 2010-11-09].
<fjh> wg decided this is always implicit
<fjh> ACTION-214?
<trackbot> ACTION-214 -- Thomas Roessler to write down a note summarizing discussion on algorithms to be included in the draft to be made public -due 17/02/2209 -- due 2009-02-24 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/214
<fjh> ISSUE-214?
<trackbot> ISSUE-214 -- XML Signature 2.0 needs precise definitions of Verification element and its children. -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/214
<fjh> ISSUE-214: see http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-Verification-2.0
<trackbot> ISSUE-214 XML Signature 2.0 needs precise definitions of Verification element and its children. notes added
<fjh> ISSUE-214 closed
<trackbot> ISSUE-214 XML Signature 2.0 needs precise definitions of Verification element and its children. closed
<pdatta> ACTION:pdatta to fix typo in XML Signature 2.0 in DigestDataLength description purpose c) [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action05]
<pdatta> ACTION: pdatta to fix typo in XML Signature 2.0 in DigestDataLength description purpose c) [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-708 - Fix typo in XML Signature 2.0 in DigestDataLength description purpose c) [on Pratik Datta - due 2010-11-09].
<pdatta> 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?
<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> open action by scott
<pdatta> 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
<pdatta> ACTION: pdatta to incorporate Meiko's examples in the document - ISSUE-217 [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-709 - Incorporate Meiko's examples in the document - ISSUE-217 [on Pratik Datta - due 2010-11-09].
<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> use case - saml assertion signature that references assertion itself
<fjh> currently uses id, meiko mentions possible wrapping attack
<fjh> using ".." could avoid wrapping attack
<fjh> however, can know that have assertion and can check carefully against attacks without special case
<fjh> streaming is fundamental to 2.0
<fjh> proposed RESOLUTION: close ISSUE-140 with no action, do not introduce relative XPaths into XPath Profile 2.0
RESOLUTION: close ISSUE-140 with no action, do not introduce relative XPaths into XPath Profile 2.0
<fjh> ISSUE-203?
<trackbot> ISSUE-203 -- How to tag id-ness of attributes when schema isn't parsed -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/203
ISSUE-43?
<trackbot> ISSUE-43 -- Improvements to XML Signature schema -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/43
<fjh> ISSUE-203: IDAttributes added to XML Signature 2.0, http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-Verification-2.0
<trackbot> ISSUE-203 How to tag id-ness of attributes when schema isn't parsed notes added
<fjh> ISSUE-203 closed
<trackbot> ISSUE-203 How to tag id-ness of attributes when schema isn't parsed closed
ISSUE-43?
<trackbot> ISSUE-43 -- Improvements to XML Signature schema -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/43
ISSUE-160?
<trackbot> ISSUE-160 -- Define URI for Canonical XML 2.0, add section to Signature 2.0 defining Canonical XML 2.0 -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/160
<fjh> need to check with Scott on ISSUE-43
<fjh> ISSUE-160: added to document, see http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-c14nAlg-2.0
<trackbot> ISSUE-160 Define URI for Canonical XML 2.0, add section to Signature 2.0 defining Canonical XML 2.0 notes added
<fjh> ISSUE-160: closed
<trackbot> ISSUE-160 Define URI for Canonical XML 2.0, add section to Signature 2.0 defining Canonical XML 2.0 notes added
pdatta: what about the prefixes-in-XPath problem?
fjh: defered to attacks discussion
<pdatta> ACTION: pdatta to add reference to XPath profile in the XML Signature 2.0 doc [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-710 - Add reference to XPath profile in the XML Signature 2.0 doc [on Pratik Datta - due 2010-11-09].
fjh: we should clearly separate the compatibility mode from the 2.0 mode texts
... review from the group is required.
pdatta: problem is that by now 2.0 and compatibility is interleaved, becomes hard to read.
fjh: we need time for this, won't go to last call today.
... wait for input from Scott.
pdatta: inputs from selection to c14n, how should we describe best?
tlr: why is an xpath expression inappropriate for expressing the elements?
s/xpath/namespace/
tlr: we have to identify what elements contain QNames and the best way to do this is using QNames
pdatta: Signature schema does not include C14N schema
fjh: you need all schemas together, right?
... it seems wrong to have duplicate expressions for the same.
... suggest a new namespace for both signature and C14N commonly that contains both schemas.
<fjh> ds2u namespace for common
proposed RESOLUTION: keep the existing namespaces separately for Signature and C14N
fjh: it makes sense to have QNameAware for every reference, since references may point to different documents with different QNames
... leave it in and wait for feedback
... not strictly necessary to optimize the schema by introducing a new namespace with schema, need to be pragmatic about complexity of documentation, etc
mje to add QnameAware elements and IDAttributes element to the examples (or check whether they're in and correct)
<scribe> ACTION: mjensen to add QnameAware elements and IDAttributes element to the examples (or check whether they're in and correct) [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-711 - Add QnameAware elements and IDAttributes element to the examples (or check whether they're in and correct) [on Meiko Jensen - due 2010-11-09].
<fjh> ACTION: pdatta to XPathAware child element of QNameAware to C14n2 [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-712 - XPathAware child element of QNameAware to C14n2 [on Pratik Datta - due 2010-11-09].
<pdatta> ACTION-712 http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0055.html
<pdatta> ACTION-712: http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0055.html
<trackbot> ACTION-712 XPathAware child element of QNameAware to C14n2 notes added
<fjh> ACTION: brich to review XML Signature 2.0 requirements, http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs2/Overview.html [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-713 - Review XML Signature 2.0 requirements, http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs2/Overview.html [on Bruce Rich - due 2010-11-09].
<pdatta> proposed RESOLUTION: Keep the c14n2:QNameAware and dsig:IdAttributes function as is, even though they have the same sub element dsig2:QualifiedAttr and c14n2:QualfiedAttr with same meaning but different namespaces
RESOLUTION: Keep the c14n2:QNameAware and dsig:IdAttributes function as is, even though they have the same sub element dsig2:QualifiedAttr and c14n2:QualfiedAttr with same meaning but different namespaces
<brich> ScribeNick: brich
<pdatta> http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0053.html
<pdatta> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#sec-Namespace-Processing
<fjh> definition of visibly utilized in c14n2, http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#sec-Namespace-Processing
pdatta: changed c14n2 section 2.5 "visibly utilized" to add XPath consideration
<fjh> OR (TBD) Some special attribute or text nodes maybe have an XPath, e.g. the IncludedXPath and ExcludedXPath attributes in an XML Signature 2.0 Transform. Any prefixes used in this XPath expression are considered to be visibility utilized.
mjensen: what does this do for "xml", which is implicitly defined
<mjensen> since xml: prefix is not defined explicitly, how is it treated in excC14N?
<mjensen> is there an explicit "xmlns:xml="http://....xmlns" in excC14N?
pdatta: xml parsers all know the mapping of "xml:
... think this is a parser issue, not xml security issue
<fjh> possible attack if incorrect parser implementation does not realize xml* prefixes are reserved and allows user/hacker defined xml* prefix override
pdatta: this is perhaps a warning that parsers should not allow "xml*:" remappings
<Cynthia> Agreed, this should be a warning in the text
<pdatta> ACTION: pdatta to add warning in c14n 2.0 about not parsers not allowing to redefine xml* prefixes [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action12]
<trackbot> Created ACTION-714 - Add warning in c14n 2.0 about not parsers not allowing to redefine xml* prefixes [on Pratik Datta - due 2010-11-09].
<mjensen> proposal: add a sentence to description of "visibly utilized" stating that it is REQUIRED to also consider "xml*" prefixes as visibly utilized.
pdatta: the problem is that we cannot emit a binding of "xml:" to the XML namespace
... so we need to rely on parsers NOT doing what they are not supposed to do
RESOLUTION: we are going to warn about possibly-incorrect parsers in the C14n2 spec
<mjensen> http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0053.html
<pdatta> ACTION-714: add a new section "Special namespaces" to Section 2.5 and talk about prefixes xml and xmlns , how the parser always knows about them, how they cannot be redefined, and how c14n cannot emit them
<trackbot> ACTION-714 Add warning in c14n 2.0 about not parsers not allowing to redefine xml* prefixes notes added
pdatta: when signature call c14n, it will pass the included/excluded xpaths, and will be treated specially
... so this will be on verification
... this will be an implicit communication of potential prefixs of interest
... something followed by a semicolon = may be a prefix
... (not quoted)
mjensen: doubt that can always figure out these prefixes
pdatta: XPath does not really know about prefixes, so the anything: form is going to be a sufficient resolution
<pdatta> there is a reliable way to scan the Xpath expression and look for prefixes
<pdatta> so take an Xpath expression - remove all quoted parts from it, scan the rest of for prefixes which is a word followed by a single colon
<mjensen> http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0016.html
pdatta: alg in note is remove all double-quoted and single-quoted strings, then search for single colons and get the word just before colon
<pdatta> For example <IncludedXPath xmlns:soap="...">/soap:Envelope/soap:Body</IncludedXPath>
<pdatta> this xmlns:soap will be emitted by canonicalizer
pdatta: have to rely on the limits on legal chars in a prefix
<mjensen> <IncludedXPath xmlns:soap="http://soap.ns">/soap:Envelope/soap:Body</IncludedXPath>
fjh: revisit algorithms to remove duplicates...
<pdatta> ACTION: pdatta to add content on scanning algorithm (augment to remove duplicates), and information on where to emit the namespace declaration [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action13]
<trackbot> Created ACTION-715 - Add content on scanning algorithm (augment to remove duplicates), and information on where to emit the namespace declaration [on Pratik Datta - due 2010-11-09].
RESOLUTION: will add the algorithms specified by Pratik in note 16 to the spec, and remove duplicates
<mjensen> the algorithm from Pratik's mail should be sufficient to fend the Namespace Injection technique completely.
<mjensen> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0027.html
<pdatta> ACTION-715: add information on interface between XML Signature to Canonical XML 2.0. during canonicalization of the SignedInfo, XML Signature has to implicitly pass the location of these IncludedXPath and ExcludedXPath elements so that Canonical XML can scan for prefixes in these XPaths
<trackbot> ACTION-715 Add content on scanning algorithm (augment to remove duplicates), and information on where to emit the namespace declaration notes added
<mjensen> approach #3
<fjh> proposal RESOLUTION: add to warning to best practices to recommend #3 for xpath as in http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0027.html for pre-2.0 versions of Signature.
RESOLUTION: add to warning to best practices to recommend #3 for xpath as in http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0027.html for pre-2.0 versions of Signature.
<fjh> ACTION: mjensen to propose text for xpath and best practices [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action14]
<trackbot> Created ACTION-716 - Propose text for xpath and best practices [on Meiko Jensen - due 2010-11-09].
<fjh> id based wrapping attacks
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-ReferenceCheck-2.0
<fjh> "The signature implementation should return all these parts (possibly as DOM elements) to the calling application, which should then compare against its policy to make sure what was expected to be signed is actually signed."
<fjh> mjensen: possibly no DOM elements in streaming 2.0 mode
<fjh> "all these subtrees"
mjensen: in a perfect world, would introduce policy about which parts should have been signed
<fjh> example, two soap bodies, second correct, id updated on second, first seen by application, no error warning, no schema validation
mjensen: see what is signed is only secure approach, but difficult to get adoption
<fjh> add guidance on position assertion to spec?
<fjh> section 3.2.6, http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-ReferenceValidation-2.0
<fjh> position changes on SAML assertion if assertion moved
<fjh> tokens are meant to be movable, so position assertion not useful for tokens. However may be useful for non-token cases
<fjh> see what you signed can work with document approach, however possible issue for web services
pdatta: SAML 2.0 does have some compensation for XML wrapping attacks
... not sure what positional assertion might mitigate against
<fjh> position assertion helps with SOAP
mjensen: and if you don't have policy
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0042.html
<fjh> ISSUE-122?
<trackbot> ISSUE-122 -- Explain why peformance improvements and rationale, relationship to earlier work -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/122
<fjh> ISSUE-86?
<trackbot> ISSUE-86 -- Document performance criterial and benchmarks -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/86
<Gerald-E> I would rather not omit the thesis in Spanish just because it is in Spanish
<pdatta> Preventing Wrapping attacks in SAML 2.0. See 5.4.2 in http://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf - Signatures MUST contain a single <ds:Reference> containing a same-document reference to the ID attribute value of the root element of the assertion or protocol message being signed. For example, if the ID attribute value is "foo", then the URI attribute in the <ds:Reference> element MUST be "#foo".
mjensen: streaming 1.0 specific, have some performance data to look at
<fjh> mjenson has looked at , and talked with Raul Garcia, streaming does better than DOM as size increases due to memory issues, but 1.0 focus
mjensen: cases where you run out of memory...streamling better
<fjh> pdatta: 2.0 does as part of spec what 1.0 optimized spec would do that didn't follow 1.0 spec blindly
pdatta: 2.0 advantage would be that we are following a better model, but an optimized 1.0 may also be following that model
mjensen: plus 2.0 has streamable XPath subset
pdatta: so we have supposition of further improvement, but no substantiation of benefits yet
... in Java, inclusion of any XPath will be off optimized path
<pdatta> ACTION: pdatta to document the Performance improvements with 2.0 [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action15]
<trackbot> Created ACTION-717 - Document the Performance improvements with 2.0 [on Pratik Datta - due 2010-11-09].
pdatta: plus add additional garbage collection drives performance down
fjh: perhaps a performance wiki would be helpful
pdatta: would like an actual doc
<fjh> ACTION: fjh to create performance data draft [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action16]
<trackbot> Created ACTION-718 - Create performance data draft [on Frederick Hirsch - due 2010-11-09].
<pdatta> http://www.codenomicon.com/labs/xml/
mjensen: thesis contains some initial numbers that may be helpful
... have also some Rampart numbers
... have some streaming vs non-streaming numbers, but the difference between a streaming 1.0 and a streaming 2.0 will be harder to get
<fjh> performance benefits: major is linear in memory via streaming, then 2.0 benefits on top of this, including usability
<pdatta> compare a) non optimized 1.0, b) optimized 1.0 with DOM, c) optimized 1.0 with stream, d) 2.0 with stream
<fjh> denial of service easier for DOM, harder for streaming, e.g. memory use
<fjh> mjensen: configuration, options that make it hard
<fjh> http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
<fjh> http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs
fjh: have to have Explain and Diff doc, and we're doing pretty well on that
<fjh> "Show evidence of wide review."
fjh: addressing responses to Last Call
... could also have formal objections...
... other criteria in link above
<fjh> All Last Call comments to date have been resolved:
<fjh> http://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmldsig-core1-20100204/doc/
<fjh> Additional Last Call of XML Signature 1.1 due to addition of X509Digest element and deprecation of X509IssuerSerial. http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.html#sec-X509Data
<fjh> proposed RESOLUTION: WG agrees to bring XML Signature 1.1 to an additional three week Last Call beginning 9 November and ending 30 November 2010 due to the addition of X509Digest element and deprecation of X509IssuerSerial.
<fjh> http://www.w3.org/TR/2010/WD-xmldsig-core1-20100513/
<fjh> The Last Call period ends 10 June 2010.
<fjh> proposed RESOLUTION: WG agrees to bring XML Signature 1.1 to an additional three week Last Call beginning 9 November and ending 30 November 2010 due to the addition of X509Digest element, deprecation of X509IssuerSerial, KeyInfoReference
<fjh> http://www.w3.org/TR/2010/WD-xmldsig-core1-20100513/#sec-KeyInfoReference
RESOLUTION: WG agrees to bring XML Signature 1.1 to an additional three week Last Call beginning 9 November and ending 30 November 2010 due to the addition of X509Digest element, deprecation of X509IssuerSerial, KeyInfoReference
<fjh> ACTION: tlr to prepare for additional XML Signature 1.1 Last Call starting 9 November and ending 30 November 2010 [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action17]
<trackbot> Created ACTION-719 - Prepare for additional XML Signature 1.1 Last Call starting 9 November and ending 30 November 2010 [on Thomas Roessler - due 2010-11-09].
<fjh> ACTION: tlr to update SOTD for XML Signature 1.1 Last Call publication [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action18]
<trackbot> Created ACTION-720 - Update SOTD for XML Signature 1.1 Last Call publication [on Thomas Roessler - due 2010-11-09].
<fjh> http://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmlenc-core1-20100513/doc/
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html
<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> we need to review this: http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0030.html
<fjh> my proposed response: http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0045.html
<fjh> ACTION: tlr to review proposal for change to XML Encryption in response to EXI comment, http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0045.html [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action19]
<trackbot> Created ACTION-721 - Review proposal for change to XML Encryption in response to EXI comment, http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0045.html [on Thomas Roessler - due 2010-11-09].
<fjh> " In the case of Type EXI the MimeType attribute is not necessary, but if used should reflect the underlying type and not "EXI"
<fjh> proposed RESOLUTION: Accept proposal in response to EXI feedback as in http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0045.html
RESOLUTION: Accept proposal in response to EXI feedback as in http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0045.html
<fjh> ACTION: fjh to update XML Encryption with proposal noted in http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0045.html [recorded in http://www.w3.org/2010/11/02-xmlsec-minutes.html#action20]
<trackbot> Created ACTION-722 - Update XML Encryption with proposal noted in http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0045.html [on Frederick Hirsch - due 2010-11-09].
<fjh> http://www.w3.org/2008/xmlsec/Drafts/generic-hybrid-ciphers/Overview.html
<fjh> last call completed with no comment
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html
<fjh> http://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmldsig-properties-20100204/
<fjh> possibly remove some material
<fjh> ISSUE-212?
<trackbot> ISSUE-212 -- Additional denial of service attack for Best Practices, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0020.html -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/212
<fjh> ISSUE-212: see http://www.w3.org/2008/xmlsec/Drafts/best-practices/Overview.html#xpath-streaming-denial-of-service
<trackbot> ISSUE-212 Additional denial of service attack for Best Practices, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0020.html notes added
<fjh> ISSUE-212 closed
<trackbot> ISSUE-212 Additional denial of service attack for Best Practices, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0020.html closed
<fjh> ISSUE-71?
<trackbot> ISSUE-71 -- Change section titles in best practices to match practices -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/71
<fjh> ISSUE-71 closed
<trackbot> ISSUE-71 Change section titles in best practices to match practices closed
<fjh> ISSUE-170?
<trackbot> ISSUE-170 -- Should we recomend signing namespaces as part of Best Practice 12 (dependency on ACTION-538) -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/170
<fjh> ISSUE-170: dealt with in 2.0
<trackbot> ISSUE-170 Should we recomend signing namespaces as part of Best Practice 12 (dependency on ACTION-538) notes added
<fjh> ISSUE-170 closed
<trackbot> ISSUE-170 Should we recomend signing namespaces as part of Best Practice 12 (dependency on ACTION-538) closed
<fjh> please review your actions, see http://www.w3.org/2005/06/tracker/users/my
<fjh> 59 open actions, http://www.w3.org/2008/xmlsec/track/actions/open
<fjh> 21 open issues, http://www.w3.org/2008/xmlsec/track/issues/open
<fjh> ACTION-699?
<trackbot> ACTION-699 -- Cynthia Martin to update interop wiki with suite B organization -- due 2010-11-08 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/699
<fjh> reassigned to Cynthia
<fjh> ACTION-704?
<trackbot> ACTION-704 -- Scott Cantor to indicate if there are alternative means to xml:space to indicate preserving space, and to comment on actual use of xml:space -- due 2010-11-09 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/704
<fjh> ACTION-704: moot with subsequent discussion
<trackbot> ACTION-704 Indicate if there are alternative means to xml:space to indicate preserving space, and to comment on actual use of xml:space notes added
<fjh> ACTION-704 closed
<trackbot> ACTION-704 Indicate if there are alternative means to xml:space to indicate preserving space, and to comment on actual use of xml:space closed
<pdatta> ACTION-699: organize the interop wiki so that all the algorithms required for NIST SUITE B are in one group , i.e. ECDSA, ECDH and AES-GCM
<trackbot> ACTION-699 Update interop wiki with suite B organization notes added
<fjh> ISSUE-160?
<trackbot> ISSUE-160 -- Define URI for Canonical XML 2.0, add section to Signature 2.0 defining Canonical XML 2.0 -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/160
<fjh> ISSUE-160 closed
<trackbot> ISSUE-160 Define URI for Canonical XML 2.0, add section to Signature 2.0 defining Canonical XML 2.0 closed