See also: IRC log
<trackbot> Date: 09 September 2008
<fjh> Scribe: Brad Hill
<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
<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
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
<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].
fjh: any objection?
RESOLUTION: Approve minutes from 2nd september.
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.
<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?
<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
<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
<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
<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