See also: IRC log
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.
http://www.w3.org/2008/09/16-xmlsec-minutes.html
RESOLUTION: 16 September minutes approved
<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
<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
<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
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
<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 ...
<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.
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].
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