W3C home > Mailing lists > Public > public-xmlsec@w3.org > October 2008

Meeting record: 2008-09-23

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 7 Oct 2008 16:58:29 +0200
To: public-xmlsec@w3.org
Message-ID: <20081007145829.GA42808@iCoaster.does-not-exist.org>

Minutes from our meeting on 2008-09-23 were approved and are
available online here:


A text version is included below the .signature.

Thomas Roessler, W3C  <tlr@w3.org>


                   XML Security Working Group Teleconference
                                  23 Sep 2008


   See also: [3]IRC log


          Thomas Roessler, Frederick Hirsch, Chris Solc, John Wray, Magnus
          Nyström, Scott Cantor, Bruce Rich, Ed Simon, Brian LaMacchia,
          Sean Mullan, Norm Walsh, Brad Hill, Gerald Edgar, Hal Lockhart,
          Pratik Datta, Konrad Lanz, Kelvin Yiu, Rob Miller

          Pratik, Datta

          Frederick Hirsch

          Thomas Roessler


     * [4]Topics
         1. [5]Administrative
         2. [6]Agenda Review
         3. [7]Approval of minutes
         4. [8]Liaisons and coordination
         5. [9]Best Practices
         6. [10]RetrievalMethod attack
         7. [11]implementation review?
         8. [12]Use Cases & Requirements
         9. [13]Schedule review
        10. [14]RetrievalMethod, second take
        11. [15]action items
     * [16]Summary of Action Items

Agenda Review

   fjh: Norm Walsh will give intro to xproc

   <fjh> 30 September 2008 Teleconference cancelled

   <fjh> Next meeting 7 October. Gerald Edgar is scheduled to scribe.

   <fjh> 14 October 2008 Teleconference cancelled,

   <fjh> 20-21 October 2008 F2F at TPAC.

Approval of minutes


   RESOLUTION: 16 September minutes approved

Liaisons and coordination

   <fjh> XForms - 10:30 - noon (tentative) Monday 20 October

   fjh: Working on face-to-face schedule; will meet xforms on Monday ...
   ... trying to find a way to have a break that day ...

   <fjh> EXI - 2-3:30 Monday 20 October (note correction, 1 1/2 hours)

   fjh: joint session with EXI ...

   <fjh> WebApps - 11-12 Tuesday 21 October

   tlr: anything in particular we should review for these meetings?

   fjh: xforms is mostly going to be a listening thing
   ... EXI, we had a face-to-face last year's TPAC ...
   ... will include that in the agenda; linked from administrative page


   fjh: webapps, haven't gotten anything yet
   ... but note that widget requirements are in last call ...
   ... will see that I can put together something for preparation ...
   ... re WS-Policy, trying to get them to update references to Signature
   2nd ed
   ... webapps has widget requirements in last call
   ... explicit request for review

   <fjh> WebApps Widgets 1.0 Requirements Last Call

   <fjh> [19]http://www.w3.org/TR/2008/WD-widgets-reqs-20080915/


