XML Security Working Group Teleconference

03 Aug 2010


See also: IRC log


Frederick_Hirsch, Shivaram_Mysore, Cynthia_Martin, Chris_Solc, Gerald_Edgar, Magnus, Nyström, Ed_Simon, Brian_LaMacchia, Scott_Cantor, Hal_Lockhart, Bruce_Rich, ThomasRoessler


<trackbot> Date: 03 August 2010

<scribe> Scribe: Gerald-E

<fjh> ScribeNick: Gerald-E


<fjh> TPAC registration open (XML Security F2F 1-2 November 2010)

<fjh> Please complete WG attendance questionnaire as well as TPAC registration if attending in person:

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Jul/0001.html

fjh: Plan now, to get the payment in on time and get a hotel

Minutes approval

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Jul/att-0016/minutes-2010-07-27.html

<fjh> Proposed RESOLUTION: Minutes from 27 July 2010 approved

RESOLUTION: Minutes from 27 July 2010 approved


Thomas: ECC status
... a round of discussion, but no resolution at this time


fjh: a few questions: test cases and participation

the quesiton is to create the test cases for interop, it takes a few days.

Test for derived keys

fjh: it is better to have more interop and confidence before entering CR. We do not want to mark essential or important features as at risk, and would prefer to not have a long CR period. Shorter would keep up momentum. If we drop essential features we go back to Last Call.
... we are trying to juggle how interop will play out

tlr: it would be good to ping a few more people to have more participation
... there are a few more parties that may be able to particpate

fjh: they may not be interested in the working group, but they may participate in the interop

tlr: as we enter into CR the greater the participation the more implementations we would have

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Jul/0014.html

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Aug/0002.html

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Aug/0003.html

fjh: some messages from sean.
... Sean is doing Java, Scott is doing C++
... it would be good to be in CR when we have the face to face
... we can do the interop remotely.

Last call comments

<fjh> Proposal for LC-2387 resolution

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jun/0003.html

<fjh> ACTION-585?

<trackbot> ACTION-585 -- Thomas Roessler to review proposal for LC-2387 -- due 2010-07-31 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/585

fjh: can Thomas close this before next week?

Cannoical XML 2.0

<fjh> ACTION-612?

<trackbot> ACTION-612 -- Scott Cantor to extend section 3 of C14N2 to deal with options related to ACTON-594 proposal -- due 2010-08-03 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/612

<fjh> ACTION-594?

<trackbot> ACTION-594 -- Scott Cantor to write detailed proposal, not including xsi:type, based on http://lists.w3.org/Archives/Public/public-xmlsec/2010Jun/0020.html -- due 2010-06-22 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/594

<fjh> action to C14N2 for qnameAware parameter

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0027.html

fjh: there is a proposal on the list

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

fjh: scott had some suggestions for C14NN2

scott: he submitted all the tags

fjh: only Pratik needs to look at this

Scott: we need consistancy

<fjh> next step is for Pratik to look at this

XML Signature 2.0

<fjh> ISSUE-183?

<trackbot> ISSUE-183 -- Constrain 2.0 SignedInfo canonicalization choice for 2.0 model? -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/183

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0026.html

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

<fjh> "All 2.0 mode signatures MUST use Canonicalization algorithms designated as compatible with 2.0 mode. Section 6.8 ( "2.0 Mode" Canonicalization Algorithms) lists such compatible algorithms as of publication.

fjh: to change the text slightly

<fjh> change MUST to must since common sense

<fjh> Canonicalization in this step MUST use a canonicalization algorithm designated as compatible with 2.0 mode for signatures created in 2.0 mode. This 2.0 mode canonicalization algorithm SHOULD be the same as used for Reference canonicalization."

fjh: there is another change for signed info
... for 2.0 mode you must use a compatable algorithm
... do people agree?

<fjh> proposed RESOLUTION: accept change proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0001.html with #1 having lower case must

RESOLUTION: accept change proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0001.html with #1 having lower case must

Schema update

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jun/0013.html

fjh: a number of calls on changing the schema
... a new URI for the new schema

<fjh> ACTION-600?

<trackbot> ACTION-600 -- Thomas Roessler to draft proposal of how update to 1.0 schema will work practically for existing implementations -- due 2010-07-31 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/600

fjh: the new schema would be corrected.

tlr: the schema referenced by the 1.1 recommendation

scott: the schema is broken, it is not usable

<scantor> 1.0 namespace schema

<scantor> X509IssuerSerial

<scantor> is unusable

<fjh> 1.0 namespace schema is broken, so we need to fix that schema

scott: X.509 issuer serial is not usable

<fjh> we need to document how we will do this, the steps involved

scott: how can we leave this out there when it is broken?
... the type of that element is an integer (serial number child element)

<fjh> type of element is integer and too short for serial numbers, solution is to change to string

scott: the solution is to change that to string
... at the time 1.1 was in last call

fjh: we need to write this down and be clear

Scott: you can not validate it

fjh: we need to act quickly so people can review it


<fjh> ISSUE-140?

<trackbot> ISSUE-140 -- Clarify how XPath is interpreted relative to entire document and ds:Reference -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/140

<fjh> related to id proposal

<fjh> scantor - keep xpaths absolute, hence id proposal

