<trackbot> Date: 31 March 2009

<fjhirsch> trackbot-ng, start telecon

<trackbot> Meeting: XML Security Working Group Teleconference

<trackbot> Date: 31 March 2009

<tlr_> Hi

<tlr_> On cab to airport now.

<tlr_> Might be late for call.

<fjhirsch> Scribe: Ed Simon

<fjhirsch> ScribeNick: esimon2

Administration

<fjhirsch> Next meeting: 7 April 2009, Hal Lockhart is scheduled to scribe

<fjhirsch> 24 April Kelvin, 28 April John Wray, 5 May Bruce Rich

RESOLUTION: April 14 teleconference is cancelled

<fjhirsch> Please complete F2F Registration (12-13 May) Questionnaire

<fjhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Mar/0017.html

Minutes Approval

<fjhirsch> Minutes from 24 March 2009

Minutes are approved for March 24

<fjhirsch> http://www.w3.org/2009/03/24-xmlsec-minutes.html

RESOLUTION: Minutes are approved for March 24

Editorial Status Update

Editorial updates are done and have been closed

<fjhirsch> ACTION-231?

<trackbot> ACTION-231 -- Brian LaMacchia to update XML Encryption 1.1 for ACTION-227 proposal -- due 2009-03-24 -- PENDINGREVIEW

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

<fjhirsch> ACTION-231 close

<fjhirsch> ACTION-231 closed

<trackbot> ACTION-231 Update XML Encryption 1.1 for ACTION-227 proposal closed

<fjhirsch> ACTION-225?

<trackbot> ACTION-225 -- Kelvin Yiu to propose text for a note potentially to be added to XMLDSIG provide recommendation for the two higher security level curves with reference -- due 2009-03-03 -- CLOSED

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

<fjhirsch> ACTION-240?

<trackbot> ACTION-240 -- Magnus Nyström to add proposed text to 1.1 -- due 2009-03-31 -- CLOSED

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

<fjhirsch> ACTION-242?

<trackbot> ACTION-242 -- Magnus Nyström to add schema comment regarding ECKeyValue -- due 2009-03-31 -- CLOSED

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

<fjhirsch> ACTION-227?

<trackbot> ACTION-227 -- Brian LaMacchia to draft text encryption algorithms regarding ECC algorithms and what curves should be used -- due 2009-03-10 -- CLOSED

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

<fjhirsch> ACTION-243?

<trackbot> ACTION-243 -- Scott Cantor to update 1.1 draft with DEREncodedKeyValue proposal -- due 2009-03-31 -- OPEN

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

<fjhirsch> ACTION-244?

<trackbot> ACTION-244 -- Pratik Datta to update transforms note sec. 4.5 -- due 2009-03-31 -- OPEN

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

<fjhirsch> ACTION-244 closed

<trackbot> ACTION-244 Update transforms note sec. 4.5 closed

Widget Signature

<fjhirsch> New public working draft of Widget Signature, please review (31 March)

Widget signature spec will be published today; please review it.

<fjhirsch> http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/

<fjhirsch> Planned schedule for Widget Signature, publish today, LC end of April, CR in June

Thomas says one concern is that Widget Signature's faster than XML Signature's

We would have to get XML Signature 1.1 within last call faster than is possible. They will go to CR then wait.

<tlr> tlr: wondering about dependencies and timing

<tlr> fjh: they'll wait for us when they're in CR

<tlr> tlr: ah fine

1.1 Interop Suite

<fjhirsch> No new info on interop

Sean will be getting in test cases

1.1 Topics

Anything to talk about?

<fjhirsch> nothing noted

2.0 Topics

Transform Note Design Decisions

<fjhirsch> High level list of decisions

Thomas put out a list of design decisions in the transform note.

<fjhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0050.html

fjh: Let's discuss event stream model, then other issues.

<fjhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0051.html

<fjhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0052.html

<tlr> tlr: happy for pratik to go first