Best Practices

   <fjh> Resolution to accept Status/Abstract and incorporate into draft


   PROPOSED: To accept revised status and abstract for best practices

   RESOLUTION: To accept revised status and abstract for best practices

   <fjh> Proposed revision for section 2.1, Best Practice 2

   fjh: Second item from Scott, revision for 2.1


   fjh: Sean had some input on this ...

   scott: some tweaking might be needed

   fjh; sean, any concerns?

   sean: sent updated e-mail this morning


   PROPOSED: adopt changes proposed by Sean

   <fjh> draft

   sean: move BP #2 and following paragraph to a later point, combine with
   BP #5 (which should be #6...)
   ... basically, move to discussion of RetrievalMethod ...
   ... and instead of moving stuff, just drop in a sentence

   PROPOSED: To accept Scott's wording with Sean's additions.

   RESOLUTION: accept Scott's wording with Sean's additions.

   <scribe> ACTION: sean to edit best practices to implement Scott's and
   his own changes; see
   [25]http://www.w3.org/2008/09/23-xmlsec-irc#T14-20-33 [recorded in

   <trackbot> Created ACTION-67 - Edit best practices to implement Scott's
   and his own changes; see
   [27]http://www.w3.org/2008/09/23-xmlsec-irc#T14-20-33 [on Sean Mullan -
   due 2008-09-30].

   <fjh> Draft review Section 1, section 2.1.4



   bhill: think there's a legitimate concern here ...
   ... if you consider using signature in office documents and the like
   ... external references can serve to track who reads documents ...
   ... there is a privacy concern here ...
   ... propose to keep this, but flash out text ...

   fjh: I have some ideas about changes

   PROPOSED: to accept changes to 2.1.4 proposed by Sean as added to by

   RESOLUTION: to accept changes to 2.1.4 proposed by Sean as added to by

   fjh: There's also changes to section 1

   RESOLUTION: to accept changes to 1 proposed by Sean as added to by

   <scribe> ACTION: sean to implement
   [31]http://www.w3.org/2008/09/23-xmlsec-irc#T14-24-47 [recorded in

   <trackbot> Created ACTION-68 - Implement
   [34]http://www.w3.org/2008/09/23-xmlsec-irc#T14-24-47 [on Sean Mullan -
   due 2008-09-30].

   <fjh> Draft review - section 2.1.2 (Best Practice 5)


   sean: xpath can have performance issues, need to pay attention, but not
   every implementation affected


   tlr: how about taking this to e-mail? (Also, don't really like

   <hal> I recommend a general disclaimer something like this

   hal: I'd like a general sentence saying "These concerns apply to
   approaches toward implementing the specification; following the best
   practices is a good idea whether or not implementation is affected by
   the concern"

   hal, please correct if the above note is wrong

   <hal> not really what I said

   <hal> but I don't object

   hal, is that better?

   bal: don't talk about specific implementations; some things might be
   sane in certain closed environments
   ... ran into that with fetch-over-web type things ...

   <fjh> ACTION: Sean to propose text to address concern of non-naive
   implementations not being vulnerable to attack [recorded in

   <trackbot> Created ACTION-69 - Propose text to address concern of
   non-naive implementations not being vulnerable to attack [on Sean
   Mullan - due 2008-09-30].

   klanz: there are standard tools to do bad things, you don't have a lot
   of influence on them
   ... think code execution in XSLT ..
   ... XSLT and XPath concern ...

   hal: to respond to the prior comment ...
   ... these still stand as best practices ...
   ... there might be reasons not to follow them ...
   ... but whole idea that somebody doesn't know how something works ...
   ... and something moves into a new environment, and boom ...
   ... that is one of the worst risks ...
   ... would like to highlight these as best practices ...
   ... it's fair to say "if you know what you're doing, you might not want
   to do this"

   bal: Hal, I hear you, I don't think that concern about poorly
   documented implementations is specific
   ... have to separate out what best practices are that we've learned ...
   ... "things you really ought not to do, and we don't see use for them"
   ... and things that ought to be better documented ...
   ... other concern, to keep scope of BP document to standard itself
   ... not attacking specific implementations ...
   ... of course just a BP document ...
   ... but people might very well run with some of what's in here and not
   understand trade-off ...
   ... 1. do not talk about bugs in particular implementations
   ... 2. be careful on wording
   ... there is tendency for documents like this to be used as
   prescriptive bans ...
   ... say "there might be good reasons for doing the things we
   discourage, but you really ought to know what you're doing"

   <hal> +1

   <fjh> bal notes concern that someone might take best practices as
   profile, disallowing things but should be treated as practice

   bal: we might want to make a hard recommendation on xslt
   ... that's really a change to the specification ...
   ... not all recommendations have equal weight ...

   fjh: bal, can you add something?

   bal: I think there ought to be a disclaimer in here, not sure where
   that went
   ... let's not do something general right now, can do that later

   tlr: add something general to SOTD?

   bal: maybe, with caveat that we might want to make stronger statement
   ... any good boilerplate?

   tlr: not sure I know of any; note that we can change later

   fjh: If we want to do normative stuff, not in BP


   <scribe> ACTION: thomas to propose disclaimer for SOTD [recorded in

   <trackbot> Created ACTION-70 - Propose disclaimer for SOTD [on Thomas
   Roessler - due 2008-09-30].

   <fjh> hal notes that best practices should reflect multiple
   applications, not just one

   hal: no objection against "make sure you know what you're doing", I
   don't understand problem with saying that more than one implementation
   has been observed to have the problem...
   ... don't say "if you think your implementation is fine, don't follow
   them" ...
   ... haven't seen the "show me your implementation" effect when
   mentioning that some implementations have problem

   smullan: we've made some progress on this
   ... early versions of BP document had stronger language on things like
   RetrievalMethod ...

   <fjh> sean notes now say less strong statements, consider this .

   smullan: also, most DOS attacks might be less serious when following BP
   1 and BP 3

   <fjh> sean notes that use of xslt may be appropriate in trusted

   pdatta: namespace node expansions ...
   ... @@ expands all namespace nodes ...
   ... there is some dependence on that feature ...
   ... interop testcase without expanding namespace nodes?

   fjh: sean noted that document shouldn't use relative namespace URIs

   <fjh> Change all examples in document to use absolute namespace URIs,
   not relative

   klanz: they're prohibited

   <brich> how about some text that says something like "There is an
   uneasy tension between security on one hand and utility and performance
   on the other hand. Circumstances may dictate an implementation must do
   something that is not the most secure. This needs to be a reasoned
   tradeoff that can be revisited in later versions of the implementation
   as necessary to address risk."


   <klanz2> The use of relative URI references, including same-document
   references, in namespace declarations is deprecated.

   <klanz2> Note:

   <klanz2> This deprecation of relative URI references was decided on by
   a W3C XML Plenary Ballot [Relative URI deprecation]. It also declares
   that "later specifications such as DOM, XPath, etc. will define no
   interpretation for them".

   fjh: sean, you said these should reject relative namespace URIs

   <fjh> [40]http://www.w3.org/TR/xml-c14n11/#DataModel

   <klanz2> [41]http://www.w3.org/TR/REC-xml-names/#reluri

   sean: our implementation rejects all the examples because of relative
   namespace URIs

   fjh: @@


   <klanz2> ns0 ... relative

   fjh: In the DOS example files, we have relative namespace URIs

   <klanz2> let's change ns0 to [43]http://www.example.org/ns0 ... to n

   <klanz2> let's change ns0 to [44]http://www.example.org/ns0 ... n

   tlr: I guess my question is whether there is any good reason for having
   relative namespaces

   fjh: we could use absolute ones as well

   <scribe> ACTION: pratik to update examples with absolute namespace URIs
   and regenerate signatures [recorded in

   <trackbot> Created ACTION-71 - Update examples with absolute namespace
   URIs and regenerate signatures [on Pratik Datta - due 2008-09-30].

   fjh: now, links to example files...
   ... we're keeping these member-visible for the moment ...

   tlr: The examples become vastly easier to understand in full
   ... could see us waiting a little longer to accommodate implementers.

   sean: even if there is an implementation that has a big problem
   ... doubt anybody will be able to fix this any time soon ...
   ... think the examples have the relevant text in there ...
   ... think that's good enough ...

   <esimon2> back in 10 min.

   fjh: no decision quite yet, decide next meeting

RetrievalMethod attack

   <fjh> RetrievalMethod attack, section 2.1.3

   fjh: long thread whether it can be recursive ...



   pdatta: fine with Sean's clarification

   fjh: what does that mean for document?
   ... does the attack depend on the KeyInfo concern?

   pdatta: no longer a denial of service attack

   fjh: sean, can you take care of this example?


   klanz2: I thought RetrievalMethod *is* recursive?


   fjh: deferred

   <fjh> Add synopsis for each Best Practice

   <klanz2> ame="Type" type="anyURI" use="optional"

   <scribe> ACTION: fjh to contribute synopsis for each best practice
   [recorded in

   <trackbot> Created ACTION-72 - Contribute synopsis for each best
   practice [on Frederick Hirsch - due 2008-09-30].

   <fjh> Misc editorial

   <fjh> Completion of implementer review actions?

   <fjh> [51]http://www.w3.org/2008/xmlsec/track/products/11

implementation review?

   fjh: Has anybody has a chance to look through the document -- how's
   review doing?
   ... Also, is publication at face-to-face a realistic option?

   <gedgar> I have to leave unfortunately.

   smullan: found that relative namespace URIs are a problem
   ... should make sure that examples are kind of accurate ...

   fjh: the bar I'm trying to get across is whether publication would
   cause any harm

   bal: as long as we talk about the spec itself, it's fine

   fjh: the document doesn't disclose things about a specific

   brich: review of document was what I committed
   ... timing isn't easy ...

   fjh: trying to understand issue
   ... want to make sure that BPs are followed? statements about specific
   ... oh well, so maybe we can't publish as quickly
   ... let's at least get pending edits out of the way

Use Cases & Requirements


   fjh: hal, you had useful material about web services
   ... how to add that?

   hal: also, what happens to long-lived documents considerations?
   ... probably the same thing should happen to that and to my material

   magnus: also talked about extending scope to not just be about
   signature and c14n, but also a few other things
   ... keyInfo e.g. is generic

   <fjh> proposal - change title to XML Security v.next use cases and

   tlr: Serious editing hasn't begun yet; some things in Shivaram's court

   fjh: need to pull things from the list

   <scribe> ACTION: magnus to provide proposal to adapt Requirements scope
   [recorded in

   <trackbot> Created ACTION-73 - Provide proposal to adapt Requirements
   scope [on Magnus Nyström - due 2008-09-30].

   hal: maybe do "domain specific requirements"?

   fjh: issues list, try to go through and extract requirements

   <fjh> issues list requirements extraction


   fjh: gerald categorized requirements here
   ... volunteers, please!

   <esimon2> I'm here!

   <esimon2> unmute me


   ed, you shouldn't be muted


   esimon2: IRC exceptionally slow again
   ... EXI review is relevant here.


   EdSimon: They aren't addressing EXI needs for signature and encryption
   ... but based on use cases, there might be native need for signature
   and encryption ...
   ... please poke them about answering
   ... there is a long conversation to be had about native XML Security
   for EXI ...

Schedule review

   <fjh> [57]http://www.w3.org/2008/02/xmlsec-charter.html#milestones

   fjh: would like to get use cases and requirements out in early November
   ... doesn't give us a whole lot of time to produce something to get us
   started ...
   ... focus on requirements soon

   <esimon2> Specifically what I said was that I have yet to see any
   discussion on EXI requirements for EXI-native signature and encryption.
   EXI has published a document discussing how current XML Signature and
   XML Encryption can be used with EXI but that, to me, does not seem
   sufficient. Need to find out if the EXI group sees a potential
   requirement for EXI-native signatures and encryption.

RetrievalMethod, second take

   klanz: recursive retrieval method or not?

   <klanz2> [58]http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo

   <klanz2> [59]http://www.w3.org/TR/xmldsig-core/#sec-RetrievalMethod

   <klanz2> <attribute name="Type" type="anyURI" use="optional"/>

   tlr: eek, I'm confused. Please send to mailing list

   <scribe> ACTION: klanz2 to summarize recursive retrievalmethod point
   [recorded in

   <trackbot> Created ACTION-74 - Summarize recursive retrievalmethod
   point [on Konrad Lanz - due 2008-09-30].

action items

   fjh: propose bulk closure

   ACTION-27 closed

   <trackbot> ACTION-27 contact crypto hardware and suiteB experts in NSA
   regarding XML Security WG and possible involvement closed


   <trackbot> ACTION-31 -- Thomas Roessler to investigate ebXML liaison
   (see ACTION-6) -- due 2008-08-19 -- PENDINGREVIEW

   <trackbot> [61]http://www.w3.org/2008/xmlsec/track/actions/31

   ACTION-31 closed

   <trackbot> ACTION-31 Investigate ebXML liaison (see ACTION-6) closed


   <trackbot> ACTION-39 -- Hal Lockhart to contribute web service related
   scenario -- due 2008-08-25 -- PENDINGREVIEW

   <trackbot> [62]http://www.w3.org/2008/xmlsec/track/actions/39

   ACTION-39 closed

   <trackbot> ACTION-39 Contribute web service related scenario closed

   ACTION-42 closed

   <trackbot> ACTION-42 Elaborate on "any document" requirement vs
   canonicalizing xml:base closed

   ACTION-47 closed

   <trackbot> ACTION-47 Add error noted in
   021.html to c14n 1.1 errata page closed

   ACTION-66 pending


   <trackbot> ACTION-66 -- Frederick Hirsch to follow up with xsl to get
   documents related to serialization -- due 2008-09-23 -- PENDINGREVIEW

   <trackbot> [64]http://www.w3.org/2008/xmlsec/track/actions/66

   fjh: we have a long list of open actions
   ... please get the ones done that relate to requirements ...

   <fjh> [65]http://www.w3.org/2008/xmlsec/actions-open.html

   <bal> yes


   <trackbot> ACTION-56 -- Scott Cantor to propose text for KeyInfo
   processing in best practices.
   -- due 2008-09-16 -- OPEN

   <trackbot> [67]http://www.w3.org/2008/xmlsec/track/actions/56

   fjh: any other updates?
   ... concrete proposals and material on the list, please ...
   ... priority for requirements document ...

   tlr: might also be worth talking about the way the process works

   <esimon2> IRC died on me; was the EXI action (was it Action-25?)

   ACTION-25 closed

   <trackbot> ACTION-25 Give feedback on xml schema best practice in
   xml-cg closed


   <trackbot> ACTION-25 -- Frederick Hirsch to give feedback on xml schema
   best practice in xml-cg -- due 2008-08-19 -- CLOSED

   <trackbot> [68]http://www.w3.org/2008/xmlsec/track/actions/25


   <trackbot> ACTION-19 -- Gerald Edgar to evaluate Issues and Actions for
   appropriate placement -- due 2008-08-19 -- PENDINGREVIEW

   <trackbot> [69]http://www.w3.org/2008/xmlsec/track/actions/19

   action-22 closed

   <trackbot> ACTION-22 Review EXI docs that were published closed


   <trackbot> ACTION-56 -- Scott Cantor to propose text for KeyInfo
   processing in best practices.
   -- due 2008-09-16 -- PENDINGREVIEW

   <trackbot> [71]http://www.w3.org/2008/xmlsec/track/actions/56

   action-56 closed

   <trackbot> ACTION-56 Propose text for KeyInfo processing in best

Summary of Action Items

   [NEW] ACTION: fjh to contribute synopsis for each best practice
   [recorded in
   [NEW] ACTION: klanz2 to summarize recursive retrievalmethod point
   [recorded in
   [NEW] ACTION: magnus to provide proposal to adapt Requirements scope
   [recorded in
   [NEW] ACTION: pratik to update examples with absolute namespace URIs
   and regenerate signatures [recorded in
   [NEW] ACTION: sean to edit best practices to implement Scott's and his
   own changes; see [77]http://www.w3.org/2008/09/23-xmlsec-irc#T14-20-33
   [recorded in
   [NEW] ACTION: sean to implement
   [80]http://www.w3.org/2008/09/23-xmlsec-irc#T14-24-47 [recorded in
   [NEW] ACTION: Sean to propose text to address concern of non-naive
   implementations not being vulnerable to attack [recorded in
   [NEW] ACTION: thomas to propose disclaimer for SOTD [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [84]scribe.perl version 1.133
    ([85]CVS log)
    $Date: 2008/10/07 14:57:43 $


   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0061.html
   3. http://www.w3.org/2008/09/23-xmlsec-irc
   4. http://www.w3.org/2008/09/23-xmlsec-minutes.html#agenda
   5. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item01
   6. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item02
   7. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item03
   8. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item04
   9. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item05
  10. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item06
  11. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item07
  12. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item08
  13. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item09
  14. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item10
  15. http://www.w3.org/2008/09/23-xmlsec-minutes.html#item11
  16. http://www.w3.org/2008/09/23-xmlsec-minutes.html#ActionSummary
  17. http://www.w3.org/2008/09/16-xmlsec-minutes.html
  18. http://www.w3.org/2008/xmlsec/Group/
  19. http://www.w3.org/TR/2008/WD-widgets-reqs-20080915/
  20. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0049.html
  21. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0040.html
  22. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0044.html
  23. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0063.html
  24. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/
  25. http://www.w3.org/2008/09/23-xmlsec-irc#T14-20-33
  26. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action01
  27. http://www.w3.org/2008/09/23-xmlsec-irc#T14-20-33
  28. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0046.html
  29. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0055.html
  30. http://www.w3.org/2008/09/23-xmlsec-irc#T14-25-06
  31. http://www.w3.org/2008/09/23-xmlsec-irc#T14-24-47
  32. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action02
  33. http://www.w3.org/2008/09/23-xmlsec-irc#T14-25-06
  34. http://www.w3.org/2008/09/23-xmlsec-irc#T14-24-47
  35. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0050.html
  36. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0056.html
  37. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action03
  38. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action04
  39. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0050.html
  40. http://www.w3.org/TR/xml-c14n11/#DataModel
  41. http://www.w3.org/TR/REC-xml-names/#reluri
  42. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/samples/dos_xpath.xml
  43. http://www.example.org/ns0
  44. http://www.example.org/ns0
  45. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action05
  46. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0059.html
  47. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0051.html
  48. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/#id64346
  49. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0054.html
  50. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action06
  51. http://www.w3.org/2008/xmlsec/track/products/11
  52. http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/Overview.html
  53. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action07
  54. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0052.html
  55. http://lists.w3.org/Archives/Member/member-xmlsec/2008Sep/0022.html
  56. http://lists.w3.org/Archives/Member/member-xmlsec/2008Sep/0022.html
  57. http://www.w3.org/2008/02/xmlsec-charter.html#milestones
  58. http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
  59. http://www.w3.org/TR/xmldsig-core/#sec-RetrievalMethod
  60. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action08
  61. http://www.w3.org/2008/xmlsec/track/actions/31
  62. http://www.w3.org/2008/xmlsec/track/actions/39
  63. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.html
  64. http://www.w3.org/2008/xmlsec/track/actions/66
  65. http://www.w3.org/2008/xmlsec/actions-open.html
  66. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0014.html
  67. http://www.w3.org/2008/xmlsec/track/actions/56
  68. http://www.w3.org/2008/xmlsec/track/actions/25
  69. http://www.w3.org/2008/xmlsec/track/actions/19
  70. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0014.html
  71. http://www.w3.org/2008/xmlsec/track/actions/56
  72. http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0014.html
  73. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action06
  74. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action08
  75. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action07
  76. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action05
  77. http://www.w3.org/2008/09/23-xmlsec-irc#T14-20-33
  78. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action01
  79. http://www.w3.org/2008/09/23-xmlsec-irc#T14-25-06,
  80. http://www.w3.org/2008/09/23-xmlsec-irc#T14-24-47
  81. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action02
  82. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action03
  83. http://www.w3.org/2008/09/23-xmlsec-minutes.html#action04
  84. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  85. http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 7 October 2008 14:59:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:10 UTC