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

Meeting record: 2008-07-29

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 12 Aug 2008 16:13:52 +0200
To: public-xmlsec@w3.org
Message-ID: <20080812141352.GA20118@iCoaster.does-not-exist.org>

Minutes from our meeting on 2008-07-29 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
                                  29 Jul 2008


   See also: [3]IRC log


          Frederick Hirsch, Konrad Lanz, Juan Carlos Cruellas, ChrisSolc,
          Gerald Edgar, Sean Mullan, Brad Hill, Scott Cantor, Ed Simon,
          Prateek Datta, John Wray, Shivaram, Kelvin Yiu

          Rob Miller, Bruce Rich, Anil Saldhana

          Frederick Hirsch

          Scott Cantor


     * [4]Topics
         1. [5]Administrative
         2. [6]Meeting Planning
         3. [7]XPath 2
         4. [8]Web Pages
         5. [9]Products List
         6. [10]Minutes Approval
         7. [11]Issues List Management
         8. [12]Canonicalization Requirements
         9. [13]Namespaces and Namespace Undeclarations
        10. [14]EXI
        11. [15]Algorithm Requirements
        12. [16]Transforms
        13. [17]Schema Validation after adding a signature
        14. [18]Action Items
     * [19]Summary of Action Items



   sidenote from later in meeting: use your W3C login name as an IRC
   handle for ease of assigning actions

  Meeting Planning

   fjh: next call 8/12/08

   <fjh> TPAC [21]http://www.w3.org/2008/10/TPAC/Schedule

   fjh: FtF scheduled Oct 20-21

   <fjh> F2F planning

   <fjh> [22]http://www.w3.org/2002/09/TPOverview.html#Future

   fjh: next year, 4 FtF mtgs

   fjh: soliciting hosts for ftf meetings

   <shivaram> Feb/March may be a better time in Seattle

   <shivaram> due to weather

   <gerald-> I could look into hosting the meeting here the first portion
   of 2009, I could work with Kelvin on this.

  XPath 2

   fjh: talked to XML coord group, offer to get presentation but need
   ... need to respond late this week / early next

   klanz2: relationship between data models in v1 and v2
   ... understand differences

   <fjh> klanz2: impact of namespace prefix undeclarations on the XPath

   <fjh> ... relationship to xml 1.1

   <scottc> core features that we would not want to profile out

   <fjh> jccruellas: views on main relationships with xml signature for
   xpath 2.0

   <fjh> ... most used features of XPath 2.0

   <fjh> ... connections with xpath filter 2.0

   klanz: implementation experience with performance, with respect to
   namespace processing

   jccruellas: insight into XPath processing performance related to
   features, XPath 2.0 vs 1.0, and metrics used

   <scribe> ACTION: fjh to draft message about XPath 2 presentation to
   mailing list [recorded in

   <trackbot> Created ACTION-20 - Draft message about XPath 2 presentation
   to mailing list [on Frederick Hirsch - due 2008-08-05].

  Web Pages

   <fjh> public [24]http://www.w3.org/2008/xmlsec/Overview.html

   fjh: updated public and admin pages, please review

   <fjh> administrative

  Products List


   fjh: separate errata from new versions

   jccruellas: any product related to XPath Filter 2?

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

   fjh: yes, listed in deliverables, add to product list

   jccruellas: add product for XPath filter

   RESOLUTION: approved product list with addition of XPath Filter

  Minutes Approval

   fjh: minor revisions sent out

   klanz2: appropriate to wait another week


   fjh: please check member list and send a note if anybody missing

   <pdatta> I was there on the 2nd half on both days

   fjh: several people missing who dialed in, so please report if you're

   <klanz2> Check here as well please:



  Issues List Management

   <fjh> [31]http://www.w3.org/2008/xmlsec/Group/Overview.html#issues

   gerald-: reviewed issues and actions
   ... resulting list seemed appropriate, but should review
   ... need relationship between issues captured in some way

   fjh: some work on tracker ...

   gerald-: seems to work now
   ... actions are specific tasks for people, issues are general topics
   for discussion

   issues might lead to actions

   fjh: issue of substance to the standards, related to our deliverables

   scottc: no final decision to use tracker, but manual no good
   ... want to use tracker for actions, but issues could be handled other

   gerald-: other tools needed to track relationships

   fjh: Agenda reviews are always implicit ...

   <klanz2> re issues: maybe use titles to reflect relation ships

   jccruellas: regrets for scheduled meeting as scribe
   ... next meeting, 8/12

   <fjh> regrets, klanz 8/12

   scottc: happy to provide Jira instance if that's helpful for issues.
   will send email to fjh about it

  Canonicalization Requirements

   fjh: identified at ftf as a core issue
   ... avoiding big or breaking changes is helpful to adoption
   ... understand issues, priorities, but still limit changes when

   seems like one use case or requirement is to signal inline what degree
   of c14n might be needed

   relationship between serialization and c14n

   fjh: streaming is another consideration

   <csolc> canonicalization as a final transform could output something
   other than a nodeset or an octect stream.

   klanz2: improving of robustness when editing unsigned parts of document

   <klanz2> potentially including reindention ...

   pdatta: whitespace between element tags

   pdatta: ignoreable-white-space that has not been ignored ...

   csolc: schema define ordered relationship of elements

   <klanz2> xs:all ?

   csolc: schema communicates semantics, c14n only about the bytes

   scottc: schema conveys semantics that c14n doesn't understand

   <EdS> In my view, schema communicates structure -- namespace
   communicates semantics.

   <EdS> Namespace defines the semantics (meaning of XML elements); schema
   defines the structural relationship of the XML elements (and points to
   their semantics (namespace)); and XML instances are instances of an XML

   scottc: yes, but much of the semantic comes from the connection between
   elements, which is a schema

   <EdS> I would say, in reference to Scott's point above, that schemas
   provide semantics in the sense that they indicate a hierarchy of
   elements which implies a semantically-meaningful grouping relationship.

   scottc: xml doc communicates information - expectation that sig should
   verify when the same, despite details

   csolc: e.g. schema says order doesnt matter, c14n takes element order
   important, processor may reorder before c14n, then unexpected
   verification failure

   klanz: line breaks in base64 are horrible

   scottc: schema type normalization is a common source of breakage

   <fjh> possible issue: simplified c14n for signing versus more general
   c14n, e.g. not produce compliant xml document

   <fjh> issue: simplified c14n for signing versus more general c14n, e.g.
   not produce compliant xml document

   <trackbot> Created ISSUE-37 - Simplified c14n for signing versus more
   general c14n, e.g. not produce compliant xml document ; please complete
   additional details at
   [32]http://www.w3..org/2008/xmlsec/track/issues/37/edit ..

   pdatta: other transforms depend on c14n1, e.g. STR

   <gerald-> I need to leave, unfortuantely, talk to you all at the next

   Kelvin: too many dependencies on XML specs, making impls too complex
   and big
   ... goal to minimize and simplify dependencies
   ... reduces threat surface

   <scribe> ACTION: Kelvin to propose ways to reduce dependencies on XML
   specs [recorded in

   <trackbot> Created ACTION-21 - Propose ways to reduce dependencies on
   XML specs [on Kelvin Yiu - due 2008-08-05].

   bhill: in use cases, distinction between need for XML signing and need
   for signing in XML
   ... simplified cases where you want the XML processor involved, but not
   necessarily in a fully robust XML context

   <fjh> issue: profile for signature processing for non-XML or for
   contrained XML requirements

   <trackbot> Created ISSUE-38 - Profile for signature processing for
   non-XML or for contrained XML requirements ; please complete additional
   details at [34]http://www.w3..org/2008/xmlsec/track/issues/38/edit ..

  Namespaces and Namespace Undeclarations


   scottc: is namespace prefix undeclaration a breaking change?

   klanz2: other changes due to unicode as well
   ... some xml 1.1 features may go into 1.0
   ... useful to send comments/questions to xml core wg

   <klanz2> [36]http://lists.w3.org/Archives/Public/public-xml-core-wg/

   <fjh> issues list [37]http://www.w3.org/2008/xmlsec/track/issues/

   <fjh> issue: Namespace Undeclarations and canonicalization

   <trackbot> Created ISSUE-39 - Namespace Undeclarations and
   canonicalization ; please complete additional details at
   [38]http://www.w3..org/2008/xmlsec/track/issues/39/edit ..


   <fjh> EXI documents published - [39]http://www.w3.org/News/2008#item128

   <scottc> ACTION: esimon2 to review EXI docs that were published
   [recorded in

   <trackbot> Created ACTION-22 - Review EXI docs that were published [on
   Ed Simon - due 2008-08-05].

   <fjh>: need to review where they mention signing, verification

   EdS: expect exi goals to include efficient signing/verification of exi

   jccruellas: exi another serialization, so are c14n and other concerns
   the same?

   <EdS>: Will take approach that EXI requirements for signing will be
   based on EXI use cases and high efficiency.

   jccruellas: does the usual 1 to many relationship exist between c14n
   and the source XML?

   <fjh> issue: appropriate signing/verification position in EXI workflow,
   expectations and correctness review

   <trackbot> Created ISSUE-40 - Appropriate signing/verification position
   in EXI workflow, expectations and correctness review ; please complete
   additional details at
   [41]http://www.w3..org/2008/xmlsec/track/issues/40/edit ..

   scottc: could be orthogonal, but may be ways to take advantage of EXI,
   e.g. XML nesting issues?

   <fjh> issue: signing compact EXI representation of XML - is that
   reproducable for verification

   <trackbot> Created ISSUE-41 - Signing compact EXI representation of XML
   - is that reproducable for verification ; please complete additional
   details at [42]http://www.w3..org/2008/xmlsec/track/issues/41/edit ..

   <fjh> ACTION: frederick to contact EXI re signature/verification use
   cases [recorded in

   <trackbot> Created ACTION-23 - Contact EXI re signature/verification
   use cases [on Frederick Hirsch - due 2008-08-05].

   klanz: could transmission of EXI break signatures?

  Algorithm Requirements


   <klanz2> wonders if SUN has FastInfoset people interested in similar
   matters as EXI?



   sean: concerned about relaxing MUSTs
   ... existing signatures need to continue to validate

   <jccruellas> +1

   jccruellas: diff. requirements on signing vs. verifying seems like a
   good solution

   <klanz2> -1

   klanz: disagrees, diff between the two is a small gap, so doesn't help
   ... maybe change MUST to SHOULD, but agrees with sean generally

   csolc: need sig 2.0 indicator to make real changes

   <fjh> ack 2nd edition

   <fjh> ack 2nd

   Kelvin: does w3c have guidance for how to deprecate things?
   ... timelines for dropping
   ... would like to see SHA 256 and at least one NIST ECC on the
   mandatory list

   scottc: some things might be important enough to force people to
   support them

   Kelvin: stronger crypto may have use where interop with weaker crypto
   not an issue

   <klanz2> keep in mind that XAdES needs legacy algorithms for a long
   time, secured by stronger algorithms

   <fjh> ... move SHA1 algs to recommended list.

   <klanz2> ... and timestamps

   <klanz2> .. cf. XAdES ArchiveTimestamp

   sean: separate implementation reqs from spec reqs

   <klanz2> deprecation for outdated algorithms on signing, " ... the
   implementation must issue a warning or so .... "

   scottc: could have different levels of conformance, separate doc

   jccruellas: one doc with the core stuff, algorithm specifics, and rules
   for what to implement may not be ideal
   ... algorithms often specific to deployment context

   jccruellas: core + one or more algorithm docs that include xml syntax
   related to algorithm and requirementss

   klanz: often a need to verify old signatures
   ... emitting warnings on older algorithms, but not the same as not
   computing them any more

   <jccruellas> +1



   <fjh> (sean)


   <klanz2> We could distinguish three cases here:


   <klanz2> 1. New and Legacy Processing would produce the same
   ... 2. Processing that isn't backwards compatible
   ... 3. New Processing Models
   ... first case limits us to existing transforms
   ... second allows us to introduce new identifiers


   scottc: prefer not to use transform to signal data, could be misuse of
   ... could use hints
   ... not necessarily xml processing instruction


   pdatta: preserving forward compatibility via adding attributes, will it
   break people?
   ... could add attributes to existing elements without breaking existing
   implementations that do not expect it
   ... xpath implies DOM, but provide a hint that some transforms could be

   <klanz2> +1

   <klanz2> to see how far we get with hints

   <fjh> issue: backward and forward compatibility

   <trackbot> Created ISSUE-42 - Backward and forward compatibility ;
   please complete additional details at
   [52]http://www.w3..org/2008/xmlsec/track/issues/42/edit ..

   <EdS> I suggest calling it 1.1 if we restrict ourselves to non-breaking
   changes and call it 2.0 if/when we decide to go for breaking changes.

   scottc: correcting the schema is important

   <fjh> issue: improvements to XML Signature schema

   <trackbot> Created ISSUE-43 - Improvements to XML Signature schema ;
   please complete additional details at
   [53]http://www.w3..org/2008/xmlsec/track/issues/43/edit ..

   <scribe> ACTION: scantor to review schema for improvements [recorded in

   <trackbot> Created ACTION-24 - Review schema for improvements [on Scott
   Cantor - due 2008-08-05].

   <EdS> +1 to Scott's schema review

  Schema Validation after adding a signature

   fjh: capability to envelope a Signature as a generic feature in


   fjh: does new xsd provide something new here?

   EdS: wildcard opens up to security threat
   ... special schema attribute in a signature?
   ... design for document should include signature in schema if
   anticipated signing

   <fjh> ... best practice for schema?

   <fjh> ACTION: frederick to give feedback on xml schema best practice in
   xml-cg [recorded in

   <trackbot> Created ACTION-25 - Give feedback on xml schema best
   practice in xml-cg [on Frederick Hirsch - due 2008-08-05].

   klanz: 2 cases
   ... signature is a first class object so designer needs to be aware of
   ... layered approach where the signature is separate from the XML

   eds: only speaking of enveloped signatures

   <csolc> the schema validation could ignore the signatures.

   Kelvin: agrees that signature is first class citizen, but maybe add
   more flexible approach to detached signatures

   eds: agrees, add support for a pointer to a signature in the schema

   scottc: in other words, an xsi:sig attribute?

   EdS: or xml:sig

   <EdS> Idea is that a special attribute, perhaps in XML Schema or
   perhaps even better in the XML spec, for referencing a signature
   (detached or maybe not) that applies to the element.

   <fjh> issue: requirement to enable signatures on documents that do not
   anticipate signatures in the schema

   <trackbot> Created ISSUE-44 - Requirement to enable signatures on
   documents that do not anticipate signatures in the schema ; please
   complete additional details at
   [57]http://www.w3..org/2008/xmlsec/track/issues/44/edit ..

  Action Items

   fjh: if completed, please send to list

   with ACTION-# in the body and title indicating status of action

   fjh: look at old best practices document from earlier WG

   <fjh> [58]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/

Summary of Action Items

   [NEW] ACTION: esimon2 to review EXI docs that were published [recorded
   in [59]http://www.w3.org/2008/07/29-xmlsec-minutes.html#action05]
   [NEW] ACTION: fjh to draft message about XPath 2 presentation to
   mailing list [recorded in
   [NEW] ACTION: frederick to contact EXI re signature/verification use
   cases [recorded in
   [NEW] ACTION: frederick to give feedback on xml schema best practice in
   xml-cg [recorded in
   [NEW] ACTION: Kelvin to propose ways to reduce dependencies on XML
   specs [recorded in
   [NEW] ACTION: scantor to review schema for improvements [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [65]scribe.perl version 1.133
    ([66]CVS log)
    $Date: 2008/08/12 14:11:55 $


   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0040.html
   3. http://www.w3.org/2008/07/29-xmlsec-irc
   4. http://www.w3.org/2008/07/29-xmlsec-minutes.html#agenda
   5. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item01
   6. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item03
   7. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item04
   8. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item05
   9. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item06
  10. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item07
  11. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item08
  12. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item09
  13. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item10
  14. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item12
  15. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item13
  16. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item14
  17. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item15
  18. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item16
  19. http://www.w3.org/2008/07/29-xmlsec-minutes.html#ActionSummary
  20. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0040.html
  21. http://www.w3.org/2008/10/TPAC/Schedule
  22. http://www.w3.org/2002/09/TPOverview.html#Future
  23. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action01
  24. http://www.w3.org/2008/xmlsec/Overview.html
  25. http://www.w3.org/2008/xmlsec/Group/Overview.html
  26. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0019.html
  27. http://www.w3.org/2008/02/xmlsec-charter.html#deliverables
  28. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0034.html
  29. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0035.html
  30. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/att-0035/16-xmlsec-minutes.html
  31. http://www.w3.org/2008/xmlsec/Group/Overview.html#issues
  32. http://www.w3.org/2008/xmlsec/track/issues/37/edit
  33. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action02
  34. http://www.w3.org/2008/xmlsec/track/issues/38/edit
  35. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0025.html
  36. http://lists.w3.org/Archives/Public/public-xml-core-wg/
  37. http://www.w3.org/2008/xmlsec/track/issues/
  38. http://www.w3.org/2008/xmlsec/track/issues/39/edit
  39. http://www.w3.org/News/2008#item128
  40. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action05
  41. http://www.w3.org/2008/xmlsec/track/issues/40/edit
  42. http://www.w3.org/2008/xmlsec/track/issues/41/edit
  43. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action06
  44. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0035.html
  45. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0036.html
  46. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0038.html
  47. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0016.html
  48. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0031.html
  49. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/att-0033/00-part
  50. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0034.html
  51. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/att-0033/00-part
  52. http://www.w3.org/2008/xmlsec/track/issues/42/edit
  53. http://www.w3.org/2008/xmlsec/track/issues/43/edit
  54. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action08
  55. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0018.html
  56. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action09
  57. http://www.w3.org/2008/xmlsec/track/issues/44/edit
  58. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/
  59. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action05
  60. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action01
  61. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action06
  62. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action09
  63. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action02
  64. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action08
  65. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  66. http://dev.w3.org/cvsweb/2002/scribe/

Thomas Roessler, W3C  <tlr@w3.org>
Received on Tuesday, 12 August 2008 14:14:33 UTC

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