Pratik: High level comments are about why declarative model is needed.
... Main concern is with procedural models is that more steps make it harder to know what is signed.
... Model needs to be easy to understand so it is easy to know what is signed and what is not.
... That is biggest advantage of declarative model.

fjh: +1 to declarative model

<klanz2> you mean what of the referenced data object is actually covered by the signature as opposed to processing the digest-input/pre-canonicalization node-set

fjh: asks are there any issues with declarative model?

<klanz2> .. @pratik

<fjhirsch> concerns with declarative model include extensibility and adoption

<scantor> +1 to the XSLT issue

<fjhirsch> tlr notes that xslt extension point is not good in new model, since it introduces turing complete extension

<klanz2> -1 to the XSLT issue

tlr: doesn't like introduction of XSLT in model

(Ed: I can't understand Thomas)

<tlr> tlr: both models have turing complete languages (due to XSLT)

<klanz2> (klanz2: I can understand him as well, but the use case of deriving viewable data is completely removed)

<tlr> ... so the distinction between the two models doesn't work out very well ..

<klanz2> fjh: why not out of xmlsig processing

<klanz2> klanz2: it's a deployment issue

<tlr> fjh: let's defer this one

Event Streams

<fjhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0053.html

<fjhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0054.html

fjh: Is having an event stream too much of a processing issue?

Pratik: main issue is transforms are based on node set
... want a different type of model for representing doc subset

<fjhirsch> pratik notes event stream is one model, but another model would be ok

Pratik: event stream is easily understood though it is more complicated to program.

<fjhirsch> pratik agrees harder to program but fairly common

Pratik: difficulty is to know info that is outside the document subset
... still need to support those cases; suggest that inside streaming parser , add namespace context

<fjhirsch> what is outside the document subset - namespace declarations, xml base, ?

Pratik: for XML attributes, no solution at present
... event stream model is good but more complicated than what is wanted
... can we think of another model that is easier to understand

<klanz2> how about spec language, what do you think is easier written/understood?

<fjhirsch> pratik notes alternative is contstrained nodeset

<klanz2> node-set vs. streams?

fjh: in reponse to fjh's question, would we not have the same issues in event model?

Pratik: would work like XML nodeset

<klanz2> http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=107

Pratik: every element would have its own namespace node
... whenever namespace is encountered, it is added; when it goes out of scope, it is removed

<fjhirsch> maintaining context avoids performance issue of copy which exists with nodesets

fjh: xml:base

<fjhirsch> pratik notes xml base and xml lang, xml base combination rules

<bal> +1 to thomas's comment

<fjhirsch> thomas asks would all transforms work with events without requiring buffering for an event stream

<bal> +q

<tlr> tlr: do the xpath subset and the xslt transform work with this stream?

Pratik: In transform notes, there is an XPath subset which can be implemented within the XPath stream
... Node would work off this event stream.

<tlr> NO!

Konrad, please type in your comments.

<tlr> konrad: xslt transform in xml dsig is octet stream to octet stream

<tlr> tlr: NO! I want to know whether the new processing model could accommodate xslt without canonicalization and all that, working just on event streams

<klanz2> agree with thomas to get rid of this

Brian: Is raising the same concern as Thomas
... If you want to go to event stream processing, need to review canonicalization, need new c14n algorithm which would be a good idea.

<fjhirsch> bal notes that going to event stream would mean redefining what we mean by canonicalization so it is a better fit

<klanz2> Exclusive discussed this already: http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation

Scott: Our current c14n model doesn't fit this.

fjh: Need to remember other models are possible like the constrained node approach.

Pratik: Want XML streaming so document doesn't have to be in memory

<fjhirsch> pratik notes requirement - not having to have entire document in memory

Pratik: At no point, in other transforms, is the whole document required to be in memory.
... DOM model is easier than stream based; so maybe we can define two implementations -- DOM and stream

<klanz2> well isn't this too low level?

<klanz2> .. for a spec

<fjhirsch> +1 to konrad

Pratik: When defining doc subset, no need to follow programming language model; can use theoretical model.

fjh: can we use a more abstract model?

<tlr> I think we need to have an idea about the model that we want to achieve.

fjh: nothing is said about how states handle their context

<tlr> We don't need to (and should not) force implementations to actually use that model.

fjh: Is event model going to be implemented anyway?

Pratik: For many implementations, like Web services, things are done in a streaming way and DOM not used; hence, the preference for stream support

<klanz2> @pratik: are you worried when specifying at a contrained node-set level that there is a gap of being specific with respect to behaviour?

fjh: There's declarative and event models but no intermediate model
... Restricted nodeset model allows one to do a little more analysis.

<klanz2> @pratik: isn't the main problem that c14n isn't agnosic re. if inheritable attributes are in the input node set

fjh: More thought needed; let's continue this discussion on the list.
... Is it a decision for backward compatibility or something new?
... Is there a place for processing instructions in the new model?

<bal> frederick

<tlr> fjhirsch?

<tlr> Chris was speaking up

<fjhirsch> oops, hold on, will dial in again.

<tlr> let's wait for frederick to come back

<csolc> PI's have a problem where you have to modify the data being signed,

<csolc> and that may not be allowed to modify the content being signed

fjh: suppose we went PIs for hints about processing efficiency

<tlr> csolc, can you check whether we actually say that in the requirements?

chris: may not have control over waht is being signed; cannot modify that with PIs

Ed agrees with Chris

<tlr> 3.2, point 4

<tlr> http://www.w3.org/TR/xmldsig-requirements

<klanz2> going rather further up, than down is maybe a good idea

<fjhirsch> chris notes that signing content that is not local will not allow you to modify it necessarily, not allowing PI to work

<klanz2> .. with respect to the model

<fjhirsch> chris notes should attempt to have a consistent model that works with or without streaming

<klanz2> that would be XMLInfoSet then

<tlr> infoset is the abstract model you use to talk about XML. It is not a format.

<fjhirsch> would prefer unified abstract model

Chris: next version would have a simplified signing mechanism

<fjhirsch> chris notes want higher performance, easier to use

<fjhirsch> scott - consider 2.0 not as a successor but as companion

<fjhirsch> how would this work?

<tlr> +1 to scott

<tlr> ok, so where we're heading is defining a lighterweight subset of 1.1.

<klanz2> I do not disagree, but should not be called XMLDSIG then ....

scott: 2.0 would XML Siganture lite, not replacing 1.1

<klanz2> different NAME

Scott: No need to interoperate betweeen 1.1 and 2.0
... Might have to use a different name.
... As like as possible, but not alike
... Define 2.0 with a specific set of use cases

<klanz2> something new

fjh: Question for Konrad; did not allow XSLT, would that be a problem?

Konrad: the constraint node model would have to increase performance
... Might be a valid way for a 1.2, but if there is something really disruptive, it MUST be a new name.

<fjhirsch> general discussion notes that the WG could agree to a new name for a new declarative work without xslt transform and find that useful

fjh: How will people know which spec to use?

<fjhirsch> konrad notes that xml signature had transforms to deal with html, css etc to generate viewable output

Konrad: In current spec, chain of transforms was for creating output that was viewable.

<csolc> XML Content Signatures 1.0

<fjhirsch> konrad add clarity, it xml processing signature, not supporting document use case

<klanz2> Raw XML Signature

<fjhirsch> pdatta notes 1.1 will exist for a long time

Pratik: If one says 2.0 is successor, 1.1 will be used for a long time.

+q

<fjhirsch> having simpler and narrower specification could be beneficial, issue of positioning

<fjhirsch> infoset like model document for signature, more abstract

tlr: Our charter says we can consider breaking changes.

<fjhirsch> tlr notes separate model might be bad

<fjhirsch> could have new model document with obvious mapping to new streaming and noted relation to 1.1

Ed: I'm not against breaking changes (actually, I'm for them); I just don't think the idea of two independent XML Signature spec streams will fly.