<fjh> next step add text clarifying that xpaths always absolute, id proposal

<fjh> ISSUE-152?

<trackbot> ISSUE-152 -- Add pratik as author to xpath subset document if produced by ws-ra -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/152

<fjh> ISSUE-152 closed

<trackbot> ISSUE-152 Add pratik as author to xpath subset document if produced by ws-ra closed

<fjh> ISSUE-160?

<trackbot> ISSUE-160 -- Define URI for Canonical XML 2.0, add section to Signature 2.0 defining Canonical XML 2.0 -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/160

<fjh> need to check in both docs

<fjh> ISSUE-200?

<trackbot> ISSUE-200 -- Which references are normative vs informative for C14N2 -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/200

<fjh> need to review

<fjh> ISSUE-197?

<trackbot> ISSUE-197 -- Define parameter sets for C14N2 -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/197

<fjh> ISSUE-202?

<trackbot> ISSUE-202 -- How to define parameter sets in document, vs conformance criteria -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/202

<fjh> ISSUE-197: included in ISSUE-202

<trackbot> ISSUE-197 Define parameter sets for C14N2 notes added

<fjh> ISSUE-197 closed

<trackbot> ISSUE-197 Define parameter sets for C14N2 closed

<fjh> ISSUE-206?

<trackbot> ISSUE-206 -- For c14n20 profile - clarify that conformance implies support, but also changes to xml or what must be explicitly specififed -- open

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/206

fjh: should we have a conformance section?
... to outline different profiles

<Cynthia> How about a separte conformance document? It would be easier to update.

scott: there was talk about profiles for C14N for the conformance requirement
... if this is part of a standard, changing the document would be more difficult.
... if there is a specific section it is easier to use

fjh: Pratik added a conformance section

<fjh> no he didn't , just checked

Scott: do we want to call out specific options?

<fjh> Need to clarify whether legacy is optional, 2.0 mandatory, also consider different profiles

<Cynthia> Yes, you need that for real interoperability

fjh: legacy vrs 2.0 would belong in the recommendation itself
... we should be clear about this

Cynthia: interest in interoperability in ECC, for keys and how we are testing it

<Cynthia> For now, add it to the current document

RESOLUTION: a conformance section will be added to the XML Signature 2.0 document

<fjh> This section should clarify implementation requirements for legacy mode and 2.0 mode at a minimum

<Cynthia> I can check it

fjh: to check normative vs informative

<fjh> ACTION: Cynthia to review C14N2 references, ISSUE-200 [recorded in http://www.w3.org/2010/08/03-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-620 - Review C14N2 references, ISSUE-200 [on Cynthia Martin - due 2010-08-10].

Publication Plan

<fjh> Publish FPWD of XPath profile, updated WD of Canonical XML 2.0 and updated WD of XML Signature 2.0 at end of August?

<fjh> Edits complete by 10th, agree to publish on 17th, publish on 24th? Also publish update to "XML Security RELAX NG Schemas" and Best Practices at this time?

fjh: to publish an update to Relax-NG

<fjh> http://www.w3.org/2008/xmlsec/wiki/Roadmap#XML_Security_2.0

fjh: the schedule is tight

Magic Signatures

<fjh> Ed has reviewed

Ed: he took a look at this
... if you want to sign XML, you have to have base64 to avoid C14N
... there are limitations, it is not a broad a scope as XML-Signature

Hal: the claims are overblown
... you can profile signatures, and signatures cover non-XML

ed: we can define a profile to do something similar to magic signature

<fjh> can anyone compose editorial feedback on the introduction of magic signatures?

<fjh> maybe I have an action to do that ...

<Cynthia> I would prefer that you (the WG/W3C) do that officially

ed: there are statments about XML in the magic signature paper that are incorrect

fjh: this is of some concern

<fjh> hal is drafting correction

tlr: is this another way to deal with signatures we need to address?

fjh: their goal seems to be avoiding XML

<Cynthia> I agree, they are not interested in XML, we don't really want to engage them

Ed: is this from Google?

Scott: others have worked on it

<Cynthia> Yes, that is why some groups are interested in this work

Scott: Google engineers were the source of this

Bal: they are interested in a version of CMS for XML or JSON

<Cynthia> I believe this is related, I had heard the original work from CISCO also

tlr: there is interest in notarized signatures

fjh: is this a request for effeciency?

Scott: they want to push this to client side javascript
... to use JSON not XML

<Cynthia> Is this the topic: http://mapixcms.org/

Scott: a lossy mapping,

fjh: to use DOM

Hal: there are issues regarding client side signing

<fjh> are there client side xml signature libraries available to javascript, open source dependency?

bal: are there client side scripts? are there hooks in the forthcoming standards?

fjh: they need something relatively simple

bal: they want javascript

<Cynthia> It's also for systems like Android OS (OMA- http://www.openmobilealliance.org/)

bal: there are issues regarding client side key management

tlr: some low-level discussion about a possible incubator for this (client side crypto APIs) targeting javascript

<fjh> if interested in client side crypto APIs for javascript contact Thomas

Cynthia: there is interest in putting this on small platforms

Summary of Action Items

[NEW] ACTION: Cynthia to review C14N2 references, ISSUE-200 [recorded in http://www.w3.org/2010/08/03-xmlsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/08/10 15:07:33 $