XML Security Specifications Maintenance Working Group Teleconference
11 Dec 2007

<fhirsch3> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Dec/0011.html

TOPIC; Meetings cancelled Dec 25 and Jan 1

There is a meeting Dec 18

<tlr> Next meeting 18 Dec, skip two weeks, resume Jan 8.

WAF Access Material

Hal will review WAF document

<tlr> it is recorded in last meeting's minutes...

Minutes approval

<tlr> http://www.w3.org/2007/11/04-xmlsec-minutes

RESOLUTION: Minutes from Dec 4 approved

<tlr> http://www.w3.org/2007/12/04-xmlsec-minutes-public

C14N draft

Frederick wants people to review the doc as a whole

C14N wants to go to PR in January

Thomas says things looks OK but would like 2nd pair of eyes to look at C14N editor's draft

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Dec/0008.html

Comments should be shared by next week.

Thomas has sent a request for a redline; will get back to us when he hears a response

Interop and implementations

<tlr> http://www.w3.org/2007/xmlsec/interop/xmldsig/c14n11/report.html

<tlr> not yet the dsig stuff, just c14n

TLR's implementation report in link above

<tlr> will do dsig shortly

Frederick asks why signatures Sean mentioned are different than in implementation report

(e.g. defCan-1)

tlr: several participants do not produce c14n as standalone file

<fhirsch3> http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Dec/0002.html

tlr: we have issue with 3 tests (tlr please list)

The WG discussed specifics of interop tests and participant status, see member confidential minutes.

<klanz2> I produce the template now

<fhirsch3> 103 is new test case added by Sun

<fhirsch3> http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Nov/0014.html

<fhirsch3> This implementation report is limited to criteria for C14n11

<fhirsch3> will be additional report for Signature etc soon

The table (see link) corresponds to the exit criteria for c14n 1.1; tlr will look at rest of work very soon

<fhirsch3> Konrad is updating template now for 103

2 things should happen: more green in top few rows and show test cases to XML Core to make sure they are satisfied

no need for table to be perfect in order to show to XML Core; table is member-confidential

The WG discussed plans for completing interop tests, see member confidential minutes.

tlr: we should have a collective look at 3-103 because it is a double ".."

Bruce: some return CR-LF so there may be a canonicalization issue or simply not posting it in binary

<fhirsch3> into CVS

Konrad: CVS does line break modifications when posting.

<fhirsch3> should be only LF (unix style)

TLR: ran a command line test which suggest the original material was posted correctly

<tlr> zkwYFWagoDX5nvwATyMGu8gcITc=