<tlr> right

<csolc> may not be incompatible. XML 1.1 since it is touring complete, in theory we could map all 2.0 syntax to 1.1

<klanz2> profile?

<fjhirsch> by defining a model for the new constrained nodeset and declarative approach we could define a document that is not signature 2.0 per se

<fjhirsch> this model could be clearly mapped to eventing and streaming

<klanz2> "In standardization, a profile consists of an agreed-upon subset and interpretation of a specification." wikipedia ;-)

<fjhirsch> it could also be mapped to 1.1 with caveat that some features in 1.1 are no longer in the model

Konrad: If we want compatibility, profiles will be appropriate.

<fjhirsch> profile presumes that non-breaking changes, no extensions, etc

Konrad: Bottom line if XSLT is removed, then the possiblity of transforming and deriving PDF, HTML, etc from XML is lost and we lose compatibility.

<fjhirsch> pratik notes that if not compatible then need new name, a new 1.0

<tlr> what's the result that we're getting at with this distinction?

Scott: we already have specs not adopting XML Signature

XMPP not comfortable with XML Signature.

Scott: streaming issue is tough; canonicalization cannot be solved with current model

<klanz2> http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation

<klanz2> it's there

fjh: We are not replacing 1.1 but are doing something in addition to 1.1

Ed: agrees with fjh as long as we are not continuing development of 1.1 (and that could be tricky)

