XML Security Working Group Teleconference

19 Feb 2013


See also: IRC log


Frederick_Hirsch, Hal_Lockhart, Thomas_Roessler, Gerald_Edgar, Jim_Dovey, Pratik_Datta


<trackbot> Date: 19 February 2013

<scribe> ScribeNick: fjh

Administrative: Agenda review, Announcements

Charter extended to 30 April, https://lists.w3.org/Archives/Member/chairs/2013JanMar/0042.html

add to agenda discussion of charter and maintenance etc

Minutes Approval

Approve minutes from 8 January 2013


RESOLUTION: Minutes from 8 January 2013 are approved.

Canonical XML 2.0

jdovey: work for Kobo, write e reading software, wrote new ePub 3 engine from scratch
... wanted to include xml signature and encryption, needed canonicalization
... however due to limitations only use streaming parser, e.g original ipad, so found c14N2, wrote own
... used test documents from this group and ran unit tests
... published Objective C code, XML tree library including SAX parser


jdovey: implementing AES-GCM, found open source implementation
... github link has page with links to various parts of implementation
... only part that is complete and fully tested is C14N2
... haven't done update since late October, so have those tests changed
... Objective C implementation has now been deferred to C++ implementation in readium

fjh: http://readium.org/
... http://readium.github.org/

jdovey: c14n2 is not in there yet
... plan to have announcement next week
... should be straight port of objective c version
... can focus on the C++ version if that helps C14N2 get to Rec, unless Objective C version is adequate
... guidance on preference would be welcome

fjh: Readium is reference implementation for epub 3 and having c14n2 in there is an important step

jdovey: yes, real commercially deployable solution

pdatta: from Oracle, have been working on 2.0 from beginning, have made implementation of 2.0
... questions about your implementation
... one issue with C14N was problem with node set and XPath, have you been working with XPath and have you had any issues with this

jdovey: I worked top down from C14N2 so minimal work with XPath but it does handle attributes might contain XPath content types
... have not implemented streaming XPath implementation
... use Sax parser and a number of states
... using regular expressions to work through XPath

pdatta: how much did you do

jdovey: signature parsed by library are complete, algorithms are there, have XPath implementation
... but wrapper for libxml
... do not have digital signatures or encryption at this point

pdatta: why do you need C14N if not doing signatures?

jdovey: signature and encryption not there yet, but C14N was a requirement, so did it first as it is required
... started at bottom
... worked on this library for 2-3 weeks, then switched to C++
... worked on signature and encryption, but saw that needed C14N first

pdatta: so preparing for doing signature/encryption later on

jdovey: yes
... reason I didn't use xmlsec open source, or Java, reason needed for lightweight content protection spec, needed another way to locate encryption key
... java was out for iphone
... xmlsec library was C function pointers everywhere, making it hard to extend so started from scratch

tlr: thanks Jim for explaining this
... regarding reference implementation for ePub 3 - to what extent is it requiring XML Security specification?

jdovey: epub 3 open container format version 3 specifies that publication container can contain meta information in XML files, encrypting content using XML Encryption
... example showing it
... adds adobe obfuscation as well
... for fonts
... if you are going to digitally sign or encrypt it references XML Security

tlr: allows use of any canonicalization algorithm

jdovey: epub 3 does not mention canonicalization at all

fjh: From the conference last week I see ePub 3 will be going forward and used despite some issues, and we can expect additional revisions
... Readium is a reference implementation that will receive a lot of attention
... thus the implementation from Jim should be real and receive exposure, perhaps Pratik can say more about the status of his implementation
... tradeoff with going to Rec - benefit to allow normative references to it, also IPR protection. However need to make sure it is real

hal: is streaming required

jdovey: no, but needed to conserve memory and make e readers work properly

hal: protocols are different than documents
... need to sell our management on this work
... reason for leaving it a note is that there are no strong motivation for original members to implement, but need to see real users

tlr: would like to frame the question
... have C14N2 spec, convinced that in certain scenarios it is superior to previous specs
... heard this from Jim
... case 1 - sufficient interest in use cases for 2.0 and sufficient use cases - chance will substitute for C14N going forward
... case 2 - have experimental and niche implementations, adds value to niche implementations; those implementers get no interoperability
... do not want to risk case on non-interoperability

fjh: we should not look at this from a negative point of view, if the Rec is visible it can be found and used, if not it won't be, self-fulfilling prophesy
... agree that in protocol space it may no longer have as much interest
... has use case in publishing industry

jdovey: has value in publishing in work flow even without signing and encryption

pdatta: streaming alone can be used in C14N even though documented
... I implemented C14N2 but not XML Signature 2.0 yet C14N2 is supposed to be used with XML Signature 2.0

tlr: not ready to take Signature 2.0 forward, so that means we should not move C14N2 forward

jdovey: using C14N2 has value without signature
... can create streaming parser that puts out clean output through the use of this spec
... value for epub3
... can use it to straighten out namespace etc
... C14N2 can be incredibly useful to us, to have very well defined target
... can more easily test implementations for interoperability
... find 2.0 C14N very useful

fjh: C14N2 does not explicitly require Signature 2.0, the algorithm is still defined, however the spec does include how to integrate with Signature 2.0

hal: not convinced we need it

jdovey: can be useful when storing data in a data base, with streaming can write into database in clean manner

fjh: sounds like a value here is namespace management
... Thank you Jim for joining, this has been a good discussion, we need to discuss more and get more input.


tlr: have been discussing with fjh about rechartering this working group
... might recharter to maintenance mode, to deal with errata, security issues and minor editing
... baseline for 1.1 and 1.0
... need to decide regarding 2.0, could consider frozen
... and recharter again for 2.0
... or if we think we are at brink of progress for 2.0, could recharter to deal with 1.1. maintenance, but could also look at implementer feedback and support for 2.0 and consider moving them forward
... this could allow moving it forward if is possible
... draft currently assumes we were moving 2.0 to Note and only doing maintenance
... could consider changing
... feedback is welcome

Other Business

RESOLUTION: There will be no change to the algorithm URIs for AES Key Wrap with Padding in Appendix A of XML Encryption 1.1

please review proposed XML Security Algorithm Cross-Reference updates, http://lists.w3.org/Archives/Public/public-xmlsec/2013Feb/0001.html

Call for Consensus to publish 2.0 drafts as WG Notes: http://lists.w3.org/Archives/Public/public-xmlsec/2013Feb/0000.html

hal: jim the more you can do to indicate community support for 2.0 the better

tlr: +1

fjh: +1
... Will continue discussion next week, also agenda items that we did not get to.


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $