XML Security Working Group Teleconference
23 Sep 2008

Agenda Review

fjh: Norm Walsh will give intro to xproc

<fjh> 30 September 2008 Teleconference cancelled

<fjh> Next meeting 7 October. Gerald Edgar is scheduled to scribe.

<fjh> 14 October 2008 Teleconference cancelled,

<fjh> 20-21 October 2008 F2F at TPAC.

Approval of minutes

http://www.w3.org/2008/09/16-xmlsec-minutes.html

RESOLUTION: 16 September minutes approved

Liaisons and coordination

<fjh> XForms - 10:30 - noon (tentative) Monday 20 October

fjh: Working on face-to-face schedule; will meet xforms on Monday ...
... trying to find a way to have a break that day ...

<fjh> EXI - 2-3:30 Monday 20 October (note correction, 1 1/2 hours)

fjh: joint session with EXI ...

<fjh> WebApps - 11-12 Tuesday 21 October

tlr: anything in particular we should review for these meetings?

fjh: xforms is mostly going to be a listening thing
... EXI, we had a face-to-face last year's TPAC ...
... will include that in the agenda; linked from administrative page ...

http://www.w3.org/2008/xmlsec/Group/

fjh: webapps, haven't gotten anything yet
... but note that widget requirements are in last call ...
... will see that I can put together something for preparation ...
... re WS-Policy, trying to get them to update references to Signature 2nd ed
... webapps has widget requirements in last call
... explicit request for review

<fjh> WebApps Widgets 1.0 Requirements Last Call

<fjh> http://www.w3.org/TR/2008/WD-widgets-reqs-20080915/

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

Best Practices

<fjh> Resolution to accept Status/Abstract and incorporate into draft

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

PROPOSED: To accept revised status and abstract for best practices

RESOLUTION: To accept revised status and abstract for best practices

<fjh> Proposed revision for section 2.1, Best Practice 2

fjh: Second item from Scott, revision for 2.1

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

fjh: Sean had some input on this ...

scott: some tweaking might be needed

fjh; sean, any concerns?

sean: sent updated e-mail this morning

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

PROPOSED: adopt changes proposed by Sean

<fjh> draft http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/

sean: move BP #2 and following paragraph to a later point, combine with BP #5 (which should be #6...)
... basically, move to discussion of RetrievalMethod ...
... and instead of moving stuff, just drop in a sentence

PROPOSED: To accept Scott's wording with Sean's additions.

RESOLUTION: accept Scott's wording with Sean's additions.

<scribe> ACTION: sean to edit best practices to implement Scott's and his own changes; see http://www.w3.org/2008/09/23-xmlsec-irc#T14-20-33 [recorded in http://www.w3.org/2008/09/23-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-67 - Edit best practices to implement Scott's and his own changes; see http://www.w3.org/2008/09/23-xmlsec-irc#T14-20-33 [on Sean Mullan - due 2008-09-30].

<fjh> Draft review Section 1, section 2.1.4

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

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

bhill: think there's a legitimate concern here ...
... if you consider using signature in office documents and the like ...
... external references can serve to track who reads documents ...
... there is a privacy concern here ...
... propose to keep this, but flash out text ...

fjh: I have some ideas about changes

PROPOSED: to accept changes to 2.1.4 proposed by Sean as added to by Frederick

RESOLUTION: to accept changes to 2.1.4 proposed by Sean as added to by Frederick

fjh: There's also changes to section 1

RESOLUTION: to accept changes to 1 proposed by Sean as added to by Frederick

<scribe> ACTION: sean to implement http://www.w3.org/2008/09/23-xmlsec-irc#T14-25-06, http://www.w3.org/2008/09/23-xmlsec-irc#T14-24-47 [recorded in http://www.w3.org/2008/09/23-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-68 - Implement http://www.w3.org/2008/09/23-xmlsec-irc#T14-25-06, http://www.w3.org/2008/09/23-xmlsec-irc#T14-24-47 [on Sean Mullan - due 2008-09-30].

<fjh> Draft review - section 2.1.2 (Best Practice 5)

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

