XML Security Working Group Teleconference

<trackbot> Date: 17 August 2010

<fjh> Scribe: Hal Lockhart

<fjh> ScribeNick: Hal

Administrative

TPAC registration open (XML Security F2F 1-2 November 2010)

Please complete WG attendance questionnaire as well as TPAC registration if attending in person: http://lists.w3.org/Archives/Member/member-xmlsec/2010Jul/0001.html

XAdES-CAdES remote interoperability event, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0033.html

Minutes Approval

http://lists.w3.org/Archives/Member/member-xmlsec/2010Aug/att-0011/2010-08-10-xmlsec-minutes.html

<fjh> Approve 10 August 2010 minutes

<fjh> Proposed RESOLUTION: Minutes from 10 August 2010 approved.

RESOLUTION: Minutes from 10 August 2010 approved.

C14N2

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

<fjh> minor issues with c14n2

<fjh> 4.10 says that if prefixRewrite is set to none you'd have to "sort

<fjh> the nsToBeOutputList by the prefix", while in the other two cases it

<fjh> says to "sort the nsToBeOutputList by URI". I'm not sure what the

<fjh> correct behaviour is here, but I'm wondering on why we have this

<fjh> differentiation...

Pratik: will have to check into sort by URI or by prefix

<fjh> Update with conformance

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

<fjh> please review this section

<fjh> the conformance section -> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/Overview.html#sec-Conformance-Profiles

Meiko: need to decide about both mandatory and optional cases

Pratik: No indication of which profile is being followed

Meiko: difference between optional parameter and optional alg

<fjh> meiko asks about granularity, whether parameters should be made mandatory or feature sets be made mandatory or optional

need to discuss in document

<fjh> meiko notes we have defaults for parameters, then sets of features with different defaults, so there is much optionality

scott: if you have a whole bunch of options, start from the point of supporting everything

then look at what is painful to implement

<fjh> I suggest Pratik adds explanation to conformance section as to what unit of conformance is, what it means, etc

if nothing is that onerous, then don't have options

fjh: backward compatability was original intent

<fjh> scantor argues against having set 1.x

meiko: would like to review which parameters are optional or mandatory

<fjh> ACTION: mjensen to review c14n2 parameters with regards to conformance and optionality [recorded in http://www.w3.org/2010/08/17-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-625 - Review c14n2 parameters with regards to conformance and optionality [on Meiko Jensen - due 2010-08-24].

<fjh> ACTION-625 due +2 weeks

<trackbot> ACTION-625 Review c14n2 parameters with regards to conformance and optionality due date now +2 weeks

<fjh> ACTION-625?

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

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

Signature 2.0

<fjh> Verification step

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

<fjh> "instead of "selecting" the referenced element

<fjh> via XPath we just "verify" its position (which then is way more flexible

<fjh> in terms of what is really enforced), but stick to ID-based referencing

<fjh> in selection."

fjh: related to question of what is mandatory

<fjh> "are all <Verification> assertions (or whatever we call them

<fjh> in the end) mandatory to hold, meaning that signature verification will

<fjh> fail if one of them does not hold? Or are they "optional" in the sense

<fjh> that a verifier may ignore them, as long as the digests and signature

<fjh> values match?"

<fjh> suggest that we have id referencing now without verification, so this could be optional, add value if wanted

<fjh> ISSUE: is Verification assertion mandatory to implement, is presence/verification optional

<trackbot> Created ISSUE-209 - Is Verification assertion mandatory to implement, is presence/verification optional ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/209/edit .

<fjh> sense of group is that use is optional

<fjh> verification element could introduce new attacks, e.g. put in bad verification for legitimate id, then signature verification could fail?

<fjh> ISSUE-209: need to agree in WG and in draft

<trackbot> ISSUE-209 Is Verification assertion mandatory to implement, is presence/verification optional notes added

<fjh> answer , probably not since integrity protected, but scott raises concern of new denial of service attacks as a possibility

Meiko: XPath based verification is difficult when streaming

Pratik: apart from length, I put in an option to put in base 64 encoding of c14n'd content

<pdatta> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-Verification-2.0

<fjh> group discusses 4.4.3.9 The dsig2:Verification element

<fjh> meiko questions value of <dsig2:DigestData> since the hash value is available