Scott: There's negative connotations wth the current brand.

<tlr> fjh: If we do a "companion spec" then we can be more minimalistic

<scantor> I think it's probably not viable to stop maintaining the old spec if we did a subset as a new spec

Konrad: XML Signature was built with the concerns at the time; it's good but not optimized for today's world

<fjhirsch> document model versus networking model

<fjhirsch> minimal xml signature :)

(tlr, please type in your comments)

fjh: We need to work on requirments for this.

<fjhirsch> changing brand might be useful as well, not 2.0 but different name, negative concerns might relate to community and

<tlr> tlr: minimal xml signature makes sense; enabling minimalism by doing core spec that fits together with 1.1 makes sense. If need to change branding, let's change it when we know that. Wondering what additional details we need to move ahead.

<fjhirsch> use purpose

<fjhirsch> pdatta - a companion not a successor, might be less interesting

<pdatta> I need to drop off now

fjh: There are signals that people are choosing something other than XML Signature so we need to take some action.

Pratik: Working on use cases for streaming.

<scantor> I think if we don't simplify/improve dramatically, we should align any improvements to the existing spec, rather than forge something new

<tlr> 1. Focus on minimalism

tlr: focus on minimalism; focus on limited use cases;...inaudible

<tlr> 2. Use Pratik's model as a basis

<klanz2> well, iff the name is changed

<tlr> 3. Stick to format to the extent possible.

<klanz2> or augmented and it's a 1.0

<tlr> +1

<tlr> klanz, I think your concern about the branding is recognized

fjh: if we cut too much, we lose the value

<klanz2> that's not only branding, but also responsibility

fjh: we aim toward the declarative approach, but not the event stream, need an abstract model

<klanz2> you take or don't

<tlr> responsible branding ;-)

Konrad: Must be responsible to customers in branding.

<fjhirsch> Current rough agreement - focus on minimalism and reduced requirements, and focus on meeting performance with usability requirements.

<fjhirsch> Use Pratik's declarative design if possible, and revised model, either event or possibly more abstract

<fjhirsch> Need clarity of purpose and name should reflect that, relationship to continued use of 1.1 where appropriate

Konrad: If it is called 2.0, then document use cases have to stay

<fjhirsch> konrad notes concern that document use case must be supported if 2.0 but not if different than 2.0

Konrad: Required for government use cases

<fjhirsch> issue: clarify role of document use case in renamed 2.0 versus 1.1

<trackbot> Created ISSUE-111 - Clarify role of document use case in renamed 2.0 versus 1.1 ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/111/edit .

