XML Security Working Group Teleconference
21 Oct 2008


See also: IRC log


Konrad_Lanz, Hal_Lockhart, Ed_Simon, Thomas Roessler, Brian LaMacchia, Gerald Edgar, Chris Solc, Pratik Datta, Rob Miller, Norm Walsh, Ed Simon
John_Wray, Juan_Carlos_Cruellas
Frederick Hirsch
Bruce_Rich, Kelvin_Yiu


<brich> ScribeNick: brich

Agenda discussion

Possibly go through Pratik's proposal for XPath subsetting

Proposal was from Sept 1

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

<fhirsch3> exi - serialize documents or fragments, multiroot docs

Schema validation, namespace undeclaration, etc

Also need to discuss c14n...whitespace handling, intermediate indention, b64-encoded certs, detection and removal of "insignificant information"

Might help to consolidate what we consider to be insignificant information, those things that applications should NOT depend on being retained

c14n being a terminal transform, rather than having to go back and forth between nodesets and octet streams, seems like a crucial simplification

konrad...is there a heuristic for determining qnames in context vs other uses?

<klanz2> can we ask users that what looks like a QName, but isn't one it will have to be escaped

Discussion around c14n output being able to be used as a standard form to be passed around...eliminating this allows more things to be considered "insignificant information" and can be left out

<klanz2> What is the complement of the InfoSet, what can be thrown away ...

XProc and XML discussion with Norm Walsh

Subtopic: C14N requirements

What pieces are not to be considered significant, that applications cannot depend on being retained?

Norm...what's significant is what in its infoset

Norm...element content whitespace is insignificant

Norm...almost everything else is significant

Norm...schema does not really address this well, only in DTD

Norm...w/o schema or DTD, all whitespace should be assumed to be significant

norm...cdata sections do not turn up in the infoset

<klanz2> That is what I tried in Transformation Primitives

we have more protection with digital signature than paper signature today, as we have content protection...seems like whitespace preservation is beyond what is required

konrad...if want whitespace preservation, could allow option

<fhirsch> if we wish to simplify then we need to simplify

csolc...how does application know whether whitespace is significant, to be able to request it or not?

<fhirsch> both tlr and csolc asked how does app know whether space is significant to set option

<fhirsch> prefer to avoid options and complexity

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html:

<klanz2> if one would apply those to the referenced document itself (by actually changing it) then the processing of the transforms, despite some serialization, could be omitted on verification as those transforms are idempotent.

<klanz2> In case it fails, the transformations may be executed again assuming an allowed change has happened. If it fails again it fails overall.

<klanz2> We should hence further revise the paradigm of not changing the dereferenced/parsed document.

<Norm> Consider the following example...


<Norm> Critically, in the original document, there's a newline between the two spans

frederick...need to drive to simplification

bal...whitespace insignificance is only possible via DTD, and that is legacy...no longer to be used

bal..."sign what is seen" is at end of dsig doc, was not primary focus, should not overemphasize

<klanz2> But it should be chewed away before the document is signed ,,,

<klanz2> So there is obviously enough potential to discuss if Information in XML is secure ....

Subtopic: Pratik's presentation


<klanz2> @bal: Point 1) in Pratik's presentation is to some extend equivalent to sections 8.1.1 to 8.1.3

pdatta...Building dsig on XPath 1.0 data model leads to lots of work to deal with namespace inheritance when nodes are omitted

norm...xpath2 may help, not required to support namespace nodes and a namespace axis

<klanz2> http://www.w3.org/TR/xpath20/:

<klanz2> In [XPath 1.0], the in-scope namespaces of an element node are represented by a collection of namespace nodes arranged on a namespace axis. In XPath Version 2.0, the namespace axis is deprecated and need not be supported by a host language. A host language that does not support the namespace axis need not represent namespace bindings in the form of nodes.

pdatta...subtrees most important to support, and perhaps included/excluded subtrees

pdatta...Enveloped signatures require the exclusion of the signature subtree itself

norm...will help find "Schema Key Constraints"

tlr...put this in "Proposed Breaking Changes" in requirements doc

pdatta...going to Streaming signatures...

norm...streaming XSLT...need email reminder

<tlr> Summary: namespace prefix undeclarations will continue to haunt us forever.

