XML Security Working Group Teleconference

<trackbot> Date: 07 September 2010

<magnus> scribenick: magnus

Administrative

<fjh> Please complete WG questionnaire: http://www.w3.org/2002/09/wbs/42458/tpac2010xmlsec/

<fjh> If attending remember to complete TPAC registration (separate from WG questionnaire)

<fjh> http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/

<fjh> ACTION-652, tlr to request conference bridge

<fjh> updated roadmap, please review http://lists.w3.org/Archives/Member/member-xmlsec/2010Sep/0004.html

Minutes approval

<fjh> Approve 31 August 2010 minutes

<fjh> http://www.w3.org/2010/08/31-xmlsec-minutes.html

RESOLUTION: Minutes from August 31 approved.

Publication Status

<fjh> Updated WDs of "XML Signature 2.0", "Canonical XML 2.0", "XML Security RELAX NG Schemas", "XML Signature Best Practices" published. FPWD of "XML Signature Streaming Profile of XPath 1.0" published. Updated WG publication status and WG home pages.

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0000.html

Canonical XML 2.0

<fjh> ACTION-625?

<trackbot> ACTION-625 -- Meiko Jensen to review c14n2 parameters with regards to conformance and optionality -- due 2010-08-31 -- PENDINGREVIEW

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

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0001.html

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

mjensen: The action was around optionality level of canonicalization params
... two interpretations

<Gerald-E> yes...

<scribe> ScribeNick: magnus

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0007.html

<fjh> . 1. Support C14N2 with defaults as listed for all parameters. All other parameters not at default settings are optional.

<fjh> 2. Also support ExclusiveMode, InclusiveNamespace, IgnoreComments and XmlAncestors parameters with values other then defaults

<scantor> +1

mjensen: Shall the new be optional and the old mandatory?

<fjh> scantor: doesn't make sense to have new parameters optional if we want to fix anything

fjh: Do you want to have several level of conformance, Miko?

mjensen: Think it is better to have two levels of optionality.

<fjh> require full support for ExclusiveMode, InclusiveNamespace, IgnoreComments and XmlAncestor parameters

pdatta: We also have a req for simplicity...minimal canonicalization. That's why we may need different levels.

scantor: Understand point of simplification. Get rid of XPath solves most of the problem though. The other simplification is better robustness.
... From that point of view, thinks Pratik's proposal takes care of most of it.

<fjh> ... simplification of canonicalization achieved by XPath simplification, also simplification of solution robustness needed, reducing optionality helps here

mjensen: Will it be a simplifications to require all conformant implementations to support this set of parameters? Splitting in required and optional params
... the tradeoff between simplifying for users and more burden on developers may be worth it. Skip the profiles.

pdatta: If IgnoreComments, say, is optional, what does it mean? Always ignore it?

mjensen: A conformant library may or may not implement this switch. I.e. another component may use it and you may not, so interop may be hurt.

<fjh> limiting optionality can give more siimplicity

scantor: Don't think canonicalization is the place for optionality.

<csolc> I agree with scantor

scantor: Should strongly consider if we should keep the optionality in the spec.

bal: There are cases when you need to turn optionality on. There are also cases when you need to turn them off. But we don't want selective on/off due to the combinatorial explosion for conformance.

<fjh> bal: different use cases - semantic equivalent, want most on; fast and simple, want most off.

scantor: Don't think the options add a lot to the performance problem.

bal: Some options are also grouped with others.
... Don't think we will get away from that selectability.

mjensen: Another issue: A pre-processor could do some of these transformation - before signature creation etc. Q: Are we proposing a set of switches, two different set of canonicalization ideas?

<fjh> ISSUE: C14N2 conformance - optional parameters, profiles, etc

<trackbot> Created ISSUE-215 - C14N2 conformance - optional parameters, profiles, etc ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/215/edit .

csolc: Will it make the code faster or smaller without these options? How much of codesize footprint will be added due to optionality?
... Should be mandatory unless significantly impact codesize etc.

mjensen: Can try to get some performance data.