<tlr> ACTION: tlr to fix CR/LF issue for test case 103 [recorded in http://www.w3.org/2007/12/11-xmlsec-minutes.html#action01]

<trackbot-ng> Created ACTION-121 - Fix CR/LF issue for test case 103 [on Thomas Roessler - due 2007-12-18].

problem might be on check out, not check in

TLR will look into the issue

defCan-1

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Dec/0004.html

<klanz2> Testcase ...spec3-103 referes to xml-base-c14n11... instead of xmlbase-c14n11...

Various participants indicated they would check in material, see member confidential minutes.

FH: Sean's notes re tests; has anyone responded or looked at his email?

<fhirsch3> http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Nov/0014.html

<fhirsch3> dname cases - not all will do these cases. (last week's minutes)

TLR: Went through DN cases in last meeting; what kind of tests we need.

<fhirsch3> dname cases may not be essential for exit criteria, need addtl review

FH: Did people review Sean's work?

TLR found a few inconsistencies and will change things in CVS accordingly. Will likely flush out more inconsistencies in his upcoming work.

Konrad: Found a few things to fix and will send email.

XML Signature

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Nov/0027.html

<fhirsch3> Question on namespace document for 2004, should in addition to link to RFC the namespace document also include text/link to draft that will eventually superscede the rfc

<fhirsch3> draft http://www.ietf.org/internet-drafts/draft-eastlake-additional-xmlsec-uris-00.txt

<fhirsch3> rfc 4051 http://www.ietf.org/rfc/rfc4051.txt

RFC 4051 by D. Eastlake is a list of namespaces for algorithms

TLR says he is OK with adding link; FH suggests pointer from old RFC to new draft

<fhirsch3> Frederick suggests that in namespace document for older namespace which refers to RFC 4051, also provide link to new draft

Chartering

<tlr> http://lists.w3.org/Archives/Public/public-xmlsec-discuss/2007Dec/0001.html

FH: One comment about derived keys.

tlr: Magnus' proposal to extend ds:KeyInfo element

fh: actually alternative to KeyInfo

Hal: first reaction is this is special case of something more general

<tlr> ACTION-121 done

<tlr> I believe to have fixed the binary issue for the output files

<fhirsch3> hal: add requirement for derived key without necessarily now adopting specific solution, consider WSS security token references etc

<fhirsch3> hal: do not be so specific

<fhirsch3> +1 to hal

<fhirsch3> ed: remove keyinfo from signature spec, put in own spec

<hal> derived key proposal seems like a special case

tlr: +1 to not putting anything specific in charter
... one chartering relevant question is whether we need to open xml encryption to accomodate this request

<hal> agree that requirement for derived key support is potentially a good requiremnt

fh: we should be ready to change XML Encryption in case our work with XML Signature requires it.

tlr: additional deliverable to update XML Encryption as changes to XML Signature require it.

<hal> perhaps should consider generally if functionality built on sig and enc (e.g. WSS) should be encorporated into base specs

<hal> the point is to make an explicit decision

+1 to Hal

<pdatta> +2 to Hal

<fhirsch3> +1 to Hal

<shivaram> +1 to Hal

tlr: may need a relatively broad mandate to deal with encryption

fh: the more we bite off, the more we need to chew (paraphrased)

<tlr> ACTION: hal to propose concrete edit to proposed charter to deal with encryption / derived specs [recorded in http://www.w3.org/2007/12/11-xmlsec-minutes.html#action02]

<trackbot-ng> Created ACTION-122 - Propose concrete edit to proposed charter to deal with encryption / derived specs [on Hal Lockhart - due 2007-12-18].

tlr: this is the time for informal feedback which is encouraged to help when it is formal feedback time

<klanz2> will do ...

Hal: specs that come to mind are DSS

<shivaram> KeyInfo is also used in XKMS

<fhirsch3> BSP

Yes, XAdES

<klanz2> FYI: http://www.etsi.org/plugtests/XAdES/XAdES.htm

Best Practices

Hal: Saw best practices as long term work

Action Item Review

ACTION-74 continued

ACTION-74 open

<tlr> ACTION-74?

<trackbot-ng> ACTION-74 -- Thomas Roessler to update Acknowledgements section in XML SIgnature 2nd edition -- due 2007-10-09 -- OPEN

<trackbot-ng> http://www.w3.org/2007/xmlsec/Group/track/actions/74

<tlr> ACTION-105?

<trackbot-ng> ACTION-105 -- Frederick Hirsch to start issues list for best practices -- due 2007-10-30 -- OPEN

<trackbot-ng> http://www.w3.org/2007/xmlsec/Group/track/actions/105

ACTION-105 closed

<trackbot-ng> ACTION-105 Start issues list for best practices closed

<tlr> ta-dah!

<tlr> ACTION-112 open

ACTION-112 open

<tlr> ACTION-112?

<trackbot-ng> ACTION-112 -- Thomas Roessler to prepare interop report template -- due 2007-11-15 -- OPEN

<trackbot-ng> http://www.w3.org/2007/xmlsec/Group/track/actions/112

<hal> leaving for ws-fed call - see you next week

ACTION-115 open

ACTION-116 closed

<trackbot-ng> ACTION-116 Remind Donald to review XML Signature and Encryption home pages for accuracy closed

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Dec/0012.html

ACTION-120 closed

<trackbot-ng> ACTION-120 Rename test cases as proposed closed

<fhirsch3> http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Dec/0001.html

Decryption Transform

tlr: Decryption Transform is currently a Recommendation, could change current draft into note or just leave it as it is as we have no implementation experience

Pratik: We have an implementation of the Decryption Transform

<fhirsch3> Choices are (1) not deliver any Decryption Transform changes, e.g. Rec stays same. Current expectation (2) deliver Note with changes to date (3) additional work to deliver more complete result

<fhirsch3> Issue with #2 is that it can be misleading since incomplete change

<fhirsch3> issue with #2 and #3 not enough implementations

Pratik: changes to canonicalization would affect Decryption Transform

tlr: one needs two interoperable implementations for something to go to Recommendation status
... no point if we are not going to have a second implementation

Konrad: not opposed to keeping Decryption Transform on stack in case we want to do something with it

tlr: might cause addition work for patent attorneys

fh: Pratik, do you know of other implementations?

Pratik: will try to find out.

Line Endings

tlr: use -A to update file to UNIX line endings in CVS

<fhirsch3> "cvs update -A"

Konrad: will get back within 12 hours