<trackbot> Date: 11 August 2009

<fjh> trackbot-ng, start telcon

<trackbot> Meeting: XML Security Working Group Teleconference

<trackbot> Date: 11 August 2009

GAH

<scribe> ScribeNick: tlr

<scribe> Scribe: Thomas

Convene

<fjh> 18 and 25 August meetings are cancelled

<fjh> Next meeting: 1 September 2009 , scribe John Wray

fjh: Next meeting on 1 September, no more meetings in August
... expect John to scribe
... TPAC registration reminder - this would be a good time to register!

<fjh> TPAC Overview: http://www.w3.org/2009/11/TPAC/overview.html

fjh: registration cost will go up

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0002.html

Minutes Approval

http://www.w3.org/2009/07/28-xmlsec-minutes.html

<fjh> 28 July 2009 teleconference

RESOLUTION: 28 July minutes approved

<fjh> 1.1 Publication and Errata update

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0072.html

<fjh> http://www.w3.org/News/2009#item136

<fjh> Exclusive C14N Errata Update

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0001.html

<fjh> Editorial Updates

<fjh> publication status page updated

fjh: updated wiki for publication status
... some edits from tlr

tlr: yeah, minor editorial stuff
... no reason to refrain from editing now

Interop

fjh: magnus, what's up?

magnus: an ancient action from the May f2f
... to create interop tests for the derived key functionality
... have updated wiki page with test cases

<fjh> http://www.w3.org/2008/xmlsec/wiki/Interop#XML_Encryption_1.1_Derived_Keys

magnus: haven't created data yet
... want to give group chance to review test cases
... to see whether they sufficiently cover new functionality
... next step then is to create actual test data

fjh: looking for WG review of test cases?

magnus: yes, fairly short
... two cases for concat kdf

<fjh> Test case 1: EncryptedData with content key derived from shared secret. Key derivation method: ConcatKDF

<fjh> Test case 2: AuthenticatedData with authentication key derived from shared secret. Key derivation method: ConcatKDF

magnus: final case is about optional algorithm
... with key derived from passphrase

<fjh> Test case 3: EncryptedData with content encryption key derived from shared secret password. Key derivation method: PBKDF2

fjh: any discussion on this, or otherwise on interop?

-- silence --

C14N 2.0 Draft

<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/

edsimon: I killed a tree, but haven't digested it all yet
... in signature 2.0 a new canonicalization element is described
... element name is Canonicalization
... right now it uses /2008/xmlsec/experimental name spece
... within c14n element, can specify parameters
... thinking that the <Canonicalization&rt; element should be defined in Canonical XML 2.0 namespece
... not necessarily signature specific

fjh: where in the spec is this?

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-o-Simple

<fjh> see canonicalization element

<fjh> suggests this be defined in c14n2.0 spec and that namespece

<fjh> <Canonicalization xmlns="http://www.w3.org/2008/xmlsec/experimental">

edsimon: talking about Canonicalization, *not* CanonicalizationMethod

<fjh> tlr asks whether conflating algorithm and role

<fjh> tlr notes canonicalization element defines role with respect to transform algorithm, if extension point, then is part of signature framework

<fjh> tlr with algorithm uri in c14n20 spece

tlr: I'd rather we stick to the separation between algorithm and role => don't move Canonicalization element into c14n name spece, but add Algorithm URI instead

cantor: note you might want to plug the algorithm in elsewhere, hence need a URI

edsimon: just a light thought -- I'm particular to defining elements most closely to their source
... don't consider it a critical issue

cantor: The other issue is that we don't have the c14n algorithm pluggable -- there's a fixed model
... two different models going on here
... rationalize
... that's one of my concerns as far as making clear to people is concerned
... compatibility introduces impedance mismatches

edsimon: agree with that
... schema for c14n element is fairly loose
... xsd:any
... perhaps tighten up

<fjh> tlr notes depends on whether we plan to plug in different algorithim

