XML Security Working Group Teleconference
26 Aug 2008

<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> http://www.w3.org/2008/10/TPAC/Overview.html

<fjh> W3C Registration deadline 28 September

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

fjh: Please register for TPAC

<fjh> 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> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html

klanz2: Orientation meeting on Xades in Plugfest

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html

<klanz2> XAdES Plugtest

XProc processing model

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0042.html

<fjh> 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: 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> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.html

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

<bal> seems fine to me

<tlr> ACTION: thomas to add http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.html to c14n 1.1 errata page [recorded in http://www.w3.org/2008/08/26-xmlsec-minutes.html#action01 ]

<trackbot> Created ACTION-47 - Add http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jun/0021.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 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: 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: 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> http://www.w3.org/2008/xmlsec/track/actions/25

ACTION-35 closed

<trackbot> ACTION-35 Contact XML Processing WG closed

<tlr> 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 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 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> 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> 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> 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 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> 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> http://spex.sourceforge.net/

<tlr> 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> 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> 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> http://www.w3.org/2008/xmlsec/actions-open.html

<scribe> ACTION: klanz to attempt summarizing recent discussions as input for design document [recorded in 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