See also: IRC log
<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
<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.
<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?
<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
<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
<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].
<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
<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