tlr: depends on whether we make that c14n element something you can plug different algs into
... if pluggable, then xsd:any

<fjh> s/tlr notes depends .*//g [??? - Thomas, please fix.]

cantor: nominally heading away from that

<Gerald-e> C14N also affects Issue-60 - requirements for XML Security and EXI usage

<fjh> issue-60?

<trackbot> ISSUE-60 -- Define requirements for XML Security and EXI usage -- OPEN

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

edsimon: have to severely look at the any

cantor: tradeoff --- whether things are attributes or elements
... if elements, then need wildcard

pdatta: from extensibility point of view, have defined c14n only for xml
... but are also allowing other kinds of types
... leave it extensible to permit other kinds of parameters

edsimon: sounds kind of similar to namespece aware c14n

fjh: add note to doc?

<scribe> ACTION: pdatta to summarize design rationale for xsd:any in note in spec [recorded in http://www.w3.org/2009/08/11-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-351 - Summarize design rationale for xsd:any in note in spec [on Pratik Datta - due 2009-08-18].

action-351?

<trackbot> ACTION-351 -- Pratik Datta to summarize design rationale for xsd:any in note in spec -- due 2009-08-18 -- OPEN

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

edsimon: issue -- what happens if you need to canonicalize more than one subtree

<fjh> ed would like to see more examples

edsimon: would like to see more details and examples of what happens
... no mentioning what happens

edsimon: otherwise, lots of good stuff in there, like what pdatta has done.

pdatta: for more than one subtree, had @@ [??? - Pratik] in there
... canonicalizing them separately, placing them after each other

edsimon: see input parameter "list of subtree
... direction is there
... would like to have some examples
... e.g. in test cases
... the functions are great, but people have to see the raw stuff going in and out
... for the range of use cases, in order to get full understanding of what's meant by the spec

pdatta: we had list of examples in c14n 1.0

edsimon: even 1.0 didn't ever pick up on "more than one node in nodeset" problem
... if you weren't part of interop, good luck

pdatta: there were examples with more than one node, right?

edsimon: don't think the specs had examples
... point is, one shouldn't have to go to interop test cases to understand spec

pdatta: not sure what you mean by "more than one node"

<scribe> ACTION: edsimon to propose concrete examples for multiple nodeset cases [recorded in http://www.w3.org/2009/08/11-xmlsec-minutes.html#action02]

<trackbot> Sorry, couldn't find user - edsimon

<scribe> ACTION: ed to propose concrete examples for multiple nodeset cases [recorded in http://www.w3.org/2009/08/11-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-352 - Propose concrete examples for multiple nodeset cases [on Ed Simon - due 2009-08-18].

pdatta: changed some stuff in requirements piece
... performance, streaming, robustness, simplicity

<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#Requirements-Simplicity

pdatta: [reviews text]

<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#Requirements

<fjh> added new material at end of each requirement

<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#Data-Model

pdatta: note from Konrad that we do not support reinclusion

<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#Processing-for-Streaming

pdatta: streaming section is a placeholder
... only explaining what the streaming piece is about

<fjh> added http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#References

<fjh> added http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#Remove-Dot-Segments

<fjh> updated based on fjh comments, updated editors list

pdatta: wondering what streaming parser we should use as reference
... didn't want to take STAX

fjh: so we're looking for a not language specific reference?

pdatta: streaming model -- these are the events, etc
... take whatever is in STAX or .NET @@, and abstract out

<fjh> we could either create a generic spec ourselves or?

tlr: wanted to ask whether it's sane to quickly concoct an abstraction

fjh: how much work?

pdatta: shouldn't be a big task

fjh: just define events?

pdatta: yes

fjh: does this sound reasonable?

cantor: out of scope?
... implementation instructions are a bonus
... not requirement for correct spec

fjh: how much do we need to do in the spec to say "we do streaming properly"?

cantor: if it's so important, we'll have an implementation in interop

pdatta: there are streaming implementations for subsets

cantor: there are things that are much harder to implement than what we're talking about here
... think URL normalization
... not necessarily technically hard, but lots of spec work
... pseudocode is a risk

<esimon2> +1 to scott

bal: share Scott's concern
... look at it in a different way
... concerned about standardizing methods for implementation
... vs interop formats on the wire
... traditionally, don't standardize implementation methods
... even for APIs, don't say "here's how you write your code"
... more specific concern -- S/MIME for streaming
... streaming was goal, influenced lay-out of fields
... but never required implementation to show up and prove it's streaming
... not required to show implementation details in order to interoperate
... if that's the goal, then it's out of scope
... think it's fine to say "streaming is a goal, but"

cantor: +1

bal: +1
... we used pseudocode in XRML(?)
... said "this is one way, it is not THE way"

<esimon2> Ed: Strongly agrees about avoiding implementation info in specs. (Can be in a separate note.)

bal: conforming implementations must match output

cantor: that's what we need to do here
... also a little concerned about way it's structured

fjh: one of goals in charter is to enable streamability
... wondering how we can show that we did a good job on the streaming side ...
... how to show that we fulfill that requirement?
... we can show during interop that this works

tlr: note that we could say "we want several implementations, at least one of this or that nature"
... that doesn't mean we have to have all streaming implementations

bal: what I'm saying is separate from whether or not we're interested in streaming
... but taking streaming requirements into account
... is separate from saying "we won't take this out of CR if don't demonstrate two streaming implementations"
... not sure that kind of requirement is something we'd meet
... fine to poll folks, and say that we've given thought to how streaming implementations might work

<brich> +1 to Brian's comments

bal: but don't think we could require that implementations be written in particular fashion in order to make spec move forward

fjh: how do we show *in* *the* *spec* that we care about streaming?

can we express some characteristics as requirements?

fjh: don't think we have big disagreement

[ fwiw, +1 to not specifying implementation ]

fjh: right now, the spec says relatively little
... would like people to review the spec and input on what people think we can say

pdatta: pseudocode discussion?

fjh: like pseudocode
... what bal said was that pseudocode is more of an example
... </personal opinion>

cantor: there's middle ground
... some specs are completely unintelligible
... ****
... don't think intelligibility comes out of implementation in the spec
... the way it's currently structured, would rather have pseudocode collected in one place

<esimon2> Pseudocode has to be identified as non-normative.

cantor: more generic issue is errors in pseudocode
... hard to get right
... people inevitably freak oiut when they find problem

<fjh> how about errors in text, or ease of understanding, e.g. C14N10

cantor: force reader to look at text in isolation
... pseudocode becomes crutch
... be careful to not get sloppy about the text

fjh: <example from doc>
... some of the stuff that isn't in the text is important to understand

cantor: ... and that needs to be in the text!

fjh: we need a review.

cantor: this argues that current structure is good way to start
... move pseudocode later

tlr: think we need fresh-eyes pseudocode-vs-text review at some point. How do we need when, and who's the victim?

fjh: looking now might not be that wrong

cantor: That's focus of my review.
... hoping to mainly be reviewing pseudocode vs spec

fjh: where the pseudocode needs to go is a common discussion

<esimon2> I don't mind pseudo-code inline as long as it is identified as non-normative.

<brich> perhaps the links to pseudocode could embed "nonnormative" in the actual link text

fjh: pdatta, any other review needed?

pdatta: prefix rewriting is tricky; that could use some review

<esimon2> If pseudo-code is non-normative, then the spec must be 100% understandable as if the pseudo-code was not there.

ed, right

tlr: do the comments on IRC imply an action item on editorial conventions in the doc?

<fjh> we can have a note that pseudocode is non-normative

edsimon: understanding should be that in final spec, pseudocode kept to minimum, perhaps for trickier aspects
... note that at early stage, pseudocode is fine!
... idea is to move away from it

brich: suggest that links to pseudocode have text "non-normative" as part of link
... people get confused easily ...

<fjh> bruce notes that each bit of pseudocode needs to indicate non-normative, since may not look at note upfront

fjh: think we're getting to some reasonable understanding
... cut down pseudocode when the text is right ...

<esimon2> fjh, I can agree with that.

<esimon2> "that" being that we do not have to aim to minimize psuedo-code, we just have to ensure the text is as clear and stand-alone as possible.

Outstanding Issues

fjh: looked where we had notes in the spec saying "we don't really agree"

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-ECKeyValue

fjh: one of them is ECKeyValue
... wondering whether the ECKeyValue piece is something where we keep stuff?
... regardless of where we go with the algorithms?
... what was the disagreement here?

bal: there was an architectural purity issue here -- magnus v bal
... add tags or don't add tags?
... current spec text is Kelvin/Brian version
... more compact, but not as reusable
... would suggest to keep it and not worry if no feed-back

fjh: expect to ask magnus

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-AlgID

fjh: algorithm discussion is the other topic
... hope to have a bit of a better idea in September
... hope to make decision in September

Signature 2.0

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/

edsimon: have gone through it, some red ink
... one major question
... for the reference and new transform model
... in one place URI specified as child of Selection element

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-Selection

edsimon: in other place schema still has URI as attribute on Reference
... think we should specify URI of resource only once
... which one?

pdatta: old schema has URI on Reference
... prefer to have it in Selection

<fjh> may want note in document clarifying backward schema compatibility and new approach

edsimon: want to have it in only one place
... like the work on selection and c14n transform
... but think keeping the old stuff around needs revisiting
... feels too verbose to be nicely implementable
... need to think about examples
... you mention databases -- xquery -- what do we do with c14n?
... opens up large set of questions which I don't think can begin to answer here
... if in selection, have to give up backward compatibility

cantor: that needs to jump over a very high bar
... and fwiw, prefer URI on Reference really without compatibility consideration

edsimon: prefer on Refrence, too
... consider no-transform case

fjh: ...
... there is clearly an issue where the URI needs to go

edsimon: feeling that compatibility sidetracks from understandability here

cantor: note downstream dependency on namespace

fjh: can't take absolute approach

edsimon: back to the earlier point, want the URI in Reference
... will discuss with Pratik

fjh: please send to list

<fjh> tlr says backward compatibility with no transform use cases argues for URI only on reference

<fjh> we need arguments for URI in selection element

tlr: suggest that in this case the URI is by default on Reference, burden of proof is that putting it into selection is beneficial

<fjh> pratik notes interaction of URI with other parameters, hence reason for in selection element

pdatta: uri might not make sense just on its own

cantor: people know that now
... that needs to be explained in the spec
... and btw it's true even in the old spec

(discussion about how to optimize processing model)

tlr: really prefer on reference

cantor: to the "no transform" use case -- need transform to use new c14n

tlr: binary blobs!

<Gerald-e> ... or exi ...

esimon: xml document can be treated as binary blob

cantor: ... as long as detached

[ yes, of course ]

esimon: want to highlight that, even if one keeps syntax the same, if changing semantics, might be required to give new name space
... note transforms in Encryption

cantor: idea was to have same semantics of URI reference
... what's changing are the implicit assumptions about input and output model for transform chain

<scribe> ... new input and output models

UNKNOWN_SPEAKER: but yes, this is precisely where the balancing act occured

pdatta: somebody needs to write an appropriate note in the text

esimon: there are some relevant issues around xquery, databases, ...
... might affect this ...
... whether inclusion xpath applies to elements or attributes?
... what is that xpath allowed to return?

<scribe> ACTION: Ed to draft text explaining meaning of URI attribute on Reference element [recorded in http://www.w3.org/2009/08/11-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-353 - Draft text explaining meaning of URI attribute on Reference element [on Ed Simon - due 2009-08-18].

pdatta: elements or attributes

cantor: Pratik, do you have a schema for the transform? That would help.
... difficult to tell what's multiply occuring or not
... can you write a schema?

edsimon: +1

[ scribe skips relaxNG / xsd quibble ]

<scribe> ACTION: pdatta to circulate draft schema for Transform [recorded in http://www.w3.org/2009/08/11-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-354 - Circulate draft schema for Transform [on Pratik Datta - due 2009-08-18].

edsimon: we also need some more stuff in the text, as the schema won't be useful to understand what's in the xpath

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#spec-xpath-subset

edsimon: perhaps we can use regular expressions to characterize the xpaths that are permissible

tlr: you're saying the subset we're looking at is a regular language?

edsimon: use *something*

[ discussion whether inclusion / exclusion xpath can use can select elements or attributes or both ]

cantor: needs clean-up

pdatta: want to avoid the case of the orphan attribute

edsimon: restrictions are different

<fjh> inclusion and exclusion xpath profiles different so need different sections defining them

edsimon: specify separately

fjh: next step?

pdatta: ed, please send e-mail with your comments

<fjh> ACTION: ed to send list of detailed comments to mail list on signature 2.0 and c14n2.0 [recorded in http://www.w3.org/2009/08/11-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-355 - Send list of detailed comments to mail list on signature 2.0 and c14n2.0 [on Ed Simon - due 2009-08-18].

fjh: other 2.0 topics that would benefit from discussion on call?

ed: enough for me

More Outstanding 1.1 Comments

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0067.html

ed: relates to earlier action item
... unclear whether xpath needs to represent well-formed document
... scott made clear that it doesn't
... in test case there's 3.2.1.4 test case
... input is a document with only well-formed XML
... however, can non-well formed XML instances as output
... 3.2.1.4 illustrates that
... no information what happens if nodeset includes more than one element node
... no information on non-well formed output

<fjh> http://www.w3.org/TR/2008/NOTE-xmldsig2ed-tests-20080610/#XMLLANG

ed: would like clarification
... umh. I'll likely need to write mail

tlr: umh. yes.

cantor: it's not entirely unclear to people implementing the spec
... interop helps here

ed: want to know whether the proposed change is appropriate

<scribe> ACTION: Ed to send revised version of 2009Jul/0067 e-mail [recorded in http://www.w3.org/2009/08/11-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-356 - Send revised version of 2009Jul/0067 e-mail [on Ed Simon - due 2009-08-18].

ed: also, need for examples in some cases

<fjh> do we need proposed errata?

ACTION-356: should result in c14n11 errata

<trackbot> ACTION-356 Send revised version of 2009Jul/0067 e-mail notes added

<fjh> errata document for c14n11 is here - http://www.w3.org/2008/05/xml-c14n11-errata

ed: on xpath filter, issue was that we never discussed what a predicate expression is
... text open to various interpretation ...
... relevant to 2.0 ...
... clarify interpretation ...
... by focusing on "predicate expression"

fjh: hear erratum for c14n 1.1; separate question for work going forward

cantor: there's also proposals for the 1.1 signature spec

<fjh> can we adopt 1, 3 from Ed as errata now?

<fjh> ok, will wait for email from Ed with proposal to adopt as C14N11 errata

Issues Review

issue-32?

<trackbot> ISSUE-32 -- Define metadata that needs to be conveyed with signature, e.g. profile information -- OPEN

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

issue-16?

<trackbot> ISSUE-16 -- Backward reference for streaming - don't know what is referenced, algs -- CLOSED

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

issue-60?

<trackbot> ISSUE-60 -- Define requirements for XML Security and EXI usage -- OPEN

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

issue-47?

<trackbot> ISSUE-47 -- XAdES references latest XML Signature, depends on ds:Object and ds:KeyInfo -- OPEN

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

<fjh> gerald notes these should stay open

edsimon: exi discusson worth taking up again