- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 2 Sep 2008 16:12:45 +0200
- To: public-xmlsec@w3.org
Minutes from our meeting on 2008-08-26 were approved and are
available online here:
http://www.w3.org/2008/08/26-xmlsec-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
XML Security Working Group Teleconference
26 Aug 2008
[2]Agenda
See also: [3]IRC log
Attendees
Present
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)
Regrets
Juan Carlos Cruellas, Rob Miller
Chair
Frederick Hirsch
Scribe
Subramanian Chidambaram
Contents
* [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
Administrivia
<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
<fjh>
[22]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html
klanz2: Orientation meeting on Xades in Plugfest
<klanz2>
[23]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html
<klanz2> XAdES Plugtest
XProc processing model
<fjh>
[24]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0042.html
<fjh>
[25]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0042.html
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
NIST
<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:
[26]http://lists.w3.org/Archives/Member/member-xmlsec/2008Aug/0010.html
Minutes Approval
RESOLUTION: August 19th minutes approved
C14N11 errata
<tlr> (strictly, as a proposed erratum)
<fjh>
[27]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0
021.html
<fjh> [28]http://www.w3.org/TR/xml-c14n11/#Example-DocSubsetsXMLAttrs
<bal> seems fine to me
<tlr> ACTION: thomas to add
[29]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0
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
[31]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0
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
closed
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
introduction
<tlr> Getting Brad CVS access is all setup
<scribe> ACTION: bhill to edit the best practices document [recorded in
[37]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-49 - Edit the best practices document [on
Bradley Hill - due 2008-09-02].
Usecases and requirements
<fjh> Please review template at
[38]http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/Overview.html
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
Nodesets
<fjh>
[39]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/att-0040/
00-part
fjh: There was an conversation started by pratik
pratik: xml signature, we have requirements to sign parts of the
document
... 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
<fjh>
[40]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0042.html
<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
<fjh>
[41]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0045.html
<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
c14n
<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
all
<scribe> ACTION: pratik to draft a strawman for alternative to xpath
transform [recorded in
[42]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-50 - Draft a strawman for alternative to
xpath transform [on Pratik Datta - due 2008-09-02].
<klanz2>
[43]http://www.w3.org/2007/xmlsec/ws/papers/12-mishra-oracle/#page=3
<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,
so...?
<tlr> pratik: they don't work very well when xpath expressions go
backwards
<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
<fjh>
[46]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0047.html
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
primitives
<trackbot> Created ACTION-51 - Provide proposal on list regarding
transform primitives [on Konrad Lanz - due 2008-09-02].
V.next discussions
<fjh>
[47]http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0031.html
<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
needed??
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
document
<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
SignedInfo
... 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
[49]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action05]
<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
[50]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action03]
[NEW] ACTION: klanz to attempt summarizing recent discussions as input
for design document [recorded in
[51]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action05]
[NEW] ACTION: pratik to draft a strawman for alternative to xpath
transform [recorded in
[52]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action04]
[NEW] ACTION: thomas to add
[53]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0
021.html to c14n 1.1 errata page [recorded in
[54]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action01]
[NEW] ACTION: tlr to put the link for the proposed errata [recorded in
[55]http://www.w3.org/2008/08/26-xmlsec-minutes.html#action02]
[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 $
References
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