XML Security Working Group Teleconference
22 Sep 2009

 

 

<trackbot> Date: 22 September 2009

<fhirsch> Bruce gives regrets for next week as well

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Sep/0012.html

Administrative - TPAC

<fhirsch> XMLSec Security Library (xmlsec) version 1.2.13 supports C14N11

fhirsch: please register

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0013.html

minutes approval

<fhirsch> http://www.w3.org/2009/09/08-xmlsec-minutes.html

RESOLUTION: minutes from sept 8, 2009 is approved

<fhirsch> XML Signature 2.0 draft

3a) Updated XML Signature 2.0 draft

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0015.html

pratik: added more sections

<fhirsch> will want to decide to publish FPWD

pratik: sections remaining - keyinfo, algorithms - we can decide whether we want to put them in the same or different doc

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Sep/0009.html

pratik: discussing how to deprecate

<fhirsch> comments on remaining work

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Sep/0011.html

<fhirsch> Updated Implementation wiki

fhirsch: sean updated wiki

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0016.html

Updated Implementation wiki (ACTION-358)

XML Signature 1.1 - mandatory to implement algorithms

<fhirsch> section 6.1 of XML Signature

<fhirsch> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Algorithms

<fhirsch> in particular, status of ECDSAwithSHA256 as required.

fhirsch: section 6.1 has mandatory algorithms including ECDSA-SHA256

<fhirsch> section 5.1 of XML Encryption

<fhirsch> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-AlgID

<fhirsch> Elliptic Curve Diffie-Hellman (Ephemeral- Static mode)

<fhirsch> ISSUE-91?

fhirsch: no response on IPR concerns
... pretty sure there will not be an easy answer to IPR questions
... have to make decision soon
... sounds like WG have to reach a comprise
... we will probably do a vote on the call, then members can raise objections

thomas: we have not received a single response from certicom and should not expect a response soon

<fhirsch> thomas notes that if WG decides for MUST in elliptic curve algorithms then this most likely would lead to a patent advisory group

thomas: PAG would result in a delay

<gerald-e> +1 for trying to close this

<gerald-e> on ECC