Requirements and Issues

<fjhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0016.html

<fjhirsch> issue-31?

<trackbot> ISSUE-31 -- Role for XML processing instruction, if any -- OPEN

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

<fjhirsch> 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

Gerald: Requriements and issues need to be distrininguished

If one can specify the profile, then the signature has to be processed according to the profile.

<fjhirsch> the signature properties document defines a profile element that can be used for this purpose

<fjhirsch> if we use signature property then defines where and how to be place

Ed: Profile should be specified as an attribute on the <Signature> element.

<fjhirsch> signature property specifies profile as a URI

<fjhirsch> http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/

<fjhirsch> konrad notes keyinfo can become a size issue with CRLs

Konrad: base64-encoded certificates can be big, does not agree with specifying it a signature property
... common for standalone signatures

<tlr> perhaps using a reference (which could be either in-document or external) is the right thing?

Sean: Not sure he agrees; CRLs are being specified throguh the extension, not imbedded

<fjhirsch> sean notes maybe not an issue with CRLs in keyinfo these days, due to extension in cert

fjh: use of ocsp instead of crl

<fjhirsch> sean notes these may be streaming concerns

fjh: let's continue to discuss latere

<fjhirsch> issue-31?

<trackbot> ISSUE-31 -- Role for XML processing instruction, if any -- OPEN

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

Gerald will update issues.

<g-edgar> Make that an action for me.

fjh: XML PIs issue; should we close it?
... Can be regarded as work we incorporate when needed.

<scribe> ACTION: geral to update issues [recorded in http://www.w3.org/2009/03/31-xmlsec-minutes.html#action01]

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

<fjhirsch> ISSUE-37?

<trackbot> ISSUE-37 -- Simplified c14n for signing versus more general c14n, e.g. not produce compliant xml document -- OPEN

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

<scribe> ACTION: gerald to update issues [recorded in http://www.w3.org/2009/03/31-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-245 - Update issues [on Gerald Edgar - due 2009-04-07].

<scribe> ACTION: g-edgar to update issues [recorded in http://www.w3.org/2009/03/31-xmlsec-minutes.html#action03]

<trackbot> Sorry, couldn't find user - g-edgar

<scribe> ACTION: gedgar to Update Issues [recorded in http://www.w3.org/2009/03/31-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-246 - Update Issues [on Gerald Edgar - due 2009-04-07].

fjh: close issue-37?

<g-edgar> c14n is not required for input

<fjhirsch> issue-37 closed in pratik's draft, end of processing chain

<trackbot> ISSUE-37 Simplified c14n for signing versus more general c14n, e.g. not produce compliant xml document closed

<fjhirsch> ISSUE-38?

<trackbot> ISSUE-38 -- Profile for signature processing for non-XML or for constrained XML requirements -- OPEN

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

<fjhirsch> close issue-38

<trackbot> ISSUE-38 Profile for signature processing for non-XML or for constrained XML requirements closed

<fjhirsch> issue-45?

<trackbot> ISSUE-45 -- Signing with multiple intended receivers, and/or long lived signatures -- OPEN

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

<klanz2> who owns this?

<klanz2> http://lists.w3.org/Archives/Member/member-xmlsec/2008Aug/att-0006/12-xmlsec-minutes.html__charset_UTF-8

fjh: set of references to sign and need it to be valid for multiple parties (ed, do you mean multiple signers?)

<klanz2> search for 45

<fjhirsch> gerald notes need to accomidate key rollover

<scribe> ACTION: gedgar to Rework ISSUE-45 [recorded in http://www.w3.org/2009/03/31-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-247 - Rework ISSUE-45 [on Gerald Edgar - due 2009-04-07].

<fjhirsch> ISSUE-51?

<trackbot> ISSUE-51 -- Effects of schema normalization on signature verification -- OPEN

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

<fjhirsch> scott notes best practices was done, but should be factored into c14n revision