norm...namespace prefix undeclaration is NOT in xml 1.0 but is in 1.1...this will NOT change

<Norm> Konrad observes that the XPath 1.0 data model can't be serialized as XML 1.0.

tlr...would like to change gears...XSLT serialization...what is the domain? what nodesets does it operate on?

norm...will serialize any XDM subtree...doesn't throw anything away(?), may add things (indentation)

tlr...why not c14n?

norm...not on radar

<fhirsch3> xproc may use c14n as serialization for serialization method

norm...XProc pipeline would output nodeset...would not make sense to have c14n...as that would output octet stream

<klanz2> All this XML == XML' ? Is allover the place in XML and causes so many headaches ... http://www.w3.org/TR/xslt#strip

<klanz2> and many more places and so on ...

frederick...these two requirements are linked...looks like must do both

<fhirsch3> removing the requirement to allow transforms to move from octet stream to nodeset and back as well as enabling c14n only has pre-hash signing step could greatly improve performance, simplification

<fhirsch3> can not do both!

<tlr> Konrad is unfortunately right about XSLT

<tlr> http://www.w3.org/TR/xmldsig-core/#sec-XSLT

<tlr> ISSUE: Revise XSLT transform; it's currently octet-stream to node-set.

<trackbot> Created ISSUE-67 - Revise XSLT transform; it's currently octet-stream to node-set. ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/67/edit .

frederick...not arguing against "sign-what-you-see" but did we make this more complicated than what was needed?

bal...whole reason for xform chains was for document subsets

<klanz2> Document subsets is XPointer

frederick...do we really need the transform chain mechanism?

<klanz2> Imagine Database A and Database B ....

bal...do you need to have subselection of URI-addressable parts?

<klanz2> and you send a detached signature from A to B ...

<klanz2> and the transforms dereference data from those data bases and the signature shall verify without actually transferring the data#

<klanz2> so would could make this a NON use case

<klanz2> but currently these things are used ...

tlr...XSLT transform requirement will constrain us...unless dealt with somehow

Subtopic: XProc futures

norm...going to CR the end of this week

norm...may get uptake early next year

norm...if case that dsig is atomic operation with few options, could argue that is part of XProc

norm...seems more complicated, would be compound steps, more than can be added to XProc

rdmiller...some work has already gone into this dsig+Xproc step/steps, will share later

<klanz2> is an XProc chain delivering the same output if executed on different processors ...

<klanz2> I mean if you stuck it into a digest will it deliver the same digest

<klanz2> maybe that is an interesting idea and then all other specs would have to assure that their output is canonical to some extend ..

konrad...if security is of concern to authors of XML apps, should have canonical form

tlr...most specs tell how to parse, not how to serialize, canonicalize

<klanz2> Security is inconvenient and costly, but is necessary to assure long term survival of any technology ...

frederick...what is going on with encryption?

norm...deferred until later, just as signature

<thomas> frederick?

<thomas> let's meet in the Webapps room

<thomas> they have more room

<ArtB> Frederick - Thomas says you folks should join us @ 11:00 in Isle A

<ArtB> OK?

<ArtB> Isle A is behind the registration desk on floor 0

<ArtB> Please ACK

<scribe> ScribeNick: brich

WebApps meeting


WebApps: SHA-256 issues?

<fhirsch3> bal: deprecate sha-1 for signing, continue verification, support SHA-256

WebApps: how to deal with knowing which alg to use?
... Signature alg?

<fhirsch3> see wam minutes here

<fhirsch3> bal: 1024 key length good for a year...

<fhirsch3> kelvin, if cert is long lived for code signing, e.g 3 year verisign cert, could drive desire to use long lived signing key at 1024...

<fhirsch3> wam minutes - http://www.w3.org/2008/10/21-wam-minutes.html

bal...said XAdES would have helpful info, some might be picked up in Signature futures

<bal> he asked about timestamps and I pointed to xades

link to XAdES already in WAM channel

<klanz2> re timestamps also poit to best practices for ephemeral signatures and timestamps, i.e. the contribution from Hal about webservices and timestamps

<tlr> We expect to do the algorithm changes, minor clean-ups, low-hanging simplifications in XML Signature 1.1. No change of namespace. No clear time plan quite yet.

<fhirsch3> tlr: identify spec in signature as signature property, so to identify profile

