XML Security Working Group Teleconference
20 Apr 2010

Administrative

<fjh> Additional agenda item - roadmap and planning, charter extension, 1.1 interop, 2.0 implementations

announcements

<fjh> Request for Comments: LCWD of Digital Signatures for Widgets; deadline

<fjh> 6 May 2010

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0034.html

fjh: please review, and please follow Art's instructions. If you want to discuss this, please speak up now

<fjh> Updated web IRC client, http://irc.w3.org/?channels=xmlsec

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Apr/0004.html

minutes approval

<fjh> Approve 13 April minutes

<fjh> http://www.w3.org/2010/04/13-xmlsec-minutes.html

RESOLUTION: April 13 Minutes approved

Planning

fjh: 1.1, 2.0, interop..

tlr: charter expires 31 May
... expect to ask for an extension
... any thoughts on how long are welcome
... also, what's going to happen to 2.0 in terms of implementation, interop
... also, pending pieces on 1.1

tlr: 1.1.. Last Call completed for 1.1, need to dispense with comments
... will need another Last Call for Retrieval method piece
encryption 1.1, looks like ready for Last Call
after Last Call we have CR, need to understand when to exit CR, requires test suite for additional features, and 2 implementations for each mandatory feature
... need rough estimates

fjh: need to note features at risk when entering CR

tlr: deadline for extension request is in may

hal: how about 2.0?

tlr: Thought about 2.0 as more speculative, was hoping to get better information for 1.1

bal: not sure the folks who control resources at MS talk about time lines right now

pdatta: interested in doing interop on EC encryption for 1.1

<fjh> pdatta: 1.1 interested in ecc encryption

pdatta: signature already done

bal: MS only has signature; don't have enc 1.1

tlr: enc 1.1 is 1.0 + EC + EXI + RSA work

<bal> MS shipped most of Signature 1.1 in native Win32 APIs in Windows 7, but no native Win32 API implementation of Encryption 1.1 was shipped in Windows 7

scantor: no particular time frame; stuck with a nasty code base

fjh: will ask on the list who will have implementation when