sean: xpath can have performance issues, need to pay attention, but not every implementation affected

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

tlr: how about taking this to e-mail? (Also, don't really like "advanced")

<hal> I recommend a general disclaimer something like this

hal: I'd like a general sentence saying "These concerns apply to approaches toward implementing the specification; following the best practices is a good idea whether or not implementation is affected by the concern"

hal, please correct if the above note is wrong

<hal> not really what I said

<hal> but I don't object

hal, is that better?

bal: don't talk about specific implementations; some things might be sane in certain closed environments
... ran into that with fetch-over-web type things ...

<fjh> ACTION: Sean to propose text to address concern of non-naive implementations not being vulnerable to attack [recorded in http://www.w3.org/2008/09/23-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-69 - Propose text to address concern of non-naive implementations not being vulnerable to attack [on Sean Mullan - due 2008-09-30].

klanz: there are standard tools to do bad things, you don't have a lot of influence on them
... think code execution in XSLT ..
... XSLT and XPath concern ...

hal: to respond to the prior comment ...
... these still stand as best practices ...
... there might be reasons not to follow them ...
... but whole idea that somebody doesn't know how something works ...
... and something moves into a new environment, and boom ...
... that is one of the worst risks ...
... would like to highlight these as best practices ...
... it's fair to say "if you know what you're doing, you might not want to do this"

bal: Hal, I hear you, I don't think that concern about poorly documented implementations is specific
... have to separate out what best practices are that we've learned ...
... "things you really ought not to do, and we don't see use for them" ...
... and things that ought to be better documented ...
... other concern, to keep scope of BP document to standard itself
... not attacking specific implementations ...
... of course just a BP document ...
... but people might very well run with some of what's in here and not understand trade-off ...
... 1. do not talk about bugs in particular implementations
... 2. be careful on wording
... there is tendency for documents like this to be used as prescriptive bans ...
... say "there might be good reasons for doing the things we discourage, but you really ought to know what you're doing"

<hal> +1

<fjh> bal notes concern that someone might take best practices as profile, disallowing things but should be treated as practice

bal: we might want to make a hard recommendation on xslt
... that's really a change to the specification ...
... not all recommendations have equal weight ...

fjh: bal, can you add something?

bal: I think there ought to be a disclaimer in here, not sure where that went
... let's not do something general right now, can do that later

tlr: add something general to SOTD?

bal: maybe, with caveat that we might want to make stronger statement
... any good boilerplate?

tlr: not sure I know of any; note that we can change later

fjh: If we want to do normative stuff, not in BP

+1

<scribe> ACTION: thomas to propose disclaimer for SOTD [recorded in http://www.w3.org/2008/09/23-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-70 - Propose disclaimer for SOTD [on Thomas Roessler - due 2008-09-30].

<fjh> hal notes that best practices should reflect multiple applications, not just one

hal: no objection against "make sure you know what you're doing", I don't understand problem with saying that more than one implementation has been observed to have the problem...
... don't say "if you think your implementation is fine, don't follow them" ...
... haven't seen the "show me your implementation" effect when mentioning that some implementations have problem

smullan: we've made some progress on this
... early versions of BP document had stronger language on things like RetrievalMethod ...

<fjh> sean notes now say less strong statements, consider this .

smullan: also, most DOS attacks might be less serious when following BP 1 and BP 3

<fjh> sean notes that use of xslt may be appropriate in trusted environment

pdatta: namespace node expansions ...
... @@ expands all namespace nodes ...
... there is some dependence on that feature ...
... interop testcase without expanding namespace nodes?

fjh: sean noted that document shouldn't use relative namespace URIs

<fjh> Change all examples in document to use absolute namespace URIs, not relative

klanz: they're prohibited

<brich> how about some text that says something like "There is an uneasy tension between security on one hand and utility and performance on the other hand. Circumstances may dictate an implementation must do something that is not the most secure. This needs to be a reasoned tradeoff that can be revisited in later versions of the implementation as necessary to address risk."

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

<klanz2> The use of relative URI references, including same-document references, in namespace declarations is deprecated.

<klanz2> Note:

<klanz2> This deprecation of relative URI references was decided on by a W3C XML Plenary Ballot [Relative URI deprecation]. It also declares that "later specifications such as DOM, XPath, etc. will define no interpretation for them".

fjh: sean, you said these should reject relative namespace URIs

<fjh> http://www.w3.org/TR/xml-c14n11/#DataModel

<klanz2> http://www.w3.org/TR/REC-xml-names/#reluri

sean: our implementation rejects all the examples because of relative namespace URIs

fjh: @@

<fjh> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/samples/dos_xpath.xml

<klanz2> ns0 ... relative

fjh: In the DOS example files, we have relative namespace URIs

<klanz2> let's change ns0 to http://www.example.org/ns0 ... to n

<klanz2> let's change ns0 to http://www.example.org/ns0 ... n

tlr: I guess my question is whether there is any good reason for having relative namespaces

fjh: we could use absolute ones as well

<scribe> ACTION: pratik to update examples with absolute namespace URIs and regenerate signatures [recorded in http://www.w3.org/2008/09/23-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-71 - Update examples with absolute namespace URIs and regenerate signatures [on Pratik Datta - due 2008-09-30].

fjh: now, links to example files...
... we're keeping these member-visible for the moment ...

tlr: The examples become vastly easier to understand in full
... could see us waiting a little longer to accommodate implementers.

sean: even if there is an implementation that has a big problem
... doubt anybody will be able to fix this any time soon ...
... think the examples have the relevant text in there ...
... think that's good enough ...

<esimon2> back in 10 min.

fjh: no decision quite yet, decide next meeting

RetrievalMethod attack

<fjh> RetrievalMethod attack, section 2.1.3

fjh: long thread whether it can be recursive ...

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

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

pdatta: fine with Sean's clarification

fjh: what does that mean for document?
... does the attack depend on the KeyInfo concern?

pdatta: no longer a denial of service attack

fjh: sean, can you take care of this example?

<fjh> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/#id64346

klanz2: I thought RetrievalMethod *is* recursive?

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

fjh: deferred

<fjh> Add synopsis for each Best Practice

<klanz2> ame="Type" type="anyURI" use="optional"

<scribe> ACTION: fjh to contribute synopsis for each best practice [recorded in http://www.w3.org/2008/09/23-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-72 - Contribute synopsis for each best practice [on Frederick Hirsch - due 2008-09-30].

<fjh> Misc editorial

<fjh> Completion of implementer review actions?

<fjh> http://www.w3.org/2008/xmlsec/track/products/11

implementation review?

fjh: Has anybody has a chance to look through the document -- how's review doing?
... Also, is publication at face-to-face a realistic option?

<gedgar> I have to leave unfortunately.

smullan: found that relative namespace URIs are a problem
... should make sure that examples are kind of accurate ...

fjh: the bar I'm trying to get across is whether publication would cause any harm

bal: as long as we talk about the spec itself, it's fine

fjh: the document doesn't disclose things about a specific implementation

brich: review of document was what I committed
... timing isn't easy ...

fjh: trying to understand issue
... want to make sure that BPs are followed? statements about specific implementations?
... oh well, so maybe we can't publish as quickly
... let's at least get pending edits out of the way

Use Cases & Requirements

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

fjh: hal, you had useful material about web services
... how to add that?

hal: also, what happens to long-lived documents considerations?
... probably the same thing should happen to that and to my material

magnus: also talked about extending scope to not just be about signature and c14n, but also a few other things
... keyInfo e.g. is generic

<fjh> proposal - change title to XML Security v.next use cases and requirements

tlr: Serious editing hasn't begun yet; some things in Shivaram's court

fjh: need to pull things from the list

<scribe> ACTION: magnus to provide proposal to adapt Requirements scope [recorded in http://www.w3.org/2008/09/23-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-73 - Provide proposal to adapt Requirements scope [on Magnus Nyström - due 2008-09-30].

hal: maybe do "domain specific requirements"?

fjh: issues list, try to go through and extract requirements

<fjh> issues list requirements extraction

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

fjh: gerald categorized requirements here
... volunteers, please!

<esimon2> I'm here!

<esimon2> unmute me

nope

ed, you shouldn't be muted

yes!

esimon2: IRC exceptionally slow again
... EXI review is relevant here.

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

EdSimon: They aren't addressing EXI needs for signature and encryption
... but based on use cases, there might be native need for signature and encryption ...
... please poke them about answering http://lists.w3.org/Archives/Member/member-xmlsec/2008Sep/0022.html ...
... there is a long conversation to be had about native XML Security for EXI ...

Schedule review

<fjh> http://www.w3.org/2008/02/xmlsec-charter.html#milestones

fjh: would like to get use cases and requirements out in early November
... doesn't give us a whole lot of time to produce something to get us started ...
... focus on requirements soon

<esimon2> Specifically what I said was that I have yet to see any discussion on EXI requirements for EXI-native signature and encryption. EXI has published a document discussing how current XML Signature and XML Encryption can be used with EXI but that, to me, does not seem sufficient. Need to find out if the EXI group sees a potential requirement for EXI-native signatures and encryption.

RetrievalMethod, second take

klanz: recursive retrieval method or not?

<klanz2> http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo

<klanz2> http://www.w3.org/TR/xmldsig-core/#sec-RetrievalMethod

<klanz2> <attribute name="Type" type="anyURI" use="optional"/>

tlr: eek, I'm confused. Please send to mailing list

<scribe> ACTION: klanz2 to summarize recursive retrievalmethod point [recorded in http://www.w3.org/2008/09/23-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-74 - Summarize recursive retrievalmethod point [on Konrad Lanz - due 2008-09-30].

action items

fjh: propose bulk closure

ACTION-27 closed

<trackbot> ACTION-27 contact crypto hardware and suiteB experts in NSA regarding XML Security WG and possible involvement closed

ACTION-31?

<trackbot> ACTION-31 -- Thomas Roessler to investigate ebXML liaison (see ACTION-6) -- due 2008-08-19 -- PENDINGREVIEW

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

ACTION-31 closed

<trackbot> ACTION-31 Investigate ebXML liaison (see ACTION-6) closed

ACTION-39?

<trackbot> ACTION-39 -- Hal Lockhart to contribute web service related scenario -- due 2008-08-25 -- PENDINGREVIEW

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

ACTION-39 closed

<trackbot> ACTION-39 Contribute web service related scenario closed

ACTION-42 closed

<trackbot> ACTION-42 Elaborate on "any document" requirement vs canonicalizing xml:base closed

ACTION-47 closed

<trackbot> ACTION-47 Add error noted in http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.html to c14n 1.1 errata page closed

ACTION-66 pending

ACTION-66?

<trackbot> ACTION-66 -- Frederick Hirsch to follow up with xsl to get documents related to serialization -- due 2008-09-23 -- PENDINGREVIEW

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

fjh: we have a long list of open actions
... please get the ones done that relate to requirements ...

<fjh> http://www.w3.org/2008/xmlsec/actions-open.html

<bal> yes

ACTION-56?

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

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

fjh: any other updates?
... concrete proposals and material on the list, please ...
... priority for requirements document ...

tlr: might also be worth talking about the way the process works

<esimon2> IRC died on me; was the EXI action (was it Action-25?) closed?

ACTION-25 closed

<trackbot> ACTION-25 Give feedback on xml schema best practice in xml-cg closed

action-25?

<trackbot> ACTION-25 -- Frederick Hirsch to give feedback on xml schema best practice in xml-cg -- due 2008-08-19 -- CLOSED

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

action-19?

<trackbot> ACTION-19 -- Gerald Edgar to evaluate Issues and Actions for appropriate placement -- due 2008-08-19 -- PENDINGREVIEW

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

action-22 closed

<trackbot> ACTION-22 Review EXI docs that were published closed

action-56?

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

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

action-56 closed

<trackbot> ACTION-56 Propose text for KeyInfo processing in best practices. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0014.html closed