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

Meeting record: XML Security weekly 2008-08-26

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 2 Sep 2008 16:12:45 +0200
To: public-xmlsec@w3.org
Message-ID: <20080902141245.GA12426@iCoaster.does-not-exist.org>

Minutes from our meeting on 2008-08-26 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
                                  26 Aug 2008


   See also: [3]IRC log


          Frederick Hirsch(fjh), Sean Mullan (smullan), Thomas Roessler
          (tlr), Ed Simon (esimon2), Brian LaMacchia (bal), Bruce Rich
          (brich), Hal Lockhart (hal), Magnus Nystrom (magnus), Chris solc
          (csolc), John Wray (jwray), Scott cantor(scantor), Konrad Lanz
          (klanz2) , Pratik Datta (pratik), Kelvin Yiu (kyiu), Bradley
          hill (bhill) , shivaram mysore (shivaram) , Subramanian
          Chidambaram (subu)

          Juan Carlos Cruellas, Rob Miller

          Frederick Hirsch

          Subramanian Chidambaram


     * [4]Topics
         1. [5]Administrivia
         2. [6]XProc processing model
         3. [7]NIST
         4. [8]Tech plenary
         5. [9]Minutes Approval
         6. [10]C14N11 errata
         7. [11]Pending Action Review
         8. [12]Best practices
         9. [13]Usecases and requirements
        10. [14]Nodesets
        11. [15]Simple sign
        12. [16]V.next discussion
        13. [17]Issues List
     * [18]Summary of Action Items

   <trackbot> Date: 26 August 2008


   <Gerald_Edgar> I am here, and I will be here to take minutes next week

   <fjh> 14 October and 30 Sept

   <tlr> PROPOSED: cancel 30 September and 14 October

   <tlr> RESOLUTION: cancel 30 September and 14 October

   <fjh> [19]http://www.w3.org/2008/10/TPAC/Overview.html

   <fjh> W3C Registration deadline 28 September

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

   fjh: Please register for TPAC

   <fjh> [21]http://www.w3.org/2002/09/wbs/42458/xmlsecearly2009/

   <fjh> above is questionnaire for f2f planning, please complete it so we
   can decide our F2F date.

   <fjh> XAdES plugfest


   klanz2: Orientation meeting on Xades in Plugfest


   <klanz2> XAdES Plugtest

XProc processing model



   fjh: If people could look at the principles of xproc model
   ... it will be good

   <fjh> also look at use cases for signature and encryption

   fjh: it is an interesting case

   <bal> one sec

   fjh: if we think of simplifying the encryption


   <fjh> bal notes randomized hashing is an option now, need to define
   randomized signature algorithm

   bal: to summarize

   hal: There was a workshop at ibm regarding the random hashing

   <klanz2> two levels

   <klanz2> a) ds:Reference

   <klanz2> b) ds:Signature

   <klanz2> ad b) -> RSA-PSS

   klanz: for (a) there is a proposal from IBM and for (b) there is a
   proposal from IAIK

   fjh: we will wait until we see brian's email

Tech plenary

   <fjh> Please note that there is a request for topic suggestions for the
   Tech Plenary:

Minutes Approval

   RESOLUTION: August 19th minutes approved

C14N11 errata

   <tlr> (strictly, as a proposed erratum)


   <fjh> [28]http://www.w3.org/TR/xml-c14n11/#Example-DocSubsetsXMLAttrs

   <bal> seems fine to me

   <tlr> ACTION: thomas to add
   021.html to c14n 1.1 errata page [recorded in
   [30]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action01 ]

   <trackbot> Created ACTION-47 - Add
   021.html to c14n 1.1 errata page [on Thomas Roessler - due 2008-09-02].

   RESOLUTION: Accept as a proposed errata for C14n

   <scribe> ACTION: tlr to put the link for the proposed errata [recorded
   in [32]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action02]

   <trackbot> Created ACTION-48 - Put the link for the proposed errata [on
   Thomas Roessler - due 2008-09-02].

   <tlr> it's all ok, and ACTION-47 took care of that already

   <tlr> trackbot, close ACTION-48

   <trackbot> ACTION-48 Put the link for the proposed errata closed

Pending Action Review

   <tlr> ACTION-5 open

   <fjh> still working with Jamie Clark at OASIS

   ACTION-23 closed

   <trackbot> ACTION-23 Contact EXI re signature/verification use cases

   ACTION-28 closed

   <trackbot> ACTION-28 update OASIS liaison information recorded at W3C:
   [33]http://www.w3.org/2001/11/StdLiaison#OASIS closed

   ACTION-25 open

   <tlr> ACTION-28 closed

   <trackbot> ACTION-28 update OASIS liaison information recorded at W3C:
   [34]http://www.w3.org/2001/11/StdLiaison#OASIS closed

   <tlr> ACTION-25?

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

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

   ACTION-35 closed

   <trackbot> ACTION-35 Contact XML Processing WG closed

   <tlr> [36]http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/

   ACTION-45 closed

   <trackbot> ACTION-45 Produce template for requirements document closed