<fjh> ACTION: mjensen to provide some performance data related to implementing entire c14n2 with all options, to influence choices regarding conformance [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-654 - Provide some performance data related to implementing entire c14n2 with all options, to influence choices regarding conformance [on Meiko Jensen - due 2010-09-14].

pdatta: Still, certain combinations of params are not useful/ do not make sense.

hal: Pointing to implementation-difficulty and not performance.

scantor: Thnk XPath is a big part of that.
... The one that is a bit of annoyance is prefix rewriting.

fjh: Have heard arguments both ways - more mandatory (ease of implementation, interop guarantees), but also for optionality (performance etc.).

pdatta: Can start thread to identify groups of params. Somewhat orthogonal to mandatory or not but related.

<fjh> ACTION: pdatta to start email thread on which parameters to be treated as group [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-655 - Start email thread on which parameters to be treated as group [on Pratik Datta - due 2010-09-14].

<scantor> we should identify invalid combinations of parameters

<fjh> ACTION: fjh to contact aleksey re review of 2.0 specs and optionality/conformance [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-656 - Contact aleksey re review of 2.0 specs and optionality/conformance [on Frederick Hirsch - due 2010-09-14].

<scantor> and identify options that have questionable use cases

<fjh> ACTION: fjh to initiate use case review for c14N2 [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-657 - Initiate use case review for c14N2 [on Frederick Hirsch - due 2010-09-14].

XML Signature 2.0 Namespace Injection

<fjh> ACTION-538?

<trackbot> ACTION-538 -- Meiko Jensen to provide proposal related to namespace wrapping attacks once XPath profile available -- due 2010-03-09 -- OPEN

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

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0027.html

<fjh> Approach #3: prohibit QNames in XPath

<fjh> Approach #4: listing used QNames explicitly

<fjh> "/*[local-name()='Body' and

<fjh> namespace-uri()='http://www.w3.org/2003/05/soap-envelope']"

<fjh> instead of

<fjh> "/soap:Body"

scantor: Just arguing that the option of not having QNames in XPath should be documented well.

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

mjensen: Where to put the explanation? XPath profile?

<fjh> mjensen: limiting XPath already, why not limit more in XPath profile

<fjh> proposed RESOLUTION: prohibit QNames in XPath

pdatta: Also considered other options...?

scantor: If someone wants to write a precise algorithm I am OK with this but I think option 3 is important because it is a safe approach.

<fjh> scantor notes that choice #3 has issue that users will still attempt to use QNames in XPath, so it might not be feasible

pdatta: Now scanning with subset of XPath is easier.
... Can write up proposal for prefix scanning

<fjh> ACTION: pdatta to provide proposal on scanning option [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-658 - Provide proposal on scanning option [on Pratik Datta - due 2010-09-14].

<fjh> ACTION-658: Meiko can assist

<trackbot> ACTION-658 Provide proposal on scanning option notes added

<fjh> ACTION-658: to create ISSUE as well

<trackbot> ACTION-658 Provide proposal on scanning option notes added

<fjh> ACTION-658: http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0027.html

<trackbot> ACTION-658 Provide proposal on scanning option notes added

XML Encryption

<fjh> ACTION-280?

<trackbot> ACTION-280 -- Magnus Nyström to produce test cases for derived keys -- due 2009-05-19 -- OPEN

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

fjh: Test cases for derived keys?

magnus: Yes, expect to produce these.

<fjh> ISSUE-132?

<trackbot> ISSUE-132 -- Keep 2.0 xenc transform feature in sync with signature 2.0 -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/132

<fjh> [tlr]: suggest to revisit when xml sig 2.0 comes out of last call

XML Signature 2.0 Schema and serial number

<fjh> ISSUE-43?

<trackbot> ISSUE-43 -- Improvements to XML Signature schema -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/43

<fjh> ISSUE-43: remaining action is for mixed content, also IssueSerial

<trackbot> ISSUE-43 Improvements to XML Signature schema notes added

XML Signature 2.0 actions

<fjh> ACTION-638?

<trackbot> ACTION-638 -- Scott Cantor to make proposal for ISSUE-210, see also http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0043.html (uncomplicate section) -- due 2010-08-31 -- OPEN

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

<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> ACTION-648?

<trackbot> ACTION-648 -- Pratik Datta to flesh out 6.8, shuffle order of sections, define URI for C14N2, see ISSUE-160 -- due 2010-09-07 -- OPEN

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

<fjh> ACTION-647?

<trackbot> ACTION-647 -- Pratik Datta to implement Cantor's proposed text to identify all attributes -- due 2010-09-07 -- OPEN

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

<fjh> ACTION-653?

<trackbot> ACTION-653 -- Frederick Hirsch to review status of ISSUE-183 -- due 2010-09-09 -- OPEN

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

<shivaram> I can scribe

<Gerald-E> I too have to leave..

<fjh> ScribeNick: shivaram

XML Signature Streaming Profile of XPath 1.0

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

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

mjensnen: does not like the position of the proposal, not sure belongs in streaming XPath profile

mjensen: when drafting the text, tried to use the syntax of XML Sig 2.0. Found smaller issues
... issues: contains new transform model for URI
... issues: since we dropped all the transform models, how to cope with enveloped signatures. Proabaly use XPATH? which may be an issue for some developers

<fjh> regarding, http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-XPath-2.0

ffj: isn't there a problem with streaming w/ generator or verifier

mjensen: if there is a reference to something before signature value then there is no problem

ffj: have people looked at the draft?

<fjh> will decide regarding adopting http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0013.html next week, please review

pdatta: for verification, it is good to have forward references

<fjh> meiko notes that for generation the streaming problem might not exist, since signer knows in advance what they wish to sign, so can act accordingly

meiko: signer knows what he is talking about, hence did not look at it from signer point of view

fjh: we need to update URIs

pdatta: what should be the new URI value

<fjh> ACTION: pdatta to review newTransformModel URI and does URI need correct? http://www.w3.org/2010/xmldsig2#newTransformModel in Signature 2.0 [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-659 - Review newTransformModel URI and does URI need correct? http://www.w3.org/2010/xmldsig2#newTransformModel in Signature 2.0 [on Pratik Datta - due 2010-09-14].

fjh: will review this offline to understand better about the new URI

<fjh> Enveloped signature question, how to handle in 2.0 model without transforms

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-subtrees-with-exclusions

scantor: I don't think this option would work anyway, but there was never a way to identify the signature itself
... this does not work with streaming as the interface is different from the DOM case
... suggest take a look at C14n doc and add something to DOM case and leave streaming case alone
... don't want to use XPATH for doing enveloped signatures

<fjh> why wouldn't this be possible via selection with ecxlusion of signature via id

<fjh> scott suggest not requiring use of XPath, hence have C14N2 have option to pass node that should be excluded into C14N2 interface

<fjh> scantor: propose changes to C14N2 to support enveloped signature

<fjh> ACTION: scantor to propose changes to C14N2 to support enveloped signature [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-660 - Propose changes to C14N2 to support enveloped signature, should happen by default, since always needed, implicit[on Scott Cantor - due 2010-09-14].

pdatta: could be done without XPATH. User should not need to mention exclude signature

scantor: will try to address DOM case atleast in his action

<fjh> ACTION-644?

<trackbot> ACTION-644 -- Meiko Jensen to propose text for Streaming XPath Profile to note that 1-pass not always possible, giving examples where 1-pass is not possible -- due 2010-08-31 -- PENDINGREVIEW

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

<bal> i've got to drop off now...

pdatta: issues about ids and XPATH
... to send an email about issue

<fjh> ACTION: pdatta to summarize issue related to use of ID without DTD for discussion and resolution [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-661 - Summarize issue related to use of ID without DTD for discussion and resolution [on Pratik Datta - due 2010-09-14].

pdata: a new element was added in 2.0 - verification which needs to be added into the schema

<fjh> ACTION: pdatta add verification element to 2.0 schema [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action09]

<trackbot> Created ACTION-662 - Add verification element to 2.0 schema [on Pratik Datta - due 2010-09-14].

Best Practices

<fjh> proposal, http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0014.html

mjensen: explained the idea behind the attack pattern

fjh: should we provide this much of info in the doc to expose attack pattern

how about including a test case in the suite for this?

<fjh> propose we agree to adopt this proposal next week

<fjh> ACTION: fjh add decisions to next week's agenda from Meiko on Streaming Profile http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0013.html and Best Practices http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0014.html [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action10]

<trackbot> Created ACTION-663 - Add decisions to next week's agenda from Meiko on Streaming Profile http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0013.html and Best Practices http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0014.html [on Frederick Hirsch - due 2010-09-14].

<fjh> ISSUE: whether and how to test denial of service cases in test suite

<trackbot> Created ISSUE-216 - Whether and how to test denial of service cases in test suite ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/216/edit .

<fjh> ISSUE-216: not an issue if attacker cannot modify XPath, so maybe test not needed (Meiko)

<trackbot> ISSUE-216 Whether and how to test denial of service cases in test suite notes added

<fjh> ACTION-604?

<trackbot> ACTION-604 -- Hal Lockhart to propose change for best practices for ISSUE-170 -- due 2010-07-06 -- OPEN

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

<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> ACTION-643?

<trackbot> ACTION-643 -- Meiko Jensen to propose text for best practices re ISSUE-212, attack noted in http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0020.html -- due 2010-08-31 -- PENDINGREVIEW

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

Interop and F2F planning

fjh: please suggest ideas

<fjh> please indicate on members list when and how you can participate in interop

<fjh> please also suggest F2F topics

Other Business

mjensen: XML Sec 2.0 does not contain full example - idness of Qnames, etc
... need a full XML Sig 2.0 mode example

<fjh> ISSUE: XML Signature 2.0 needs 2.0 mode examples, e.g. , verification, selection etc.

<trackbot> Created ISSUE-217 - XML Signature 2.0 needs 2.0 mode examples, e.g. , verification, selection etc. ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/217/edit .

<fjh> can start with example Meiko proposed

mjensen: has a base which can be used to generate example

scantor: can help with the example if someone else is doing it

<fjh> ACTION: mjensen to propose examples for 2.0 mode in XML Signature 2.0 [recorded in http://www.w3.org/2010/09/07-xmlsec-minutes.html#action11]

<trackbot> Created ACTION-664 - Propose examples for 2.0 mode in XML Signature 2.0 [on Meiko Jensen - due 2010-09-14].

mjensen: can bootstrap the process and would like help from scantor

<fjh> regrets from Meiko for October meetings.

mjensen: regarding examples;