See also: IRC log
<brich> ScribeNick: brich
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 ...
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...
<xmp>
<p>
<span>do</span>
<span>not</span>
</p>
</xmp>
<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
http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html
<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
http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0077.html
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
<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 ...
<klanz2> http://tools.ietf.org/html/rfc3986#section-konrad, 5.1.2
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
<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
<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
<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
<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].