See also: IRC log
<trackbot> Date: 29 September 2009
<fjh> Present?
SCRIBE nick gerald_e
<scribe> SCRIBENICK: gerald_e
<fjh> ScribeNick: gerald_e
fjh: Sean will scribe next
week
... a need to extend the charter, we will not be done by
May.
... 1.1 will be done, but not 2.0
<fjh> info on TPAC and F2F at http://www.w3.org/2008/xmlsec/Group/Overview.html#upcoming-f2f
<fjh> widget signature testing
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0025.html
fjh: tools for editing
<fjh> http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
<fjh> minutes 22 Sept
<fjh> http://www.w3.org/2009/09/22-xmlsec-minutes.html
fjh: can we take the minutes of 22 Sep as accepted?
RESOLUTION: minutes of 22 September are approved.
<scribe> ScribeNick: gerald_e
Pratik: References have been changed , for XPath, a link was inserted
<esimon2> Suggested profile name: "Reduced XPath"
Pratik: a name for the profile of XPath to make it framable and refer to C14N 2.0 he put in example of xPath and XML sig
look at Section 4.4.3.5
<fjh> 4.4.3.5 http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#spec-xpath-subset
Pratik: he added words about retreval methods
fjh: to agree to publish on
today's call
... can we agree today to publish?
<fjh> Approve shortnames
FJH: Short names
<fjh> xml-c14n2 and xmldsig-core2
<fjh> proposed resolution - adopt xml-c14n2 for shortname for Canonical XML 2.0
RESOLUTION: adopt xml-c14n2 for shortname for Canonical XML 2.0
RESOLUTION: adopt xmldsig-core2 for the shortname for XML Digital Signature 2.0
RESOLUTION: agree to publish FPWD of Canonical XML 2.0 and XML Signature 2.0 on 8 October 2009
fjh: issues to close or resolve to get to last call
<fjh> issue-124?
<trackbot> ISSUE-124 -- Does w3c support conformance clauses for specification and minimum conformance levels, how to do properly -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/124
<fjh> ACTION: fjh discuss ISSUE-124 with tlr [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-373 - Discuss ISSUE-124 with tlr [on Frederick Hirsch - due 2009-10-06].
<fjh> Issue-100?
<trackbot> ISSUE-100 -- Ripe URIs -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/100
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0039.html
<fjh> issue-100 closed
<trackbot> ISSUE-100 Ripe URIs closed
<fjh> XML Signature 1.1 issues
<fjh> issue-82?
<trackbot> ISSUE-82 -- Should 1.1 spec mandate support for range of RSA key sizes (and DSA)? -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/82
FJH: is there somthing more to do on this?
bal: he does not see this as an issue any more
<fjh> we have text in document for key size recommendations
bal: we have recommendations about minimum key length
<fjh> issue82 closed
<fjh> issue-121?
<trackbot> ISSUE-121 -- Provide recommendation regarding key length for signature a la widget signature, either in signature 1.1 or best practices -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/121
<fjh> issue-121 closed
<trackbot> ISSUE-121 Provide recommendation regarding key length for signature a la widget signature, either in signature 1.1 or best practices closed
<fjh> xml encryption 1.1
there were no objections to closing these issues
<fjh> issue-125?
<trackbot> ISSUE-125 -- Add C14N1.1 to the list of canonicalization algorithms in Section 5.9 of XMLENC -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/125
<fjh> section 5.9 http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-Alg-Canonicalition
fjh: c14n before encryption
BAL: it is complete - close Issue-125
<fjh> issue125 c14n11 listed in identifiers in section 5.9 http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-Alg-Canonicalition
<fjh> issue-125 c14n11 listed in identifiers in section 5.9 http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-Alg-Canonicalition
<fjh> issue-125 close
<fjh> issue-125 closed
<trackbot> ISSUE-125 Add C14N1.1 to the list of canonicalization algorithms in Section 5.9 of XMLENC closed
<fjh> issue-135?
<trackbot> ISSUE-135 -- Review transforms for encryption -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/135
fjh: it is thought thisi is an alignment issue: for XMLENC-1.1
esimon: we need to have more description for the issues to make it meaningful
<fjh> ACTION: fjh to review ISSUE-135 [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-374 - Review ISSUE-135 [on Frederick Hirsch - due 2009-10-06].
<fjh> issue-137?
<trackbot> ISSUE-137 -- Normative reference to DRAFT-HOUSLEY-KW-PAD -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/137
fjh: this issue needs more detail
<fjh> note in issue - DRAFT-HOUSLEY-KW-PAD needs to become approved.
<fjh> ACTION: fjh last call with ISSUE-137 discussion [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-375 - Last call with ISSUE-137 discussion [on Frederick Hirsch - due 2009-10-06].
fjh: he will talk to Thomas about waiting for approval. Brian will check on the IETF about this.
discussion about schemas
for XMLDSIG1.1
<fjh> issue: is a single schema needed for XML Signature 1.1 to validate against, given that we have 2nd edition schema plus 1.1 additional schema
<trackbot> Created ISSUE-142 - Is a single schema needed for XML Signature 1.1 to validate against, given that we have 2nd edition schema plus 1.1 additional schema ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/142/edit .
<bal> re: ISSUE-137, looks like this is now a published RFC, http://tools.ietf.org/html/rfc5649
<fjh> issue-142 can it be fixed with import or include statement to import 2nd edition schema
Ed: there are potential solutions
using include statements should we provide a single
signature.
do we have a problem in that we do not provide a scema to
validate 1.1 signatures?
<scribe> ACTION: esimon2 to start a discusson on the list to schema XMLDSIG-1.1 validation [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-376 - Start a discusson on the list about schema XMLDSIG-1.1 validation [on Ed Simon - due 2009-10-06].
<scribe> ACTION: bal to edit the reference to RFC-5649 [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-377 - Edit the reference to RFC-5649 [on Brian LaMacchia - due 2009-10-06].
<pdatta> +q
<esimon2> I was also thinking the issue of encryption transforms might refer to 2.0; e.g. how does the new transform affect XML Encryption.
fjh: issue 135 should refer to Enc 2.0 not Enc 1.1
<esimon2> * back in 5
<fjh> ACTION: fjh to add Implementations link to public home page [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-378 - Add Implementations link to public home page [on Frederick Hirsch - due 2009-10-06].
fjh: should the link for 1.1 be put on the public page?
fjh: who can help with interop?
<fjh> http://www.w3.org/2008/xmlsec/wiki/Interop
fjh: we need to plan next steps and timing for interop
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0045.html
fjh: we need to do derived keys
testing.
ECC testing
how should we progress? we need to do more to be able to
publish.
... can we talk about this next week?
<pdatta> would be interested in doing interop for encryption with elliptic curves
fjh: derived keys, ECC, and generic hybrid all need work
<mullan> we will try to add support for the new keyinfo types (OCSP and DEREncodedKeyValue)
<fjh> ACTION: fjh ask on list about interop participation and which topics can be tested [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-379 - Ask on list about interop participation and which topics can be tested [on Frederick Hirsch - due 2009-10-06].
FJH: he is planning how we can get to REC for 2.0
<fjh> http://www.w3.org/2005/10/Process-20051014/tr#last-call
<fjh> Include XML Signature 1.1, XML Encryption 1.1, XML Security Generic Hybrid Ciphers, XML Signature Properties
<fjh> update to XML Security Algorithms Cross-Reference
gjh: the specs for 1.1 are stable
fjh: the properties we shoujld get feedback form wigits
<fjh> Proposal related to ACTION-297, ACTION-298 and ACTION-320
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0006.html
TOPIC 2.0
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0040.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0042.html
<fjh> action-372 close
<fjh> action-372 closed
<trackbot> ACTION-372 Create an issue for the discussion in email closed
<fjh> action-350?
<trackbot> ACTION-350 -- Ed Simon to propose text to align node set result treatment for XSLT and XPath in 1.1 spec -- due 2009-08-04 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/350
<fjh> http://www.w3.org/2008/xmlsec/track/actions/open
fjh: ed to provide a list of closed actions and the reasons they are closed.
<fjh> action-371?
<trackbot> ACTION-371 -- Pratik Datta to add id and position handling in step in draft -- due 2009-09-29 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/371
<fjh> action-370?
<trackbot> ACTION-370 -- Pratik Datta to update signature 2.0 draft and remove URI from selection element and keep it in reference only -- due 2009-09-29 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/370
<fjh> action=370 closed
<fjh> action-370 closed
<trackbot> ACTION-370 Update signature 2.0 draft and remove URI from selection element and keep it in reference only closed
fjh: confirmed that action 370 is conplete
<fjh> action-368?
<trackbot> ACTION-368 -- Pratik Datta to update XPath in XML Signature 2.0 -- due 2009-09-29 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/368
<fjh> action-368 closed
<trackbot> ACTION-368 Update XPath in XML Signature 2.0 closed
<fjh> ACTION: tlr see if xmlspec can include strikeouts and inserts markup [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-380 - See if xmlspec can include strikeouts and inserts markup [on Thomas Roessler - due 2009-10-06].
<fjh> action-367 closed
<trackbot> ACTION-367 Remove note in section 4.4.2.3 in XML Signature 1.1 closed
<fjh> action-364?
<trackbot> ACTION-364 -- Pratik Datta to get feedback from implementers on XPath approach -- due 2009-09-15 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/364
<fjh> action-228?
<trackbot> ACTION-228 -- Gerald Edgar to send a message to the list of closed issues and how they were closed -- due 2009-03-10 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/228
fjh: people are to make comments on the doc
<fjh> http://www.w3.org/2008/xmlsec/track/issues/open
FJH: a need to close issues and actions
<fjh> new issue
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0041.html
ed: c14n 2 actions 350 and
352.
... root processing children. if there is an XPath filter that
returned an arttribute node and a text node. THis is not
specified in the C14N 1.. spec.
<fjh> issue-141?
<trackbot> ISSUE-141 -- C14N 1.1 processing of non-element, non-PI nodes in a node set -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/141
Pratik: there is a defined way to specify these things.
<fjh> Pratik notes that there was an old interop test for this case
:fjh: there is a list of cases in the original signature work
<fjh> ACTION: pratik to locate original c14n test case applicable to ISSUE-141 and update ISSUE-141 with link [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-381 - Locate original c14n test case applicable to ISSUE-141 and update ISSUE-141 with link [on Pratik Datta - due 2009-10-06].
fjh: there are 36 issues, some are old.
<fjh> issue-139?
<trackbot> ISSUE-139 -- Need to collect streaming XPath requirements -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/139
fjh: people should look at the list and discuss closing as many as we can.
ed: concerned about requiring an
XPath subset, what are the use cases for a subset?
... he is not convinced of the need
... he would like to see the evidence for this need
<fjh> ed notes research papers mentioned earlier
ed: he will look into efficient XPath processing
<fjh> sounds like f2f topic, performance, benchmarking, requirements review
Pratik: what goes into the subset? do we really need it?
s/supset/subset/
<fjh> pratik argues of need for web services, large document processing
Pratik: antime we have a large document, it needs to be loaded into memory.
Ed: he is not conviced
... he will look at this as time permits
<fjh> issue-131?
<trackbot> ISSUE-131 -- Is semantic equivalence robustness in requirements document -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/131
fjh: can we close this? do we
need to update the requirements document?
... we are not saying this needs to be semanticly
equivalent
<fjh> ck bal
<fjh> a
fjh: you could use C14N as an equivalent document for input for further processing.
<fjh> issue-131 deal with namespace rewriting, using C1n4 options appropriately
bal: two documents could be cannocalized to the same result.
fjh: we need to be clear about the options for semantic equivalence
<fjh> issue-131 need to be clear how close you can get to true equivalence
bal: we need to be clear about the defaults
<fjh> issue-131 need to set defaults properly
bal: we were not clear about c14n in prior stds
fjh: we need to address this in the 2.0 docuement
<esimon2> Namespace-aware canonicalization discussed in this presentation: http://www.w3.org/2007/xmlsec/ws/slides/18-edsimon-xmlsec/
fjh: we are missing a paragraph on semantic equivalents and to provide guidance
<fjh> ACTION: pratik to add guidance on semantic equivalence to Signature 2.0 related to ISSUE-131, which defaults, how equivalent does it get [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-382 - Add guidance on semantic equivalence to Signature 2.0 related to ISSUE-131, which defaults, how equivalent does it get [on Pratik Datta - due 2009-10-06].
<fjh> issue-123?
<trackbot> ISSUE-123 -- How in 2.0 to disallow SHA-1 when algorithm URI currently defined -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/123
<pdatta> C14N 2.0 uses Ed's proposal on Namespace-aware canonicalization as one of the namespace prefix rewriting options, the other option is sequential numbers
<fjh> was the WG intention to discourage SHA-1 in 1.1 and disallow in 2.0
<fjh> hal notes need for update process
HAL: we need to address cryptographic strength.
fjh: we need to remove
SHA-1
... SHA-1 is included, but not mandatory in 1.1
<fjh> SHA-1 mandatory, 1.1 not mandatory, 2.0 not allowed
BAL: SHA-1 is deprecated for US government applications next year
<fjh> backward compatibility issue comes up again
<fjh> issue-113?
<trackbot> ISSUE-113 -- Requirement to provide extension to Signature 1.1 to enable streaming hints in backward compatible manner -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/113
<fjh> we have different approach toward this so not needed.
<bal> ok i'm muted
<bal> that's weird
<fjh> issue-113 addressed in different manner in 2.0
<fjh> issue-113 closed
<trackbot> ISSUE-113 Requirement to provide extension to Signature 1.1 to enable streaming hints in backward compatible manner closed
(hamsters?)
<esimon2> * Sounded to me like a mouse running on a rusty wheel.
<fjh> issue-107?
<trackbot> ISSUE-107 -- deprecate decryption transform?, see what you sign and workflow -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/107
<esimon2> http://www.w3.org/TR/xmlenc-decrypt
esimon: a suggestion not to take actoin on this
hal: this is trouble to implement and maintain, and it satisfies only one use case.
fjh: the 2.0 model does not
encourage this. we are not doing harm by not doing
anything.
... leave the older stuff alone, but not encourage it. to
conciously change it. we have enough to do this.
<fjh> proposed resolution - WG decides not to deprecate or modify the decryption transform
RESOLUTION: WG decides not to deprecate or modify the decryption transform
<fjh> issue-107 closed
<trackbot> ISSUE-107 deprecate decryption transform?, see what you sign and workflow closed
<fjh> issue-104?
<trackbot> ISSUE-104 -- Carry existing ds:References into new XMLDSIG 2.0 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/104
<fjh> ssue-86?
<fjh> issue-86?
<trackbot> ISSUE-86 -- Document performance criterial and benchmarks -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/86
fjh: implementations have gotten
clever so this may not be meaningful.
... how to communicate that performance is not as bad as
people's impressions.
... it would be good to show an improvement
<fjh> what are we going to use as a performance baseline
<fjh> ACTION: sean to provide reference to performance paper [recorded in http://www.w3.org/2009/09/29-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-383 - Provide reference to performance paper [on Sean Mullan - due 2009-10-06].
[discussion on] how to provide performance numbers to give people a reason to make the change
<fjh> what is the baseline, are we showing improvement over a previous version, or comparison to theoretical basis
<fjh> for example pratik showed against serialization as baseline
fjh: does EXI have performance numbers?
<fjh> issue-45?
<trackbot> ISSUE-45 -- Multiple or layered signatures -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/45
<fjh> original title was Signing with multiple intended receivers, and/or long lived signatures"
<fjh> ed notes approach of using manifest
<fjh> one SignedInfo with multiple siganture values
there are ways to have multiple signature values associated with signed info.
<fjh> issue-45 allow more than one SignatureValue element within one SignedInfo
<fjh> is there a requirement for multiple signers to sign a single document
fjh: there is a need for some thought to do this, but it is known how much the need is.
<fjh> csolc notes can deal with current mechanism of duplicite or counter signatures
fjh: resolve this issue now
<fjh> proposed resolution - not address issue of allowing Signature to contain multiple SignatureValue elements in 2.0
<fjh> proposed resolution - defer issue of muliple signers within one signaure after 2.0
RESOLUTION: To defer issue of multiple signers within one signature until after 2.0