<klanz2> yes

<klanz2> I can however hardly hear anything

<klanz2> do we have a requirement to clarify dereferencing from within a ZIP file, it seems ODF and Widgets need this?

<klanz2> things that may play a role here are: http://tools.ietf.org/html/rfc3986#section-5.1.2

<klanz2> Java has something in the format jar:<url>!/[<entry>]

<klanz2> http://java.sun.com/j2se/1.5.0/docs/api/java/net/JarURLConnection.html

<esimon2> Hi Konrad, where is everyone?

<kyiu> ScribeNick: kyiu

NVDL Introduction

<klanz2> do we have a link to NVDL

RobMiller: how to move XML in an assured way - has paper that shows how to constrain schema

<klanz2> what slide are we on

I think 2

<klanz2> What is NVDL

NVDL=Namespaces-based Validation Dispatching Language

<klanz2> I know, but is that the heading of the slide you have been seeing

<klanz2> yes

fhirsch3: how do you identify a component? how do you express constraints?
... can possibly put NVDL on our best practices list

<klanz2> Very Good Point

<klanz2> rob: NVDL can be used to mitigate many things on a schema validation level already

<fhirsch3> slides for NVDL http://www.w3.org/2008/xmlsec/f2f-2008-10-20/NVDL-plus-XML-Signature.ppt

<klanz2> there is a potential to tackle certain things in our best practices using NVDL ...

<fhirsch3> NVDL pdf http://www.w3.org/2008/xmlsec/f2f-2008-10-20/NVDL-plus-XML-Signature.pdf

<klanz2> e.g.: Limit http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/#id114072 -> give an NVDL example of how to prevent this ...

Transform Requirements

<klanz2> http://tools.ietf.org/html/rfc3986#section-konrad, 5.1.2

WebApps followup

klanz2: add test cases for zip based packaging formats?

tlr: xmldsig already allows relative paths in uris. not xmldsig's responsibility

<fhirsch3> group noted that other groups may have to test Reference uri retrieval, really out of scope for signature

Transform Requirements

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/att-0036/00-part

pdatta: very difficult to find out what is signed. Model is run transform, get digest
... seems verifying processor doesn't know what is going on. in practice, we restricts what transform sequences are allowed
... should step back and try to do things in a different way
... how to identify what is signed - not responsibility of a transformation

csolc: may want to canonicalize binary formats

<fhirsch3> separate what is signed, selection, and digesting/canonicalization

csolc: 2 steps: selection and canonicalization

pdatta: klanz2 brought up using xslt to remove whitespaces, but it should be done within canonicalization

klanz2: new use case for transforms: generate xhtml on the fly and signed

fhirsch3: seems like you can simplify signature greatly if data is first retrieved from database, run through xslt, then signed, instead of running the xslt as part of xmldsig

bal: you would have to generate a uri for the results from the database query

<klanz2> 8.1 Transforms

<klanz2> A requirement of this specification is to permit signatures to "apply to a part or totality of a XML document." (See [XML-Signature-RD, section 3.1.3].) The Transforms mechanism meets this requirement by permitting one to sign data derived from processing the content of the identified resource. For instance, applications that wish to sign a form, but permit users to enter limited field data without invalidating a previous signature on the form might use [XPath] to exclude those portions the user needs to change. Transforms may be arbitrarily specified and may include encoding transforms, canonicalization instructions or even XSLT transformations. Three cautions are raised with respect to this feature in the following sections.

<klanz2> Note, core validation behavior does not confirm that the signed data was obtained by applying each step of the indicated transforms. (Though it does check that the digest of the resulting content matches that specified in the signature.) For example, some applications may be satisfied with verifying an XML signature over a cached copy of already transformed data. Other applications might require

csolc: seems transforms for document manipulation should not be part of dsig

<klanz2> that content be freshly dereferenced and transformed.

<klanz2> *to sign data derived from processing the content of the identified resource*

bal: thinks we had requirement from we wanted to sign parts of a document. xpath was a means of selection, xslt is selecting and transforming

fhirsch3: what would we lose if we keep only selection, but not transform?

tlr: 2 possible assertions: if we take msg, apply transform, then you are assured the information is result. you don't get the assurance if you don't apply it.

fhirsch3: push back on putting all information about a workflow into xmldsig