<fjh> ACTION: pdatta to remove <dsig2:DigestData> from 4.4.3.9 The dsig2:Verification element in Signature 2 [recorded in http://www.w3.org/2010/08/17-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-626 - Remove <dsig2:DigestData> from 4.4.3.9 The dsig2:Verification element in Signature 2 [on Pratik Datta - due 2010-08-24].

<fjh> ACTION: pdatta to add id verification proposal from meiko to Signature 2.0, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0030.html [recorded in http://www.w3.org/2010/08/17-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-627 - Add id verification proposal from meiko to Signature 2.0, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0030.html [on Pratik Datta - due 2010-08-24].

Streaming XPath

fjh: generation requires 2 paths, verification only one

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

<fjh> meiko notes much care is needed on verification side due to attacks, and have to deal with attacks based on memory size

Meiko: receiver has to worry about attacks, sender does not

<fjh> "signature verification can be done

<fjh> in one-pass, as long as no backward references are used"

if receiver only needs to use parts of data, 1 pass is a big win

Patik: can't really verify in 1 pass

<fjh> pratik notes that have to keep received content in buffer anyway, so that app doesn't process until signature verification complete

<Cynthia> You could sign each MPEG block...

<scantor> right

<Zakim> fjh, you wanted to ask about apps that don't wait for verification

Scott: need to agree on exactly what we mean by streaming in order to evaluate features

<Cynthia> That is my problem also, what is streaming and what are the limits of what we will support for streaming

<pdatta> I would like to keep the selection, XPath , canonicalization and digesting in one pass,

<pdatta> but allow for forward/backward references

<fjh> we should distinguish sending/signing from receiving/verification, and be explicit about streaming requirements for each

<fjh> hal notes that signing might be less frequent from verification

Cyntha: better to break up large data in app

<fjh> cynthia notes that we should distinguish two use cases, those that require much memory and those that don't

<fjh> sounds like we need an action to summarize the issues and choices here

<fjh> pratik suggests focusing on 1pass for streaming XPath to make progress now

<Cynthia> I agree

<fjh> ACTION: meiko to send email address book example of 1-pass vs 2-pass to list [recorded in http://www.w3.org/2010/08/17-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-628 - Send email address book example of 1-pass vs 2-pass to list [on Meiko Jensen - due 2010-08-24].

<fjh> ACTION: fjh to summarize discussion on issues and streaming use cases on email list [recorded in http://www.w3.org/2010/08/17-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-629 - Summarize discussion on issues and streaming use cases on email list [on Frederick Hirsch - due 2010-08-24].

<fjh> brich suggests noting clear use path in a document, and noting where diversions can lead to difficulties (in best practices?), need to be clear on assumptions, focus on simplified XPath

Publication

wanted to publish 3 specs at the same time, fairly soon

Pratik: have not incorporated Meiko's feedback - only big thing

fjh: perhaps publish on Aug 26?

<fjh> ACTION-476?

<trackbot> ACTION-476 -- Frederick Hirsch to review xml signature 2.0 -- due 2010-08-18 -- OPEN

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

<Cynthia> ACTION-620 is not complete

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

<trackbot> ACTION-581 -- Scott Cantor to make proposal around IDness of attributes -- due 2010-06-15 -- OPEN

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

Meiko: need to investigate if Scott's proposal solves the problem

<fjh> ACTION-548?

<trackbot> ACTION-548 -- Ed Simon to ed to review XPath Profile -- due 2010-04-20 -- OPEN

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

<fjh> ACTION-614?

<trackbot> ACTION-614 -- Meiko Jensen to review XPath Profile -- due 2010-08-10 -- OPEN

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

<fjh> ACTION-614 closed

<trackbot> ACTION-614 Review XPath Profile closed

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

<fjh> Streamable XPath Profile Review

Pratik: have to decide if we allow descendant access

Meiko: can get something that is not even well formed XML from C14N

<fjh> pratik notes can have multiple disjoint subtrees in C14N

Meiko: problem is when you are doing streaming
... can be done more simply

<fjh> meiko notes his comments are based on his implementation experience

fjh: propose we clean up minor changes and publish by Aug 26

<fjh> ACTION-621?

<trackbot> ACTION-621 -- Thomas Roessler to propose ECC-related refactoring of spec -- due 2010-08-31 -- OPEN

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

<fjh> Publish FPWD of XPath profile, updated WD of Canonical XML 2.0 and updated WD of XML Signature 2.0 at end of August? Edits complete by 10th, agree to publish on 17th, publish on 24th? Also publish update to "XML Security RELAX NG Schemas" and Best Practices at this time?

<fjh> ACTION: fjh to remove or update the change log in best practices [recorded in http://www.w3.org/2010/08/17-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-630 - Remove or update the change log in best practices [on Frederick Hirsch - due 2010-08-24].

<fjh> plan to complete edits this week, review and WG formal decision to publish on 24th and publish on 26th

<fjh> ACTION-615?

<trackbot> ACTION-615 -- Pratik Datta to update URI for XPath in XML Signature 2.0 -- due 2010-08-03 -- OPEN

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

<Cynthia> ACTION-620 is not complete

<fjh> ACTION-620?

<trackbot> ACTION-620 -- Cynthia Martin to review C14N2 references, ISSUE-200 -- due 2010-08-10 -- OPEN

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

<Cynthia> I will get it done this week

<fjh> ACTION-622?

<trackbot> ACTION-622 -- Thomas Roessler to propose wording for response to EXI WG on LC-2386 LC-2387 -- due 2010-08-17 -- OPEN

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

<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> ISSUE-205?

<trackbot> ISSUE-205 -- Entity expansion risks associated with signature processing -- open

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

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

<fjh> resolution was that this has already happened by the parser, so moot

<fjh> in C14N2 input is always subtrees, has been done by parser, so nothing to be done here.

<fjh> ISSUE-205: in C14N2 input is always subtrees, has been done by parser, so nothing to be done here.

<trackbot> ISSUE-205 Entity expansion risks associated with signature processing notes added

<fjh> ISSUE-205 closed

<trackbot> ISSUE-205 Entity expansion risks associated with signature processing closed

Magic Signatures

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

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

<fjh> hal: if signing non-xml, could represent data in json

<fjh> hal: signatures can break depending on where you put data, base64 encoding prevents this

<fjh> Ed raised issue that XML Signature handles many business use cases that magic signatures do not

<fjh> I believe hal noted that magic signature offers a wire format that is stable in various protocols etc

<fjh> Hal notes that magic signatures does not support a variety of algorithms

<Cynthia> We still need to respond, but need to coordinate with the W3C (larger organization)

<fjh> magic signatures may meet certain requirements that might differ from those of XML Signature

<fjh> will consider how to respond off line