Best practices

   fjh: Cleaned and did editorial work, so can we accept Brad's proposal
   with those additional changes?

   RESOLUTION: Accept brad's proposal as edited by fjh which includes the

   <tlr> Getting Brad CVS access is all setup

   <scribe> ACTION: bhill to edit the best practices document [recorded in

   <trackbot> Created ACTION-49 - Edit the best practices document [on
   Bradley Hill - due 2008-09-02].

Usecases and requirements

   <fjh> Please review template at

   fjh: anybody got a chance to look?

   <bal> no, haven't had a chance

   magnus: hope to have time to look over the week

   <gedgar> I have not yet, I till will lok at it in the next few days

   <shivaram> can we add a "Out of Scope" section to include anything that
   we will address - this is for the requirements doc

   tlr: Do not have the bandwidth to drive the content of the requirements

   shivaram i will be able to help with the content

   <tlr> shivaram, want write access to the document?

   <shivaram> sure - I would appreciate write access - thanks

   <tlr> shivaram, please send SSH key

   <tlr> fjh: happy to add out of scope section to document

   <klanz2> ok for me

   <tlr> RESOLUTION: to add out of scope section to requirements document

   <gedgar> there is also a need to move issues into the requirements
   documents and close the issue

   <tlr> gedgar, I think that'll happen as we walk through these issues



   fjh: There was an conversation started by pratik

   pratik: xml signature, we have requirements to sign parts of the
   ... may be fullfledged nodesets is not the way to go
   ... xpath has the concept of namespace nodes
   ... namespace nodes have impact on performance

   <klanz2> Namespace Distribution Across DOM is very expensive, right

   pratik: we redefine the rqmts that full nodesets is not required


   <klanz2> A SAX/STAX Node List and some namespace xml namespace context

   pratik: we still could use xpath to identify the nodeset

   <klanz2> +1 to Pratik, profile XPath (e.g. Not to remove namespace
   nodes and the like)

   pratik: what do we actually want to sign


   <klanz2> q

   pratik: extend the xpath transform element
   ... 2 alternative forms of presentation

   tlr: we are mixing 2 discussions, one is what needs to be preserved by

   <klanz2> I think it's worth looking at Exclusive C14n's definition of
   visibly used prefixes and the use of the InclusiveNamespacePrefixList

   <pratik> There are existing implementations that use XPath Transform.
   To have backwards compatibility with them, we can extend the XPath
   Transform, so that it can specify the transform in two ways - the old
   way, and a new way which give a list of included elements, and a list
   of excluded elements/attributes

   klanz2: suggesting that when we select using xpath transform

   we should change the api to include the namespace context

   klanz2: we should change the api to include the namespace context, e.g.
   augment XPath node selection with list of required namespaces

   <klanz2> i.e. add ... | //namespace::* to every XPath expresion

   pratik: more efficient implementation would not use xpath transform at

   <scribe> ACTION: pratik to draft a strawman for alternative to xpath
   transform [recorded in

   <trackbot> Created ACTION-50 - Draft a strawman for alternative to
   xpath transform [on Pratik Datta - due 2008-09-02].


   <klanz2> spex

   <fjh> XProc requires XPath 2.0, may be a performance issue

   <klanz2> [44]http://spex.sourceforge.net/

   <tlr> [45]http://www.cs.umd.edu/projects/xsq/

   <fjh> discussion of streaming xpath implementations

   <tlr> tlr: there seem to be some streaming xpath implementations,

   <tlr> pratik: they don't work very well when xpath expressions go

   <bhill> XPath 2.0 is turing complete and network able, as XSLT

   <bhill> nightmare from a security perspective

   <tlr> tlr: so, basically, if there's certain xpath expressions,
   performance degrades

   <tlr> bhill, good point

   <klanz2> ds:Reference ?

   <klanz2> value ?

   <bal> referencetarget?

   <tlr> bhill: xpath 2.0 is a non-starter for signature. it is
   Turing-complete, with ability to make arbitrary network operations

   <tlr> ... not suitable for processing hostile data ...

   <tlr> ... it's xslt all over again ...

   <klanz2> we need a secure subset ? Can they tell us where it gets hairy

   <tlr> tlr: so, just to get this clear, xpath 2.0 is turing-complete,
   1.0 isn't?

   <tlr> bhill: yeah, 2.0 has loops and network access and stuff

   <klanz2> Is this an Issue?

   <klanz2> Namespace Retaining?

Simple sign


   scantor: Not a good solution as simple sign is trying to solve only a
   particular usecase

   <tlr> rathole alert.

   <klanz2> and at the end of the day they found a solution, so where is
   the problem ;-9

   <klanz2> well, if c14n Vnext and transforms are faster in the future
   most of it should dissolve anyway ...

   <klanz2> ... and easier streamable

   <klanz2> what was the constraint?

   <scantor> simplicity of implementation

   <klanz2> so memory footprint

   <klanz2> and deployment

   <bhill> +1 to pratik's comment

   <fjh> pratik: should be possible to implement using basic crypto and
   xml processing in environment

   <fjh> pratik: asn.1 processing is complicated, so XML is good for
   composition and parsing, have xml library

   pratik: xml is better than ASN for decomposition

   <bal> +1; there's a lot of complexity buried under "having an ASN.1
   compiler in the environment"

   pratik: represent the signature in a xml

   <fjh> +1

   <fjh> tlr: issue finding and using canonicalization libraries

   tlr: problem is finding c14n libraries and using them

   <fjh> Assumptions-available crypto and XML libraries

   <fjh> sean: why not simply use xml signature without canonicalization
   alg if no changes occuring requiring canonicalization

   <klanz2> We need to look one step ahead of C14n - I think -,

   <klanz2> Its not easy to say

   <klanz2> * ... I don't care about namespace prefixes

   <klanz2> * ... I don't care about whitespace

   <klanz2> * ... I dont't care about multiple successive whitespace
   characters ...

   <klanz2> and the like

   <klanz2> you have to write hard XPath Filters even use XSLT ...

   <klanz2> and there is no simple string processing that's interoperable

   bhill: complexity is not only c14n but also reference model

   <klanz2> e.g. simple string functions that are interoperable

   <fjh> klanz: provide simple transforms to make it easy to say remove
   all prefixes, ignore whitespace etc

   <fjh> simplicity and interoperability both required

   <klanz2> secure primitives

   <klanz2> consider indempotent primitives

   <fjh> action klanz2 provide proposal on list regarding transform

   <trackbot> Created ACTION-51 - Provide proposal on list regarding
   transform primitives [on Konrad Lanz - due 2008-09-02].

V.next discussions


   <klanz2> (Off-Topic) Issue: Line Length in Servers, some servers run
   out of memory or become slow with "one line" XML ...

   sean: not convinced we really need to use processing instructions; most
   of the examples seemed not to actually justify that

   <klanz2> smullan: The is only case where Schema beraks ??? So PIs not

   kelvin: the PI proposal was mostly motivated by not just wanting to
   break dsig, but also by not wanting to modify document schemas
   ... so you can hash things without going back and forward in the stream

   <klanz2> +1 to Kelvin that was teh original intention by suggesting PIs

   kelvin: so we can put stuff into any existing document
   ... provide hints to dsig verifier early on

   <klanz2> kelvin: PIs help not to disrupt existing Implementations and
   their schemas ... ??

   <klanz2> tlr: PIs are signed

   <fjh> tlr: pi are included in signature hashes, so adding pis will
   change signature result

   <klanz2> Well it will not help to update existing signatures

   fjh: the concern is about a use case where you'd retrofit PIs

   <klanz2> but new ones will be fine

   fjh: which won't work

   kelvin: oh, right

   sean: in proposals that I saw back at the workshop, and all that --
   there were workarounds for where the signature is located in the

   <klanz2> smullan: PIs are a workaround ...

   sean: forward and backward references, and all that
   ... always a problem one way or the other
   ... don't like sticking things into document to indicate where refs are
   before you know where they are

   <klanz2> smullan: estetics are not good with hints ...

   sean: detached sig seems to solve the location-type signature issue

   <fjh> sean: use detached sigantures as solution

   fjh: well, you *can* use detached signatures

   sean: I'm asking about a requirement

   <klanz2> klanz: Some when a detached signature is sent off, so do you
   put it ahead or after the document ... sigining and verification are
   wrt. this ..

   <klanz2> ... opposite

   tlr: so I'm hearing a question whether there is a requirement for
   one-pass processing of enveloped (or enveloping) signatures, since
   detached signatures can deal with things just fine

   sean: detached signature is when the signature is separate from the
   signed material

   <klanz2> external detached signature

   <klanz2> sure the relationship of enveloped/detached/enveloping/
   qualifies the reference and not the signature

   scantor: it's the reference that matters, not so much the signature

   bal: all he's saying is that you can imagine a scenario where if I sign
   a document, embed a signature, maybe also to an external doc, ...

   <klanz2> that's the web architecture ...

   bal: so I have two separate references in SignedInfo, one to enclosing
   doc, one to external document
   ... .then???

   fjh: so, then what?

   bal: just that an individual xml signature blob could contain both
   references that are enveloped, or references that are external

   <klanz2> so PIs may after all not be so ugly

   fjh: I heard something different from Sean, but that you might want to
   always use detached

   <klanz2> as they allow to provide hints on a ds:Reference level

   sean: yes

   bal: there are other technologies that work that way ...
   ... some of the push-back that we had was desire to carry signatures
   along with content ...

   fjh: note counter signatures and the like, where it can get complex

   bal: you cannot always wrap things
   ... that's why we have enveloped signatures in the first place

   sean: suspected there were good answers to why we shouldn't do that
   ... not sure I like some of these proposals...

   klanz: only hope not to put things between hints is to put data inside
   ... you could also use an element to wrap things ...

   fjh: entities trouble?

   klanz: as soon as you have references to arbitrary places, you always
   have the problem
   ... except you cut things in pieces

   <klanz2> tear xmldsig apart, keys, algos and references at the
   beginning of document .... digest values/signature values at the end.

   <fjh> this is what i suggested before, e.g. xml:hash

   <klanz2> althoug it's neat somehow

   <klanz2> its like a sign-this attibute ...

   <klanz2> we'll why not support both PIs and the attribute ... well ...
   I don't know

Issues List

   <smullan> Discussion was useful , I understand why detached signatures
   are not always the right solution for a minimal profile

   <klanz2> xml:hash-this could also be of type xs:ID so it can be
   referenced ;-)

   <fjh> actions

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

   <scribe> ACTION: klanz to attempt summarizing recent discussions as
   input for design document [recorded in

   <trackbot> Created ACTION-52 - Attempt summarizing recent discussions
   as input for design document [on Konrad Lanz - due 2008-09-02].

   <klanz2> thanks everybody

   <klanz2> bye

   <bal> bye

Summary of Action Items

   [NEW] ACTION: bhill to edit the best practices document [recorded in
   [NEW] ACTION: klanz to attempt summarizing recent discussions as input
   for design document [recorded in
   [NEW] ACTION: pratik to draft a strawman for alternative to xpath
   transform [recorded in
   [NEW] ACTION: thomas to add
   021.html to c14n 1.1 errata page [recorded in
   [NEW] ACTION: tlr to put the link for the proposed errata [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [56]scribe.perl version 1.133
    ([57]CVS log)
    $Date: 2008/09/02 14:11:57 $


   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0048.html
   3. http://www.w3.org/2008/08/26-xmlsec-irc
   4. http://www.w3.org/2008/08/26-xmlsec-minutes.html#agenda
   5. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item01
   6. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item03
   7. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item04
   8. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item05
   9. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item06
  10. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item07
  11. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item07b
  12. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item08
  13. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item09
  14. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item10
  15. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item11
  16. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item12
  17. http://www.w3.org/2008/08/26-xmlsec-minutes.html#item13
  18. http://www.w3.org/2008/08/26-xmlsec-minutes.html#ActionSummary
  19. http://www.w3.org/2008/10/TPAC/Overview.html
  20. http://www.w3.org/2008/10/TPAC/Schedule
  21. http://www.w3.org/2002/09/wbs/42458/xmlsecearly2009/
  22. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html
  23. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html
  24. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0042.html
  25. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0042.html
  26. http://lists.w3.org/Archives/Member/member-xmlsec/2008Aug/0010.html
  27. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.html
  28. http://www.w3.org/TR/xml-c14n11/#Example-DocSubsetsXMLAttrs
  29. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.html
  30. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action01
  31. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.html
  32. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action02
  33. http://www.w3.org/2001/11/StdLiaison#OASIS
  34. http://www.w3.org/2001/11/StdLiaison#OASIS
  35. http://www.w3.org/2008/xmlsec/track/actions/25
  36. http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/
  37. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action03
  38. http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/Overview.html
  39. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/att-0040/00-part
  40. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0042.html
  41. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0045.html
  42. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action04
  43. http://www.w3.org/2007/xmlsec/ws/papers/12-mishra-oracle/#page=3
  44. http://spex.sourceforge.net/
  45. http://www.cs.umd.edu/projects/xsq/
  46. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0047.html
  47. http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0031.html
  48. http://www.w3.org/2008/xmlsec/actions-open.html
  49. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action05
  50. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action03
  51. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action05
  52. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action04
  53. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.html
  54. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action01
  55. http://www.w3.org/2008/08/26-xmlsec-minutes.html#action02
  56. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  57. http://dev.w3.org/cvsweb/2002/scribe/

Thomas Roessler, W3C  <tlr@w3.org>
Received on Tuesday, 2 September 2008 14:13:23 UTC

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