bal: looking back on v1 requirements, we may have just over defined transforms when reqs were mostly inclusions and exclusions

<klanz2> XPointer is still a WD ...

tlr was arguing to keep selection

<bal> (discussion of what auditors do when they audit)

where info is stored (inside or outside of the signature) should not affect the auditor

<klanz2> What about this: http://www.w3.org/TR/xmldsig-core/#sec-Base-64

<klanz2> That is a clear indication that what is to be secured is the derived and not the data as such

<klanz2> but the empty transform chain degenerates to the situation where there is identity between what is dereferenced data and digested data

fhirsch3: it may be difficult for an app to define a transform if the API doesn't support it or complex

<klanz2> similar thoughts could be applied if only transfrom primitives were used ...

fhirsch3: xproc is about defining processing chain and would like to see a simple processing step for signing
... trying to get things simpler, not sure if we can meet our security and perf objectives without simplification

bal: then you can make canonicalization the last transform before digest

klanz2: doesn't think supporting transformation is contrary to our goals

fhirsch3: we don't eliminate the transform step, but questioning whether it belongs within xmldsig.

klanz2: removing transformation may not be supported by the community

fhirsch3: convinced that we should be on a path to do a version 1.1. Would be nice to get feedback before going to last call
... pretend we have a small part of 2.0 ready way ahead and ask for feedback

tlr: would be very valuable if we reach out to etsi, ietf and oasis. proposal would have to be public and not member only
... brief design note may be the right way to get feedback

<klanz2> For 1.1 we could start with things like http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html Transfromation primitives ...

pdatta: could present in 2 ways: new syntax or retain old syntax but restrict

<klanz2> Some quickly drafted examples for such transformation primitives could be:

<klanz2> a) some sort of minimal canonicalization as defined in RFC 4051 [2] ...

<klanz2> b) normalization of namespace prefixes, ...

<klanz2> c) normalization of multiple successive whitespace characters ...

<klanz2> d)sorting of attributes ...

<klanz2> e) a non-XPath-Filter based version of the enveloped signature

<klanz2> transform ...

<klanz2> f) and the like ....

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/att-0036/00-part

pdatta: don't want DOM because of amount of memory used, pass around a stream of nodes instead

<fhirsch3> pratik , 2-3 passes max...

brich: 1 pass is ideal

pdatta: verification is difficult for 1 pass.

bal: key is knowing what to hash

pdatta: wss use case often has signature detached
... wss has signature before rest of body. possible 1 pass when verifying, but not possible to have 1 pass for signing

hlockhart: when sending, you know content is ok, verify cannot assume that

fhirsch3: have question about streaming - should we have another level?
... trying to figure out how to act on it
... should streaming be a core requirement, or optional

bal: streaming is often the reason people choose CMS instead of XMLDSIG

pdatta: even if you go with 2 passes, what are the problems wiht the current model?
... nodeset itself requires a DOM, everything is loaded at the same time
... xpath expressions can go anywhere in the document
... could limit to only the xpath axis that allows streaming
... filtering namespace nodes - there is a very complicated test vector and wondering if we can do without it

<klanz2> Some bits of the streaming discussions in the maintenance WG back then:

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008May/0026.html

<klanz2> http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2008Jun/0002.html

fhirsch3: may want to run regression test cases against proposal and see how many are broken

pdatta: perhaps we can have more than 1 digest for each reference?

klanz2: 2 digest processing should not be too expensive

pdatta: because signature breaks too often, if we have multiple types of canonicalization, then it may be easier to make a determination

fhirsch3: could also have an attack where it changed one canonicalization but not all

klanz2: it could help analyze broken signatures
... main problem is there are tools that break assumption that XML should not be touched after signing

<fhirsch3> konrad notes possible requirement is that the xml environment allows flexibility or even apps to break rules, signatures still need to verify

fhirsch3: ACTION to pdatta to put proposal into requirements doc
... does the WG agree to explore simplifying transform chain processing

bal: let's make sure we agree on the roadmap
... do a version 1.1, plus and early note about transform processing in 2.0

<klanz2> I'd like to have this added as a requirement: the xml environment allows flexibility or even apps to break rules, signatures still need to verify

tlr: sketch out the breaking change briefly and get feedback as early as possible

fhirsch3: want input from entire WG