<fjh> ACTION: fjh to ask on list about interop and implemention plans for 1.1 features, including encryption and also 2.0 [recorded in http://www.w3.org/2010/04/20-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-552 - Ask on list about interop and implemention plans for 1.1 features, including encryption and also 2.0 [on Frederick Hirsch - due 2010-04-27].

scantor: talk to some of the open source implementers

tlr: yes, indeed

<scribe> ACTION: thomas to contact implementers known from hmac affair [recorded in http://www.w3.org/2010/04/20-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-553 - Contact implementers known from hmac affair [on Thomas Roessler - due 2010-04-27].

tlr: also, how about 2.0?

hal: question behind the question is - are we extending based on 1.1 or based on end of the work?

<fjh> we should extend for the end of the work, our goal is to finish 1.1 and 2.0

<fjh> 1.1 is the minimum time

tlr: well, at some point the question will be who else is doing 2.0
... (outlines possible extension request -- 1.1 to REC, 2.0 to CR)

fjh: was being optimistic, hope to have both 1.1 and 2.0 done during extension phase
... would like to see 2.0 conclude

hal: trying to understand possible time lines

tlr: what's your timing expectation?

hal: design final on 2.0 by end of this year shouldn't be a stretch
... main variable should be interop
... if we couldn't get two implementations by end of next year, mothball for a while

fjh: would like to see indication of interest by december

tlr: so, here's what I'm taking out of this discussion:
... 1. 1.1 into CR this fall
... 2. test suite for 1.1 winter
... 3. to rec for 1.1 mid next year
... 4. 2.0 LC late fall
... 5. 2.0 CR end of year
... 6. test suite for 2.0 mid next year
... extension till May

fjh: risks in CR?

tlr: nah

hal: push-back -- want to sell 1.1 to govt based on EC
... two motives to 2.0 -- interoperability, well --; -- and performance improvements
... dsig performance is important
... question I want to throw out is -- would being able to make that case better help?

pdatta: Dividing work in processing model and syntax. Perhaps pull out processing model?

hal: I was talking about testing and measurement work to show benefits
... to show that 2.0 is worth it

<fjh> pratik notes 2.0 processing model can be used for current signatures, then 2.0 syntax approach

csolc: need to do a sales job for 2.0

hal: are there things this WG can do that would help?

csolc: Performance is indirect argument. Mass appeal. Sell the performance.

<esimon2> * back in 10

<fjh> 2.0 CR beginning 2011

<fjh> tlr suggests 1 year extension to charter with possible additional extensions

<fjh> hal suggests group might demonstrate performance benefits

hal: does the design meet the objective people had with 2.0?

fjh: I do think it would make sense to show performance benefits

<fjh> hal suggests noting performance testing as part of extension

RESOLUTION: XML Security WG asks for extension by 12 months

fjh: schedule?

tlr: I thought that was implicit to this resolution

RESOLUTION: WG accepts tlr's 1-6 schedule above

c14n 2.0 review

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0038.html

<fjh> ACTION-539?

<trackbot> ACTION-539 -- Meiko Jensen to review C14N20 draft -- due 2010-03-09 -- PENDINGREVIEW

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

meiko: rather mature already; see some space for additional improvements
... no major concerns ...

action-539 closed

<trackbot> ACTION-539 Review C14N20 draft closed

fjh: any issues with any of the specific comments?

pdatta: streaming (?) -- pretty printing

<fjh> text node streaming

pdatta: remove whitespace in the beginning and ending of text node
... if you have a newline in the middle of a text node, it wouldn't be split off

meiko: when you have some text in between starting tags
... ignorable whitespaces
... are these removed by the trim function?

pdatta: they are removed

meiko: newlines between two non-whitespace characters in a content node would be preserved
... so you may end up with a large document in one line
... not sure whether it's what you want to do
... might lead to lots of slow string processing in obvious implementations

pdatta: people who're interested in performance will likely not just use string functions

scantor: funny feeling about trimming whitespace that's inside element nodes
... but that's a common prettyprinting scenario, too
... not obvious that you'd meet requirement if you didn't do it
... also, isn't there language about xml:space="preserve"
...
... whitespace treatment within elements is where it gets interesting

meiko: three different options? "trim", "trim only if context", "no trim"

scantor: ugh, complexity

pdatta: some pretty-printers touch @@ too

scantor: that's certainly the case when people do things manually
... I want to review xml:space
... think we're pretty free to implement feature in whatever way is appropriate

pdatta: you were suggesting having 2 parameters?

<fjh> trim, trim not in content

hal: the choices were trim everywhere or trim only outside of content

<scantor> (or not at all)

tlr: and scott's point was that he'd rather see one trim parameter, instead of adding two

meiko: what I meant was is it a three-value parameter
... know it's equivalent to xml:space
... fear that if developers use xml:space, they have to use it properly
... would rather just have one switch in c14n interface

tlr: don't think it's clear we'll have the right canonicalization for every single possible change

fjh: XML serialization -- use URI?

tlr: not sure there'll be many more XML serializations, but...

scantor; the other question was prefix rewriting

fjh: any other things that we need to discuss out of this comment?

<fjh> ACTION: pdatta to review c14n comments from meiko, incorporate into doc, flagging with email any concerns for discussion [recorded in http://www.w3.org/2010/04/20-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-554 - Review c14n comments from meiko, incorporate into doc, flagging with email any concerns for discussion [on Pratik Datta - due 2010-04-27].

<fjh> Sorting

sorting

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

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0015.html

<fjh> pdatta argues that c14n should do sorting to simplify signature

pratik: question is whose responsibility sorting is

meiko: perhaps this depends on the next item

<fjh> only applicable if XPath for more than one subtree

meiko: this is only relevant if have xpath expression that's touches more than one subtree

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

meiko: was question whether just pose restriction on use of xpath

<fjh> meiko supports putting sorting into c14n

tlr: c14n is using document order already. What are we arguing about?

pdatta: for 2.0, isn't nodeset, but subtrees

fjh: don't think we really have a question

<fjh> ACTION: pdatta add clarifications re sorting into c14n2 document [recorded in http://www.w3.org/2010/04/20-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-555 - Add clarifications re sorting into c14n2 document [on Pratik Datta - due 2010-04-27].

RESOLUTION: c14n accepts possibly unordered set of subtrees, which is then sorted in document order by c14n

prefix rewriting

<fjh> Prefix re-writing

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0018.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0020.html

fjh: (summarizes discussion)

meiko: If we talk about performance, prefix-free c14n would have impact on performance
... wouldn't have to consider which namesapce declared where in the document
... you loose prefixes, so loose ability to reference qnames

fjh: sense out of group discussion seemed that we need qnames

hal: it's a non-starter
... people often use same symbolic names in different namespaces
... semantics of identifier aren't clear unless you know namespace

<scantor> it doesn't rule out all namespace usage, it doesn't handle qualified attributes or QNames in content like xsi:type

meiko: can offer to list the drawbacks
... can live with it being removed from the spec, if drawbacks are too strong

scantor: could still declare some namespaces
... trade-off is @@

RESOLUTION: prefix-free c14n off the table, due to qname handling

Signature 2.0

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0032.html

ed: comment #7 is interesting
... excluding object tags from the digest calculation
... does 2.0 selection transform allow doing that?
... recollection is not

pdatta: exclude or include Object?

<fjh> ed wants to include the content within Object element without the Object element itself

ed: the object element without the enclosing tag

<scantor> referencing text content of an element, in other words

ed: seems the specification suggests excluding the Object tags (which is reasonable), but doesn't support doing so

pdatta: the part about Object tags is old. Can only include/exclude subtrees

ed: that's where the contradiction is; need to resolve one way or the other

scantor: think we generally have an open issue around this

<fjh> ACTION: pdatta to review text related to Object tag for consistency with 2.0 model [recorded in http://www.w3.org/2010/04/20-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-556 - Review text related to Object tag for consistency with 2.0 model [on Pratik Datta - due 2010-04-27].

ed: we should say: (a) forget about dropping the object tag, or (b) change something in the spec

fjh: why is dropping the object tag an important feature?

ed: binary data?
... seems like people liked it before

scantor: people didn't seem to like what it did to c14n

fjh: we might not need this feature. Sounds like another place for simplification

<scantor> I looked for an open issue on the Object/Manifest material, didn't see one, but it's come up

<scantor> will do

<scantor> I will

<scantor> it's much broader than that

ed: issue should point at question #7 in my e-mail

scantor: there's a bunch of questions use cases around Manifest / Object

issue-162?

<trackbot> ISSUE-162 -- Will reliable determination of Object element type and encoding be possible under 2.0 Transform -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/162

<fjh> need to include object and manifest in new processing apporach

scantor: I think ISSUE-162 is related. Will edit it.

ed: point 7 isn't the whole issue

<fjh> ACTION: scantor to edit ISSUE-162 to reflect need to include object and manifest in 2.0 [recorded in http://www.w3.org/2010/04/20-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-557 - Edit ISSUE-162 to reflect need to include object and manifest in 2.0 [on Scott Cantor - due 2010-04-27].

scantor: if inability to reference text is a problem, that needs to be separate

ed: neutral, but the contradiction needs to be resolved

processing instructions

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0035.html

fjh: we had that early on, decided against it

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0036.html

fjh: this brings us into web services again

pdatta: was thinking about one-pass processing

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0037.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0039.html

pdatta: argument was that one might not have to reprocess it

meiko: have done one-pass verification of XML Signature
... think it works if you have the "proper" application
... have to keep the entire message around, except for gateway-like use cases
... or applications that speak event-based interface
... that is only possible if have information from SignedInfo before processing
... need to know what transform, ... to use
... if we had a sign "at this element use this stuff"
... then could calculate digest in advance

hal: are you talking about application that can operate on data before the signature is verified

meiko: you can do work as long as you don't do the "critical" operations before end document event

hal: transaction roll-back if signature fails?

meiko: correct

hal: trading latency for throughput

meiko: in web services, interested in part of message. Can save that part in first pass, avoid second pass
... I'd just talk about delayed execution of critical parts

hal: I think I'm going off-topic here...

scantor: any approach here (including PI) would require changes to underlying spec
... would probably push back on enveloped signature if I was opening up that kind of proposal

meiko: useful optional mechanism to improve performance

fjh: doubtful about processing instructions; continue discussion on list?

adjourned