<scribe> ACTION: thomas and bal to coordinate offline [recorded in http://www.w3.org/2009/09/22-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-366 - And bal to coordinate offline [on Thomas Roessler - due 2009-09-29].

thomas: it's premature to make a decision right now

<fhirsch> w3c should communicate benefits of helping here, as well as asking

fhirsch: does the WG have problems with deferring the decision?

XML Signature ECKeyValueType

<fhirsch> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-ECKeyValue

<fhirsch> Note in section 4.4.2.3

fhirsch: does the WG think we need further discussion?

bal: propose resolution to remove note

RESOLUTION: remove note in section 4.4.2.3

<scribe> ACTION: bal remove note in section 4.4.2.3 in XML Signature 1.1 [recorded in http://www.w3.org/2009/09/22-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-367 - Remove note in section 4.4.2.3 in XML Signature 1.1 [on Brian LaMacchia - due 2009-09-29].

C14N 2.0 and XML Signature 2.0

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Sep/0011.html

fhirsch: canonicalization - where we are at with publishing the draft?

need to review the draft for typos

fhirsch: have the draft published on Oct 6
... pratik, what do you think about publishing C14N 2.0?

pratik: should we take out the code snipplets before publication?
... we would have to rewrite parts of the doc to describe the code that was removed for clarity

fhirsch: might be useful to keep the code for draft
... not sure if we need KeyInfo or Algorithms updated for the draft. could have a note to reference 1.1

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Sep/0011.html

<fhirsch> Overall discussion of how Transforms are > deprecated/desupported/not recommended. e) dereferencing/selection > processing model

fhirsch: can we state intent in the first public draft and work out details later
... we just want to share the overall approach in the draft

pratik: can send out some text around deprecation
... for deferencing, URI a parameter

<fhirsch> wherever there is a gap, please put in an editors note indicating the plan to incorporate material from 1.1

<pdatta> I will add in the text for dereferencing. Earlier dereferencing was URI -> Nodeset/octets. Now it is selection parameters (which may include URI) -> object

pratik: do we want to put the XPath subsets into the doc as well?

fhirsch: we should probably defer XPath subsets - we are probably not going to be ready

esimon2: don't want to be in the position to exclude implementations from supporting the full XPath

fhirsch: do we want a third document?

scantor: if the subset defined is significantly simpler than XPath than would like to see the subset to be mandatory.

fhirsch: don't need to do too much with the canonicalization doc
... don't need to do too much with the canonicalization doc

scantor: if we cannot agree on the subset, then we can leave the exact definition as TBD

fhirsch: we can get more feedback if we leave the subset in doc

scantor: subset in doc is not up to date

<scribe> ACTION: pratik to update XPath in XML Signature 2.0 [recorded in http://www.w3.org/2009/09/22-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-368 - Update XPath in XML Signature 2.0 [on Pratik Datta - due 2009-09-29].

<scantor> we agreed to create a plug point via URI to identify the selection/include/exclude syntax

pratik: we have to decide on the syntax
... we have to decide on the syntax

<scribe> ACTION: scantor to draft a proposal for using URI to identify section syntax [recorded in http://www.w3.org/2009/09/22-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-369 - Draft a proposal for using URI to identify section syntax [on Scott Cantor - due 2009-09-29].

pratik: thomas mentioned the deferencing proposal is not compatible with web architecture

scantor: thinks thomas' comment was to not allow empty URIs in dereferencing
... not a fundamental problem
... not use a fixed URI, but use a different syntax

<fhirsch> not use fixed uri to mean database query, but use query string for select etc

pratik: can remove the one in the selection section
... in 1.1, only 1 URI can be missing

scantor: URI should always be present
... same document reference can still allow empty URI

<pdatta> RESOLUTION Remove URI from Selection element, keep it ad Reference only

<scribe> ACTION: update signature 2.0 draft with resolution [recorded in http://www.w3.org/2009/09/22-xmlsec-minutes.html#action05]

<trackbot> Sorry, couldn't find user - update

<scribe> ACTION: pratik to update signature 2.0 draft and remove URI from selection element and keep it in reference only [recorded in http://www.w3.org/2009/09/22-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-370 - Update signature 2.0 draft and remove URI from selection element and keep it in reference only [on Pratik Datta - due 2009-09-29].

<fhirsch> proposed resolution - agree on publication of FPWD of Canonical XML 2.0 and XML Signature 2.0 next week ( 29 September ) and then publish on 6 October

RESOLUTION: decide to publish next week and publish on Oct 6
... agree on publication of FPWD of Canonical XML 2.0 and XML Signature 2.0 next week ( 29 September ) and then publish on 6 October

Streamable XPath Subset

fhirsch: there was a conversation betwene pratik and ed

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0010.html

fhirsch: ed commented that we should have a single text node

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0011.html

esimon2: it's a relative complex topic and hopefully progress will be made weekly
... don't want to be in position not to allow implementations to use full XPath
... agree with scott to define a very minimal subset
... full XPath support would not be mandatory

<fhirsch> ed suggesting mandatory xpath subset, optional full xpath, to enable implementations to be able support in streaming if they can

esimon2: don't want to disallow full xpath, even in streaming

fhirsch: is it reasonable to try to define a minimal subset?

esimon2: not against doing a minimal subset
... implementations may have a programming paradigm or capability to implement transform without restricting XPath

fhirsch: have to figure later how such full XPath implementations can handle the minimum subset
... what about id? issue was that you cannot go backwards

esimon2: there may be programming paradigm that can handle it without restrictions
... transforms are not required to be implemented in a streaming way

fhirsch: isn't there a cost in interoperability to allow both?

esimon2: there is additional testing, but don't necessarily see it as insurmontable. You just need additional test cases
... XSLT implementations don't have the restrict interoperability requirement in signature

<fhirsch> interoperability is concern of being broader

fhirsch: wsi is profiling down because optionality is increasing complexity
... need help to progress this

smullan: signature 2.0 supports older transforms, so why can't we use that to support older transforms?

<fhirsch> sean notes, also for XPath

scantor: is best to keep the 2 as separate goals

fhirsch: it's possibly something we can push to the side for now

pratik: original proposal did not include id, but can include id in a different position

fhirsch: it's a good idea

pratik: the position is also use a lot so we should try to put it in

<fhirsch> these two should go in for next week's draft

pratik: text nodes can be very large and you don't want to load the entire text node in memory

esimon2: even if the text node is referenced by an XPath?

<fhirsch> ACTION: pdatta add id and position handling in step in draft [recorded in http://www.w3.org/2009/09/22-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-371 - Add id and position handling in step in draft [on Pratik Datta - due 2009-09-29].

pratik: have use case to support base64 encoded content, but is supported by referencing the element node, not the child text node

esimon2: will take another look at the doc

pratik: have topic about other axis
... implementations want to find out about the value of an element, but current model require reference to a full subtree

XPath Filter 2

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0009.html

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0014.html

<scribe> ACTION: esimon2 to create an issue for the discussion in email [recorded in http://www.w3.org/2009/09/22-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-372 - Create an issue for the discussion in email [on Ed Simon - due 2009-09-29].

Errata

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Sep/0006.html

bal: don't think issue was explicitly addressed

fhirsch: will send email to the list

<fhirsch> action-354?

<trackbot> ACTION-354 -- Pratik Datta to circulate draft schema for Transform -- due 2009-08-18 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/354

Action review

scantor: can clean up schema later after we close on more substantive issues