<klanz2> is sean mullan here?

bal: from the charter, WG will communicate breaking changes early and broadly

resolution: accept pdatta stuff into requirement doc

ACTION to klanz2 to write his database use case to add to requriements doc

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

fhirsch3: can we communicate that streaming is now a core requirement?

RESOLUTION we'll add a requirement that there should be a clearly defined subset of XMLDSIG that is streamable

fhirsch3: do v1.1 early to include algorithm updates

sha2 and ecc

clarify processing around handling of absent uri

no new namespace, no breaking changes, no need to invoke version policy

include careful update of versioning policy

<klanz2> I'd like to discuss to add a set of very simple transfroms ..

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html

also other simple obvious clarifications

roadmap item2: note to describe simplifcation of transform

roadmap item3: uri index note

<fhirsch3> note that smmarizes uris defined in various places, encryption, sig, rfcs etc

<fhirsch3> item2 is selection and c14n+digest only transforms

<fhirsch3> item1 is for signature

item 4 update xmlenc with new ecc algs

<fhirsch3> item4 probably also careful clarification of versioning

item 1: should point to NIST doc for key sizes

sentiment in the room is to accept the roadmap with info we have now

<tlr> RESOLUTION: roadmap accepted, subject to possible agreement by those not attending face-to-face

<tlr> http://lists.w3.org/Archives/Member/member-xmlsec/2008Oct/0014.html

<klanz2> Where are we on the AGENDA? http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0037.html

<klanz2> you are losing me entirely

<klanz2> are we talking on 2.0 1.1 ???

<tlr> 2.0

<fhirsch3> The WG is considering restricting the transform model in XML Signature 2.0 to limit the transforms to selection of material for signing and also to enable digesting and canicalization

<fhirsch3> The current ability to support complicated arbitrary transform streams might be better handled at the applciation,perhaps using xproc steps.

<klanz2> Well I object this because it is optional anyway ...

<fhirsch3> For example, XSLT would no longer be supported as a signature transform but could still be used before signing is initiated.

<klanz2> Well I object this because it is optional anyway ...

<bal> my proposed wording

<bal> The Working Group is considering modifying the Reference Processing Model in XMlDSIG 2.0 to consider only "selection", "canonicalization" and "digesting" transformations. The Working Group believes that there are significant security advantages to making this change to the XMLDSIG structure, but it does constitute a restriction on behavior that is currently permitted by XMLDSIG 1.0. Specifically, this change would still permit signing of document subsets but wou

<bal> ld prohibit transformations of arbitrary complexity (e.g. XSLT) from being used within the XMLDSIG sturcture itself.

<klanz2> http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/Index.en.html

<klanz2> http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/viewerformat/ViewerFormat.en.html

<bal> The Working Group is considering modifying the Reference Processing Model in XMlDSIG 2.0 to consider only "selection", "canonicalization" and "digesting" transformations. The Working Group believes that there are significant security and performance advantages to making this change to the XMLDSIG structure, but it does constitute a restriction on behavior that is currently permitted by XMLDSIG 1.0. Specifically, this change would still permit signing of document

<bal> subsets but would prohibit transformations of arbitrary complexity (e.g. unconstrained XSLT) from being used within the XMLDSIG sturcture itself.

<tlr> http://lists.w3.org/Archives/Member/member-xmlsec/2008Oct/0015.html

<klanz2> http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/minimum/Minimum.en.html

<klanz2> Minimum Implementation of the Security Layer

<klanz2> http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/minimum/Minimum.en.html#profilXMLSig.erstellung.transformationsalgorithmen

<tlr> http://lists.w3.org/Archives/Member/member-xmlsec/2008Oct/0015.html

<esimon2> 1+ for message in chat

<fhirsch3> add requirement to requireents doc for migration and legacy support

<esimon2> Just fyi, I'm sporadically unavailable for the next half hour.

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

TOPIC Web Services Requirements

hal: we know there are naive implementations that verify signatures without ensuring if the right keys are used, or if the signature met cryptographic requirements of the organization

fhirsch3: running out of time quickly, want to decide if we want a call next week

<fhirsch3> ws security msg is about environment, not specific to xml signature requirements

<fhirsch3> question of whether wss is constraint or whether it might change based on work in xml security

