XML Security Working Group Teleconference
09 Sep 2008

 

 

<trackbot> Date: 09 September 2008

<fjh> Scribe: Brad Hill

http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0029.html

Administrivia

<fjh> TPAC - Hotel reservation deadline extended to 20 Sept

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

fjh: who is attending TPAC?

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

fjh: one from w3c, one from working group, please do both

<fjh> http://www.w3.org/2002/09/wbs/42458/tpac2008xmlsec/

hal: will try to attend by phone

brad: will try to attend by phone

rdmiller: will attend in person

<klanz2> re action review: action 16 should have been closed with reference to http://www.w3.org/mid/488F2E60.3000507%2540iaik.tugraz.at

F2F planning

<fjh> http://www.w3.org/2002/09/wbs/42458/xmlsecearly2009/results

fjh: resolution proposed for January 13-14 for F2F in redwood city

hal: any date in Jan/Feb for hosting

<klanz2> http://www.etsi.org/plugtests/XAdES2/html/XAdES2.htm

<klanz2> Remote CAdES / XAdES plugtest 16-27 February 2009

<klanz2> * Registration Deadline January 2008

<gedgar> I will plan on making this meeting.

<klanz2> Jan is fine

hal, klanz, gedgar are OK with proposed date

resolution proposed to accept this date

Jan 13-14

<fjh>

RESOLUTION: F2F January 13-14 January 2009 at Redwood City, CA hosted by Oracle

fjh: (to hal) any additional setup, teleconference, etc.?

hal: headcount for food as we get closer

Liasons & coordination

fjh: 3 joint sessions in F2F

<fjh> XForms http://lists.w3.org/Archives/Member/member-xmlsec/2008Sep/0003.html

<fjh> EXI http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0005.html

<fjh> comments http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0028.html

esimon2: EXI will require a careful, in-depth look at re-thinking signature, no time this year on my schedule

<fjh> Web Applications, 11 am

<fjh> day2

<fjh> Schema, XProc, informal session with Norm

<fjh> schema mail thread http://lists.w3.org/Archives/Member/member-xmlsec/2008Sep/0011.html

klanz2: I am not an NVDL expert

rdmiller: I brought up NVDL, can pull together a small introduction

<klanz2> Namespace-based Validation Dispatching Language

<klanz2> source: http://www.xfront.com/nvdl/

