See also: IRC log
>fjh: Scribe: Sean Mullan
fjh: http://www.w3.org/2008/10/TPAC/Schedule
fjh: plenary planned for Oct 20-24, start planning for it
... need to register also
fjh: F2F planning ...
hal: Oracle can potentially host in Redwood City
esimon2: +1 to Redwood!
brich: the registration link is http://www.w3.org/2008/10/TPAC/Overview.html#Registration
bal: also could host but Seattle in Feb may not be best time of year
fjh: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html
fjh: xades plugfest coming up
fhirsch3: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html
Minutes 16 July: http://www.w3.org/2008/07/16-xmlsec-minutes.html
Minutes 17 July: http://www.w3.org/2008/07/17-xmlsec-minutes.html
RESOLUTION: Minutes from 16/17 July approved
fhirsch3: Minutes 29 July http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/att-0041/29-xmlsec-minutes.html
RESOLUTION: 29 July minutes approved
fhirsch3: Pending action items
fjh: process: open action items, annotate items, can link emails as annotations, email group when action is done, go over in meeting
<smullan> ACTION-9 CLOSED
<trackbot> ACTION-9 Fix Tracker closed
<smullan> ACTION-3 CLOSED
<trackbot> ACTION-3 RNG Schema: Check on status with customer. closed
<smullan> ACTION-10 CLOSED
<trackbot> ACTION-10 Update wg page to include issues link closed
<smullan> ACTION-11 CLOSED
<trackbot> ACTION-11 Ask for XPath 2.0 presentation to group closed
fjh: keep action 12 open
<smullan> ACTION-14 CLOSED
<trackbot> ACTION-14 Ask about namespaces/undeclarations in xml coordination group closed
<fhirsch3> draft message re XPath http://lists.w3.org/Archives/Member/member-xmlsec/2008Aug/0001.html
fjh: action 20, draft message has been sent to group
<smullan> ... does it look ok?
<smullan> +1
<smullan> RESOLUTION: workgroup agrees message is ok
gerald: no objections
<smullan> ACTION-20 CLOSED
<trackbot> ACTION-20 Draft message about XPath 2 presentation to mailing list closed
<fhirsch3> product list is at http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0001.html
<smullan> ACTION-26 CLOSED
<trackbot> ACTION-26 Define products in tracker and associate with actions/issues closed
fhirsch3: see http://www.w3.org/2008/xmlsec/actions-open.html
<fhirsch3> http://www.w3.org/2008/xmlsec/track/actions/open
<smullan> ACTION-2 review
<smullan> tlr: still working on it
<smullan> ACTION-4 still open
<smullan> ACTION-5 still open
<smullan> ACTION-6 : sean not the right person, need someone else
<smullan> ... should be assigned to someone else
<scribe> ACTION: thomas to investigate ebXML liaison (see ACTION-6) [recorded in http://www.w3.org/2008/08/12-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-31 - Investigate ebXML liaison (see ACTION-6) [on Thomas Roessler - due 2008-08-19].
ACTION-6 closed
<trackbot> ACTION-6 Investigate ebxml liasion closed
tlr: close action 6 and make new one assigned to tlr
brich: ACTION-7 still open
<smullan> ACTION-13 still open
bal: ACTION-15, draft proposal sent to list
<smullan> ACTION-15 CLOSED
<trackbot> ACTION-15 Provide proposal on xmlsec namespace approach to identify elements to be processed closed
<fhirsch3> completed with http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0007.html
<smullan> ACTION-16 still open
<smullan> ACTION-19 still open
<smullan> ACTION-21 part of proposal of ACTION-15
<smullan> ACTION-21 CLOSED
<trackbot> ACTION-21 Propose ways to reduce dependencies on XML specs closed
<fhirsch3> completed with http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0007.html
<smullan> ACTION-22 still open
<smullan> ACTION-23 still open
<smullan> ACTION-24 still open
<trackbot> ACTION-23 -- Frederick Hirsch to contact EXI re signature/verification use cases -- due 2008-08-05 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/23
<trackbot> ACTION-24 -- Scott Cantor to review schema for improvements -- due 2008-08-05 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/24
<smullan> ACTION-27 still open, rob not on call
<smullan> ACTION-28 still open
<smullan> ACTION-29 still open
<smullan> ACTION-30 still open
fjh: one doc or two?
... originally 2, one for c14n, one for sig
bal: start with one document then two if needed
<bal> back in about 60min
fjh: do we have a template for reqmts?
... no real template, but thinks we should use xmlspec
http://www.w3.org/TR/widgets-reqs
fjh: suggest we take existing document as starting point
fjh: could use widgets one or something else
... if you know of a template, let list know
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0005.html
fjh: agreed at f2f we need principles doc
... look at doc above and see if it looks good
fjh: helpful if someone could write more text for each principle
fjh: ask next week for resolution to accept princ.
fjh: Bring forward existing requirements to keep?
... any comments on directions for requirements?
hal: some requirements may end up in conflict based on work we produce
<esimon2> OK to post conflicting requirements, though one should have a note indicating that it is recognized they may conflict.
hal: minimum profile proposal strikes me we need to be clear about assumptions
fjh: goal is to get concrete requirments down, even though may not be firm
fjh: example - is processing instruction ok?
fjh: should we have diff requirements for signature generation and validation?
hal: clearly a possibility for anything we may deprecate
tlr: no process for deprecating algs that aware of
fjh: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0000.html
<fjh> comments from Brad Hill
bhill: reemphasize point that not all signatures will be trusted
pdatta: if you trust signer, not a good assumption to trust transforms?
... cross site scripting?
bhill: not sure if in scope for xml sig ...
"Is http://foo.bar/baz.html signed?" - yes - "GET http://foo.bar/baz.html"
<smullan> are remote refs equally problematic as any detached sigs?
smullan, yes
tlr: is important to call out, item that people can not realize issue
<bhill> issue re: entity expansion in remote DTDs and changes between validation and subsequent retrieval
<bhill> consider for new c14n requirements: SOAP subset only?
<bhill> relevant to algorithms for reference caching: pre vs. post c14n safety
fjh: comment on list on brad's comments will next week be good time to accept changes?
<smullan> .. brad on vacation next week, 2 weeks better
<bhill> brad will be on vacation next week
<smullan> ... who should edit doc?
bhill: happy to edit if has access
fjh: sig was orig ietf and w3c doc, but xml enc was not, trying to release rfc for 2nd ed to be consistent
... some feedback from ietf, still moving forward
tlr: separation of normative and informative refs ...
fjh: using tracker, gerald seeing if makes sense
... issues under current wg now
... issues have 3 states, closed, open, raised
... issues can be raised by anyone, wg agrees they become open but not yet doing that
... suggest we move all raised to open?
<gedgar> I think that is apt
<smullan> RESOLUTION: move all raised issues to open status
fjh: everyone should look at issues and add notes if appropriate
<gedgar> I will add descriptions
<gedgar> and I will aggregate similar issues
<fjh> http://www.w3.org/2008/xmlsec/issues.html
<gedgar> place add this as an action for me.
<esimon2> back in 5
<gedgar> I have to drop off.
<fjh> http://www.w3.org/2007/xmlsec/ws/report.html
fjh: at f2f hal suggested we have categories
<fjh> categories - security, performance, features, operational errors
... go thru papers and summarize them again?
... produce requirements and assumptions, and if so any volunteers?
pdatta: part of the work should go into requirements doc
fjh: work on requirements first, then look at other profiles such as this one
<fjh> review wg requirements draft against workshop papers and other profiles once we have a draft
<fjh> http://www.w3.org/TR/NOTE-xml-canonical-req
<smullan> fjh: should review this and see if there is anything we want to keep
kelvin: not require verifier to use full xml stack initially, reducing attack surface
<smullan> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0007.html
kelvin: move work to signer where possible
kelvin: about doing simple verification first before handing it over to an xml parser
pdatta: order of attributes may be a problem
kelvin: only a problem if doc is reserialized
... make assumption that xml is binary blob?
... goal - separate crypto from xml processing
hal: don't see benefit to signer canonicalizing
kelvin: only benefit is to maintain compat with existing algs
hal: need to be really clear on assumptions
fjh: maybe take a look at exi work, see similarities or compatibiliites
<fjh> EXI public page
<fjh> http://www.w3.org/XML/EXI/
fjh: might be useful to separate issues from solution
scantor: c14n may not be sufficient for the use cases that have emerged
scantor: if specs prohibit PIs, then that may be fatal issue
tlr: compatibility of signature as well as document format assumed, eg document that allows PIs
kelvin: nothing in spec that prohibits PIs
bhill: would be good to not only have more work on signer, but also allow reverse for more capable receiver
<fjh> scribe: Frederick Hirsch
bhill: would like to see symmetric minimal profile, either for signer or receiver
<scribe> ScribeNick: tlr
hal: would like to see specific
proposal
... looked at this quite a lot, seen approaches where
performance burden
... can be put primarily of sender / receiver
<bhill> brad is concerned with existing tech's (e.g. javascript) ability to serialize in canonical form
hal: not aware of any algorithm
where can have simple sender by having complex receiver
... not trying to say it's impossible, but not sure...
tlr: that is scott I believe
scantor: can have multiple receivers need to remember this
scott: also, cases where you
don't worry as much about compatibility, but all sorts of cases
where processing instructions likely to be problem
... in some cases, PIs might make sense, in others, not
hal: long lifetime signatures, performance might not be issue
hal: for long lifetime signatures, performance might not be a large issue
scott: leaning that direction
too
... but: attack surface ...
... document processing on the desktop
fjh: I think we need to talk about this on the requirements level
kelvin: strawman meant to generate discussion
fjh: that works really well
scott: one of the weaknesses of
original spec is that, dealing with stuff at once, a very
general spec was created
... instead of having multiple ones that are segmented by
problem space
fjh: maybe need to look at the segments separately
ScottC: parallel tracks?
fjh: next steps -- what would be most useful right now?
<scantor> yes, that was me
kelvin: postings about
assumptions or requirements would be useful
... could take action item to document requirements and
assumptions I was making ...
<scribe> ACTION: kyiu to document requirements and assumptions in simple signing strawman [recorded in http://www.w3.org/2008/08/12-xmlsec-minutes.html#action02]
fjh: capture two issues ...
<fjh> issue: signing with multiple intended receivers, and/or long lived signatures
<trackbot> Created ISSUE-45 - Signing with multiple intended receivers, and/or long lived signatures ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/45/edit .
<fjh> issue: acceptability of PI for various environments/segments/use cases
<trackbot> Created ISSUE-46 - Acceptability of PI for various environments/segments/use cases ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/46/edit .
fjh: anything else?
... in that case, we're through the agenda ...
... close to top of the hour ...
Next meeting: Next week, 10am Eastern
-- adjourned --