WG will review Hal's proposal and provide further comments over email

<esimon2> gotta go for a bit

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html

TOPIC Transform Primitives

<klanz2> a)some sort of minimal canonicalization as defined in RFC 4051 [2] ...

<klanz2> b)normalization of namespace prefixes, implying that they are not of

<klanz2> significance to the data object. It does not contain QNames in

<klanz2> content referred to by this ds:Reference.

<klanz2> Hence this ds:Transform specifies a numbering scheme for namespace

<klanz2> prefixes with some NCName [3] parameter P so that prefixes are

<klanz2> replaced by concat(P,'1') ... concat(P,'n') ... and so on .

<klanz2> The transformation MUST by default throw an error on the discovery

<klanz2> of the string concat(P,x,':') in attribute values or out side tags,

<klanz2> where x is a decimal integer ....

<klanz2> c)normalization of multiple successive whitespace characters,

<klanz2> implying that they are not of significance to the referenced data

<klanz2> object and are replaced by a single white space character, ...

<klanz2> 1) appreciating the usually line based processing of text formats

<klanz2> either line breaks are added/normalized after each start and end TAG

<klanz2> 2) alternatively the indention algorithm XYZ is applied

<klanz2> ... multiple/contradicting usage of c) is prohibited ...

<klanz2> d)sorting of attributes

<klanz2> e)a non-XPath-Filter based version of the enveloped signature

<klanz2> transform

<klanz2> f) and the like ....

klan2 need a set of commonly needed transfroms that are streamable

can inspect to ensure only the right set of transforms are used

klanz2: could help hardware based implementations. Would like to get people's opinions on whether it is useful

fhirsch3: should defer to later

proposal is essentially parameters on canonicalization

<klanz2> but you then inherit the problems from c14n

ACTION fhirsch3 write a draft for the note

<trackbot> Created ACTION-93 - Write a draft for the note [on Frederick Hirsch - due 2008-10-28].

<tlr> ACTION-93: "the note" is the note to explain the transform proposal

<trackbot> ACTION-93 Write a draft for the note notes added

,TOPIC Action Item Review

action item review

<tlr> ACTION-38 closed

<trackbot> ACTION-38 Enlist kelvin to write up scenarios he's interested in; split of classes closed

<tlr> ACTION-52?

<trackbot> ACTION-52 -- Konrad Lanz to attempt summarizing recent discussions as input for design document -- due 2008-09-02 -- OPEN

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

<trackbot> ACTION-54 Provide a presentation to the working group introducing NVDL. closed

<tlr> action-57 closed

<trackbot> ACTION-57 Review best practices document from implementation standpoint closed

<tlr> action-81 closed

<trackbot> ACTION-81 Provide draft answer to hoylen, http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0003.html closed

<klanz2> 13 I'll review, 52 still open, 74 closed 81 closed,

86 and 90 looks like duplicate

ACTION-74 closed

<trackbot> ACTION-74 Summarize recursive retrievalmethod point closed

action-81 close

action-92 pending

cancel call on 10/28

ACTION kyiu provide draft note on new algorithms for 1.1

<trackbot> Created ACTION-94 - Provide draft note on new algorithms for 1.1 [on Kelvin Yiu - due 2008-10-28].

<tlr> action-http://www.w3.org/2007/10/htmldiff

<tlr> ACTION: to introduce Kelvin to W3C spec editing [recorded in http://www.w3.org/2008/10/21-xmlsec-minutes.html#action01]

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

<tlr> ACTION: thomas to introduce Kelvin to W3C spec editing [recorded in http://www.w3.org/2008/10/21-xmlsec-minutes.html#action02]

ACTION tlr send kelvin information about editing tools

<trackbot> Created ACTION-95 - Introduce Kelvin to W3C spec editing [on Thomas Roessler - due 2008-10-28].

<trackbot> Created ACTION-96 - Send kelvin information about editing tools [on Thomas Roessler - due 2008-10-28].

Summary of Action Items

[NEW] ACTION: thomas to introduce Kelvin to W3C spec editing [recorded in http://www.w3.org/2008/10/21-xmlsec-minutes.html#action02]
[NEW] ACTION: to introduce Kelvin to W3C spec editing [recorded in http://www.w3.org/2008/10/21-xmlsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/11/12 13:40:41 $