<fjh> ACTION: rmiller3 Provide a presentation to the working group introducing NVDL. [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-54 - Provide a presentation to the working group introducing NVDL. [on Robert Miller - due 2008-09-16].

<esimon2> http://nvdl.org/

esimon: namespace specific c14n as it relates to NVDL

<fjh> xproc - additional conversation and review rqd

fjh: xslt group rep to speak with us on next week's call re: xpath, specifically xpath profiles
... any issue with next week? [none] will conclude arrangements for them to join our call next week

XML 2nd edition coordination

<fjh> WS-Policy http://lists.w3.org/Archives/Public/public-ws-policy/2008Sep/0000.html

<esimon2> Last year, I presented on Namespace-specific canonicalization -- those thoughts may be relevant to NVDL. I would also refer those interested to the comments of Henry S. Thompson (of the XML Schema WG) recorded in the minutes.

<fjh> OASIS SSTC, WS-SX

fjh: also work with Federation working group pre public draft, similar to WS-SX

<fjh> ACTION: brich Check with WS-Federation regarding XML Signature 2nd edition references [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-55 - Check with WS-Federation regarding XML Signature 2nd edition references [on Bruce Rich - due 2008-09-16].

minutes approval

fjh: any objection?

RESOLUTION: Approve minutes from 2nd september.

Best practices

bhill: CVS will be updated by noon today
... technical difficulties with keys on my side, apologies for lateness of update

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

<scribe> ACTION: scantor Propose text for KeyInfo processing in best practices. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0014.html [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-56 - Propose text for KeyInfo processing in best practices. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0014.html [on Scott Cantor - due 2008-09-16].

fjh: publication as draft desired, any objections?

pdatta: have examples been tested adequately?

fjh: suggest publishing document only, not sample files

pdatta: examples inline in document
... concern is, do the attacks work?

fjh: good to have this in public as work product, "heartbeat"

klanz: do we have a cvs directory of DOS cases?
... propose interop/test event on DOS test cases

fjh: when to do this?

smullan: now, if document is close to draft publication

brich: asking vendors to validate these attacks as working?

bal: difficulty in public disclosure on vulnerabilities

klanz2: just a private ack of testing

fjh: hard to keep this confidential

<klanz2> +1

fjh: approve best practices without approving specific attack scenarios
... those with concerns will take it upon themselves to review the DOS criteria and suggest corrections

<brich> +1

<klanz2> there is awareness now, so let's have an best practices review action on implementers until 1-3 Month or so ?

<fjh> Proposed ACTION: brich review best practices document from implementation standpoint

<klanz2> jcc

<klanz2> 1 Month

<fjh> ACTION: brich review best practices document from implementation standpoint [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-57 - Review best practices document from implementation standpoint [on Bruce Rich - due 2008-09-16].

<fjh> ACTION: jcc review best practices document from implementation standpoint [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-58 - Review best practices document from implementation standpoint [on Juan Carlos Cruellas - due 2008-09-16].

<fjh> ACTION: pdatta review best practices document from implementation standpoint [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-59 - Review best practices document from implementation standpoint [on Pratik Datta - due 2008-09-16].

note on ACTION: proposed due date in 1 month for implementers to review

<fjh> ACTION: klanz review best practices document from implementation standpoint [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action09]

<trackbot> Created ACTION-60 - Review best practices document from implementation standpoint [on Konrad Lanz - due 2008-09-16].

<fjh> ACTION: bal review best practices document from implementation standpoint [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action10]

<trackbot> Created ACTION-61 - Review best practices document from implementation standpoint [on Brian LaMacchia - due 2008-09-16].

<fjh> ACTION: sean review best practices document from implementation standpoint [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action11]

<trackbot> Created ACTION-62 - Review best practices document from implementation standpoint [on Sean Mullan - due 2008-09-16].

<csolc> add me

<fjh> ACTION: rmiller3 review best practices document from implementation standpoint [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action12]

<trackbot> Created ACTION-63 - Review best practices document from implementation standpoint [on Robert Miller - due 2008-09-16].

<fjh> ACTION: csolc review best practices document from implementation standpoint [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action13]

<trackbot> Created ACTION-64 - Review best practices document from implementation standpoint [on Chris Solc - due 2008-09-16].

<gedgar> I too will look it over.

Use cases and requirements

<klanz2> link?

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/Overview.html

<klanz2> thx

<csolc> oh wanted to add an requirement

klanz: working on action 51, surrounding primitives of interoperable transforms for removing content, whitespace, prefixes, etc.

csolc: no ability to do byte-range signatures over binary content, add requirement

fjh: what does it mean to sign a byte range? for protocols?

csolc: use case is for docuements that grow over time, differential signatures on appended content
... ability to sign with gaps

hal: example of use case for signing log files

<klanz2> ISO-32000 ?

<klanz2> PDF-SPEC ?

<scribe> ACTION: csolc Document use case and semantics of byte-range signatures. [recorded in http://www.w3.org/2008/09/09-xmlsec-minutes.html#action14]

<trackbot> Created ACTION-65 - Document use case and semantics of byte-range signatures. [on Chris Solc - due 2008-09-16].

ck klanz

<fjh> klanz notes that PDF might be target of XAdES signature

klanz: suggest referencing ISO-3200, PDF-SPEC in defining these transforms

<klanz2> there is also interest within XAdES community to be able to do this

fjh: other missing use cases?

v.next

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

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

smullan: questioning streaming profile proposed by pdatta, burden is on signature implementer to create streaming implementation; probably end up with something similar to XPath anyway. Prefer to keep it as simple as posible. Discussion with Xpath working group will be helpful.

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

scantor: 2 points, one dovetails w/smullan. other: think burden of proof should be on why it should NOT be Xpath, given extra cost of implementing new method vs. reuse of existing Xpath libraries

pdatta: xpath subset can meet most use cases. if use case outside of this subset discovered: where to draw the line on adding complexity?

klanz2: make use of MUST, SHOULD and RECOMMENDED to give us flexibility

fjh: amdahl's law, hard to know where to focus on performance optimization, how to divide the areas of attention

<klanz2> c14n as preprocessing normalization

fjh: are we constraining ourselves to not change implementation? can we create a new model that doesn't require c14n in the same places?
... to discuss on the list

<klanz2> +1

fjh: is c14n of SignedInfo small enough in implementations to entertain changing?

<klanz2> to pratik, saying SignedInfo is small usually

fjh: to pdatta, what is the scope of your performance tests?

pdatta: in my test cases, xpath is ~90% of time used

fjh: to refer to workshop results, make sure we are not missing important areas when optimizing performance

<csolc> I don't have hard numbers but I do know the majority of our time is in the canonicalization trasform on the signed content, not the signed info.

<klanz2> +1 namespaces are horrible

hal: namespaces take 50% of time

bal: anecdotally complaints are about c14n, no hard data at hand

klanz: limit selection of subsets to not being able to remove namespaces would be a big improvement
... this is all in pdatta's work, need to draft this as a paper

<klanz2> http://www.w3.org/2007/xmlsec/ws/papers/12-mishra-oracle/#page=3

<klanz2> I think that's it

fjh: issues with general turing machine re: security, performance

c14n public comment

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/att-0013/00-part

pdatta: reducing size of c14n output doesn't matter, if only used for digesting, as digest is fixed size

fjh: but if c14n can be treated as a source document for later in the tranform chain...

<klanz2> indempodency of transformsallows you to view the output again as input

hal: underlying assumption was a pluggable pipline: any output suitable as input. is this generality required?
... also, ability to propagate c14n output on the network as a best practice

klanz: 'what you see is what you sign' in original spec makes c14n at end important to normalize

<fjh> klanz noted could either have what you see is what you sign is the input to transforms or output

<fjh> klanz noted if input then transforms are processing that is non-substantive, if output, create new viewable model

<klanz2> There is esentially two (maybe three) big general viewpoints to look at the chain of transforms

<fjh> requirement is see what you sign. can it be achieved in different ways that are more efficient

<klanz2> 1. remodel the building of a viewable document from arbitrary xml (e.g. XSLT)

<klanz2> different processors screwed things like line-endings and namespaces up and c14n is supposed to fix this again

<fjh> question, what is the proper role of canonicalization in a processing pipe, e.g. only for generating hashes at points or needed for see what you sign

<klanz2> 2. an enabler for robustness and here the data of interest is the acual input rather than the viewable output

<fjh> question, does this depend on the extent of what canonicalization actually does, e.g. does simplification also enable only hashing approach

<klanz2> for two typical cases are, white space normalization, ....

<klanz2> and as a subcase subdocument selection

<klanz2> indempodency of transforms for 2. would allow to view the input to the chain of transforms equal to the output

<klanz2> as you could perform it over and over again and after the first processing it would not change any more

<klanz2> pratik: tracing back nodes to the input

pdatta: for transform chain, see if you can programmatically determine what is being signed, split selection transforms from c14n operations; view as two operations rather than a continuous pipeline

<klanz2> pratik: as soon as you go to octet stream it is not traceable back to the input document

<klanz2> the nodes are gone

klanz: distinguish between transforms which create a new document vs. changing the document in a way that allows tracability to the original one

<fjh> klanz notes that can separate parts of c14n, separating what is semantically insignificant from what is structurally insignificant, e.g. line ending versus namespace propagation

fjh: is recommending APIs in scope for this group?

pdatta: was asking what do we have to do in the spec to enable certain APIs by making sure certain information is available

brich: last discussion got away from needs/scope of detached signatures, which may select content from several documents

<klanz2> pratik: let's talk about the dereferenced document

klanz: transform chain does not make explicit when reference to original document is lost and content must be reparsed

fjh: (summarizing klanz) lack of modularization in tranforms adds unnecessary work between nodeset/octet stream/nodeset for certain normalizations that should be possible within the original nodeset context

<fjh> klanz stay within referenced doc

klanz: property of staying in original document important for determining what portions were signed
... distinguish between "selection" and "transformation"

<esimon2> selection is a query (read only); transformation is a modification

fjh: transform is general, create a subset of transforms with constrained semantics

<fjh> goal is to have specific transforms defined for efficiency and clarity

issues list

<fjh> new issue on schema normalization, issue-51

fjh: next steps, consolidate issues, move where necessary to requirements

<klanz2> re action review: action 16 should have been closed with reference to http://www.w3.org/mid/488F2E60.3000507%2540iaik.tugraz.at

actions

<fjh> action-43 close

<fjh> ACTION-43 closed

<trackbot> ACTION-43 Write about constrained nodesets requirement closed

ACTION-50 close

ACTION-50 closed

<trackbot> ACTION-50 Draft a strawman for alternative to xpath transform closed

ACTION-16 closed

<trackbot> ACTION-16 Write up proposal regarding use of transform that has parameter for passing xml model closed

<scantor> Action 37 should be done

<fjh> action 22 open until message sent to exi list

<shivaram> yes

ACTION-37 closed

<trackbot> ACTION-37 Write up scenario for simple sign closed

<shivaram> yes - I will do it this week

<scantor> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0047.html

<fjh> ACTION-30 shivaram will help with this

<klanz2> thank you everyone

<gedgar> byw all