12:44:28 RRSAgent has joined #xmlsec 12:44:28 logging to http://www.w3.org/2007/05/02-xmlsec-irc 12:44:31 rrsagent, make this log public 12:44:39 Meeting: XML Security Spec Maint WG face-to-face 12:44:42 Date: 2007-05-02 12:44:59 Chair: Frederick 12:45:09 GregB has joined #xmlsec 12:45:13 rdmiller has joined #xmlsec 12:45:28 Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Apr/0014.html 12:46:13 fjh has joined #xmlsec 12:47:49 zakim, this will be xmlsec 12:47:49 ok, tlr; I see T&S_XMLSEC()8:00AM scheduled to start 47 minutes ago 12:47:54 zakim, who is on the phone? 12:47:54 T&S_XMLSEC()8:00AM has not yet started, tlr 12:47:55 On IRC I see fjh, rdmiller, GregB, RRSAgent, Zakim, tlr, trackbot-ng 12:48:23 zakim, code? 12:48:23 the conference code is 965732 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tlr 12:48:50 T&S_XMLSEC()8:00AM has now started 12:48:57 +[NRCC] 12:48:58 gregwhitehead has joined #xmlsec 12:49:25 klanz2 has joined #xmlsec 12:49:31 I'm here 12:49:59 ScribeNick: GregB 12:50:30 http://www.w3.org/2007/xmlsec/Group/Scribe-Instructions.html 12:52:29 + +1.613.726.aaaa 12:52:45 zakim, aaaa is EdSimon 12:52:45 +EdSimon; got it 12:52:53 grw has joined #xmlsec 12:53:44 ScribeNick: grw 12:54:25 zakim, NRCC has fjh, GregB grw, klanz2, rdmiller, tlr 12:54:25 +fjh, GregB, grw, klanz2, rdmiller, tlr; got it 12:54:29 zaki, who is on the phone? 12:54:47 zakim, who is on the phone? 12:54:47 On the phone I see [NRCC], EdSimon 12:54:48 [NRCC] has fjh, GregB, grw, klanz2, rdmiller, tlr 13:00:54 grw: it would be great to automate the scribe function with forms for each of the functions 13:01:58 TOPIC: Administrative 13:02:09 Ed has joined #xmlsec 13:02:29 zakim, nick Ed is EdSimon 13:02:29 ok, tlr, I now associate ed with EdSimon 13:02:56 Yes, Ed is Ed Simon 13:03:53 jcc has joined #xmlsec 13:06:53 sean has joined #xmlsec 13:08:37 hal has joined #xmlsec 13:09:21 PHB has joined #xmlsec 13:13:23 Members of the group introduced themselves 13:14:12 Regrets: Tony Nadalin 13:16:53 Present+ FrederickHirsch 13:17:01 Present+ KonradLanz 13:17:05 Present+ JuanCarlosCruellas 13:17:10 Present+ Phill Hallam-Baker 13:17:14 Present+ Greg Whitehead 13:17:21 Present+ Greg Berezowski 13:17:31 Present+ SeanMullen 13:17:34 Present+ DonEastlake 13:17:38 Present+ HalLokchart 13:17:41 Present+ RobMiller 13:17:44 Present+ ThomasRoessler 13:17:53 Present+ EdSimon 13:18:53 zakim, who is on the phone? 13:18:53 On the phone I see [NRCC], EdSimon 13:18:55 [NRCC] has fjh, GregB, grw, klanz2, rdmiller, tlr 13:22:25 s/HalLokchart/Hal Lockhart/ 13:22:52 Topic: approval of last meeting's minutes 13:22:59 TOPIC: Approval of 2007-04-17 telecon minutes 13:23:16 http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Apr/0008.html 13:23:19 approved 13:24:09 RESOLUTION: 2007-04-17 telecon minutes approved 13:24:23 TOPIC: Teleconference schedule 13:25:11 fjh: weekly Tuesdays 9-10 am Eastern, 6-7 am PT, 3pm 13:25:37 ... European 13:25:44 fjh: no call next week 13:26:35 TOPIC: F2F plans 13:27:01 fjh: will want to do a workshop at some point to solicit additional input for future work 13:27:25 fjh: also Joint Technical Plenary and AC Meetings Week, 5-10 November 2007, Cambridge MA 13:28:36 tlr: first two days working meetings, third day plenary, followed by more working meetings 13:29:15 tlr: we could plan on 1.5 days thu-fri 13:30:31 fjh: need a decision this week 13:31:06 fjh: this group chartered through the end of the year. ideally our work is done by november 13:31:40 http://www.w3.org/2002/09/wbs/34786/TPAC07/ 13:32:10 deastlak has joined #xmlsec 13:33:52 tlr: one of the outputs of this group will be a proposal for a charter for continued work 13:35:38 tlr: in preparation for second f2f need: call for participation, prepare agenda 13:35:58 tlr: second f2f = workshop 13:36:07 s/second f2f need/workshop/ 13:36:12 I agree with the November plans. 13:38:51 TOPIC: Agenda review 13:41:43 TOPIC: Introduction to W3C, W3C process and Tools [Thomas Roessler] 13:43:27 tlr: slides at http://www.w3.org/2007/xmlsec/w3c101 13:55:16 q+ to test this 13:55:34 q? 13:55:38 ack 13:55:45 ack fjh 13:55:45 fjh, you wanted to test this 13:56:50 if you are on the queue and muted, when acked are unmuted 14:03:26 On break now. 14:05:35 -EdSimon 14:18:00 test 14:22:17 +EdSimon 14:26:03 tlr has joined #xmlsec 14:32:10 fjh: starting again 14:35:11 ACTION: Frederick to update scribe instructions 14:35:12 Created ACTION-3 - Update scribe instructions [on Frederick Hirsch - due 2007-05-09]. 14:36:08 Tracker, actions? 14:37:53 klnaz2 has joined #xmlsec 14:41:35 Tracker for xmlsec is member-only visible 14:42:57 I'm not familiar with bugzilla 14:46:14 ACTION: fjh to provide instructions on using bugzilla 14:46:14 Sorry, couldn't find user - fjh 14:46:30 ACTION: Frederick to provide instructions on using bugzilla 14:46:30 Created ACTION-4 - Provide instructions on using bugzilla [on Frederick Hirsch - due 2007-05-09]. 14:46:41 ACTION: Thomas to teach tracker about common aliases 14:46:41 Created ACTION-5 - Teach tracker about common aliases [on Thomas Roessler - due 2007-05-09]. 14:48:47 TOPIC: Consensus 14:49:21 We would like to avoid reaching need for formal objection 14:53:11 Consensus is for "in the set", i.e. people in good standing. 14:54:00 Good standing based on attendance and delivering on deadlines. See Thomas slides. 14:55:00 PHB has joined #xmlsec 14:55:46 http://www.w3.org/2005/10/Process-20051014/policies.html#coi 14:56:14 please review conflict of interest policy, noted in the link above 14:56:28 grw: what is conflict of interest in the context of this group? 14:56:36 tlr: see process document for explanation of conflict of interest 14:57:29 TOPIC: Patent Policy 14:58:08 current patent practice link - http://www.w3.org/TR/2002/NOTE-patent-practice-20020124 14:58:30 tlr: XML Signature predates current patent policy 14:58:45 tlr: see patent policy transition procedure 14:59:50 Transition procedure link - http://www.w3.org/2004/02/05-pp-transition.html 15:00:44 rsalz has joined #xmlsec 15:03:00 TOPIC: Presentation: Overview of Canonical XML 1.1 and XPath essentials [Konrad Lanz] 15:06:31 No, I do not have the slides. 15:07:04 http://www.w3.org/2007/xmlsec/20070502-klanz-c14n.pdf 15:09:48 see also http://www.w3.org/TR/DSig-usage/ 15:10:22 XPointer used in URI, XPath Filter in Transform both allow getting document subset 15:15:32 fjh has joined #xmlsec 15:15:54 q+ to ask about syntactic vs semantic definition of same-doc reference 15:19:59 ACTION: konrad to share example for transform that depends on information beyond the transform input nodeset 15:19:59 Created ACTION-6 - Share example for transform that depends on information beyond the transform input nodeset [on Konrad Lanz - due 2007-05-09]. 15:23:54 slide 7 15:24:00 slide 8 15:24:43 slide 9 15:25:10 http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Feb/att-0013/C14N-diff.html 15:28:53 slide 10 15:30:11 slide 11 15:32:10 q- 15:33:50 grw: Is C14N11 needed for SIgnedInfo? 15:33:56 deastlak has joined #xmlsec 15:34:31 slide 12 (end) 15:34:39 Konrad: could use id on signed Info other than schema 15:35:01 q+ 15:37:03 juan-carlos: focus on current xml in current namespace 15:37:16 s/xml/xml attributes 15:37:21 s/xml/ 15:37:28 s/current/xml 15:38:22 old behavior is to inherit all xml: attributes 15:38:41 proposal to change that to not inherit by default 15:40:18 fjh: can we ask xml core to specify inheritance rules when new attributes defined? 15:40:48 hal: no, we can't count on that 15:41:35 ISSUE: C14N11 does not clearly define how new attributes in xml namespace are to be handled (as inheritable, non-inheritable, undefined) 15:42:43 klnaz2: raised this issue with xml core, but not solved there 15:43:08 +1 to Frederick 15:43:12 q? 15:43:36 PROPOSED: up on groups that define XML namespace attributes to tell whether simply inheritable or not 15:43:42 (by juan Carlos) 15:43:58 proposal is to propose sentence and give to XML Core, other attributes in xml namespace are non-inheritable by default 15:44:04 jcc: should be up to group defining xml attributes whether inheritable 15:44:11 q+ 15:44:27 q+ 15:44:28 jcc: should have a registry of attributes 15:44:46 klnaz2: maybe this is better for future work 15:44:56 q+ 15:45:08 q- phb 15:45:18 q+ hal 15:45:25 q+ to raise the issue of qname mess 15:45:40 q+ 15:46:31 hal: c14 doc should be explicit, don't include implict rules 15:47:16 q? 15:52:45 tlr: how is conformance affected by future additions that break a current algorithm 15:54:35 fjh: if c14 1.1 is to be compatible with 1.0 can we change the rules around xml: attribute inheritance 15:55:29 hal has joined #xmlsec 15:55:39 php: not relevant since you will never mix 1.0 and 1.1 (eg sign with 1.0 and verify with 1.1) 15:55:45 q+ 15:56:04 ie clear because you explicitly specify canonicalization method 15:56:22 deastlak: default should be not inheritable since you can always work around that, but not the reverse 15:57:17 deastlak: desireable not to have to rev canonicalization 15:57:22 deastlak: would be nice if inheritably could be determined syntactically 15:57:42 q? 15:57:45 ack tlr 15:57:53 deastlak: alternatively, could have some explicit indication of inheritability 15:58:03 ack fjh 15:58:07 ack deastlak 15:58:11 ack hal 15:58:23 hal: no way to anticipate future special cases 16:00:22 klanz2: could have an extensibility parameter but not a big fan of that 16:00:41 php: just ask xml core what default they prefer: inheritable or not 16:00:59 q+ 16:01:06 q+ hal 16:01:25 ack PHB 16:01:25 PHB, you wanted to raise the issue of qname mess 16:01:33 ack grw 16:02:41 greg whitehead: need to change from default of inheriting for xml namespace attributes 16:02:59 q+ 16:03:16 ... perhaps extensibiilty to indicate how handled as input to canon algorithm 16:03:17 ... perhaps extensibiilty to indicate how handled as input to canon algorithm 16:03:20 ... perhaps uri 16:03:55 ... diminishing returns depending on how far this goes 16:05:39 q? 16:05:48 ack 16:06:08 tlr: undefined behaviour leads to both security and interoperability issue 16:06:57 tlr: inheritance issued could be handled by a prefilter using existing extensibility points 16:07:06 s/issued/issue/ 16:07:35 q+ 16:07:40 q? 16:07:48 ack tlr 16:09:17 tlr: if you define a attribute that requires special processing, define a transform to do that processing 16:11:56 klnaz2: this won't work because transforms always refer back to the original document, changes apply to original 16:12:34 klnaz2: could do this only if we change the transform processing model to output a copy of input 16:16:03 ack tlr 16:19:48 proposal - for attributes in xml namespace, no listed in c14n 1.1, there will be no special processing 16:20:17 s/no listed/not listed 16:20:53 rationale - exceptional processing for future xml attributes can be handled by some mechanism without revving c14n (such as pre-processing) 16:23:03 fjh: proposes to propose this to xml core 16:23:26 fjh: also convey security concerns 16:24:16 security concern - with this proposal, security may be compromised if new attributes are defined that require special processing 16:24:33 for clarity suggest "no special processing' -> "no special process, that is, they will be treated as not inheritable" 16:24:41 q? 16:24:41 q? 16:24:42 q? 16:24:43 q? 16:24:43 q? 16:25:48 hal: alternative is to stop with an error if an unknown xml attribute is found 16:26:54 ack hal 16:26:56 ack fjh 16:26:58 tlr: this would prevent using existing extension points to handle special processing 16:27:09 tlr: c14n would have to revved in all cases 16:31:30 tlr: error proposal is safer, but has higher deployment cost 16:33:19 deastlak: fixed behavior best, not inherited a better default since you can always copy attributes as a workaround 16:33:34 deastlak: not desireable to keep revving c14n 16:35:44 http://www.w3.org/TR/C14N-issues/#S3 16:35:45 ed: prefers inherited to be default 16:38:39 Ed prefers inheritance, but wants to study this issue more, and also see examples of the arguments against inheritance 16:39:46 break 16:40:08 return at !:15 ET, about 1/2 hour 16:40:13 s/!/1 17:13:31 deastlak has joined #xmlsec 17:17:09 I'm back 17:18:40 Resuming meeting 17:21:22 ScribeNick: rdmiller 17:21:26 Scribe: RobMiller 17:21:50 sean has joined #xmlsec 17:22:40 TOPIC: XML 1.1 and C14N 17:22:56 slide 14 17:23:20 q+ 17:23:31 konrad: this means cannot sign xml 1.1 at all 17:23:42 q? 17:24:20 ... suggests looking an xml core archives 17:24:40 s/an/at 17:25:29 ack Ed 17:25:53 Ed: wondering about XPATH 2.0 17:27:14 klnaz2: Canonical XML is currently defined for XPath 1.0 and not XPath 2.0 17:29:27 Ed's point was whether XPath 2.0, though not defined in Canonical XML, might address or be of help in the issues re XPath 1.0 and XML 1.1 17:29:57 klanz2: canonization need not generate valid XML, is this a good decision. 17:30:56 slide 15 17:31:00 slide 16 17:31:06 slide 17 17:33:10 slide 19 17:34:21 slide 20 17:35:32 klanz2: namespace undelarations in xml 1.1 can cause issues in canonicalization 17:36:22 q+ 17:38:47 fjh: where is this applicable? 17:39:16 klnaz2: this applies to XML 1.1 and canonicalization 17:46:14 fjh: what are we trying to accomplish with this conversation right now? this is a discussion for future charterting. 17:48:38 fjh: will submit a comment to propose wording be added to C14N11 that C14N11 is applicable only to XML 1.0 and XPath 1.0 17:49:16 slide 23 17:51:14 don, http://www.w3.org/2007/xmlsec/20070502-klanz-c14n.pdf 17:51:42 q+ 17:53:09 fjh: did we address the qnamr issue properly? 17:53:29 s/qnamr/qname 17:53:29 hlockhar has joined #xmlsec 17:54:05 tlr: not using qnames is a good topic for best practices. 17:58:00 ACTION: PHB to propose a change to C14N11 to handle the qname issue due 5/3/2007 17:58:00 Sorry, couldn't find user - PHB 17:59:52 ACTION: Phil to propose a change to C14N11 to handle the qname issue due 5/3/2007 17:59:52 Sorry, couldn't find user - Phil 18:00:45 TOPIC: XML Signature Syntax and Processing - Overview and Proposed Changes [Thomas Roessler] 18:05:01 are there slides? 18:05:03 q? 18:06:02 tlr: The reference processing model should use C14N 1.0 as a default. 18:08:24 tlr: the transform used for signing should be explicitly defined. 18:09:38 http://www.w3.org/2007/xmlsec/20070502-tlr-dsigchange.pdf 18:09:43 q 18:09:47 q+ 18:09:59 GregB has joined #xmlsec 18:10:54 ack 18:11:06 ack fjh 18:11:21 ack klnaz 18:13:38 ack sean 18:14:36 sean: RetrievalMethod has a sequence of transforms. 18:19:41 Dsig proposal has three parts 18:20:00 a. receivers must assume c14n10 18:20:14 b generators must put explicit transforms to be clear on c14 version 18:20:34 fjh: if you use xml:base with exclusive canonicalization there may be issues, but it is something that can be addressed. 18:20:37 c mandatory algs c14n1.0 and c14n11 (both) 18:22:07 -EdSimon 18:22:34 ACTION: Thomas to provide precise wording for issues with exclusive canonicalization and xml:base 18:22:36 Created ACTION-7 - Provide precise wording for issues with exclusive canonicalization and xml:base [on Thomas Roessler - due 2007-05-09]. 18:23:12 ACTION: Thomas to propose spec wording for conformance-affecting changes 18:23:12 Created ACTION-8 - Propose spec wording for conformance-affecting changes [on Thomas Roessler - due 2007-05-09]. 18:23:31 +EdSimon 18:24:27 ACTION-7 closed 18:24:27 Sorry... I don't know how to close ACTION yet 18:25:08 TOPIC: Review of XML Signature errata 18:25:56 Is there a link to errata slides? 18:26:32 http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core 18:26:42 http://www.w3.org/2001/10/xmldsig-errata 18:33:16 ACTION: Sean to review E01 18:33:16 Created ACTION-9 - Review E01 [on Sean Mullan - due 2007-05-09]. 18:36:41 http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0039.html 18:37:44 ACTION-9 also covers reviewing the old material -- "what was meant by it" 18:39:02 fjh: E01 was meant to be editorial 18:41:27 fjh: added a note addressing E02 stating that Exclusive XML Canonicalization may be used 18:43:18 E02 accepted 18:46:49 http://www.w3.org/TR/xmldsig-filter2/#sec-Algorithm-Identifier 18:47:59 E03 edits accepted 18:48:37 -[NRCC] 18:49:04 I was cut off again; will call back shortly 18:49:18 -EdSimon 18:49:19 T&S_XMLSEC()8:00AM has ended 18:49:21 Attendees were +1.613.726.aaaa, EdSimon, fjh, GregB, grw, klanz2, rdmiller, tlr 18:49:30 ed, we were cut off 18:49:34 zakim, code? 18:49:34 the conference code is 965732 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tlr 18:49:43 T&S_XMLSEC()8:00AM has now started 18:49:50 +EdSimon 18:49:56 -EdSimon 18:49:57 T&S_XMLSEC()8:00AM has ended 18:49:58 Attendees were EdSimon 18:50:22 T&S_XMLSEC()8:00AM has now started 18:50:29 +EdSimon 18:50:36 +[NRCC] 18:52:07 E04 edits accepted, but will require wordsmithing to replace "since" with "because". 18:55:44 http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/0109.html 18:58:27 ACTION: Whitehead to review E05 18:58:27 Created ACTION-10 - Review E05 [on Greg Whitehead - due 2007-05-09]. 18:59:03 ACTION: klanz2 to investigate Austrian eGov use case for Type attribute 18:59:03 Created ACTION-11 - Investigate Austrian eGov use case for Type attribute [on Konrad Lanz - due 2007-05-09]. 18:59:27 grw has joined #xmlsec 19:01:09 Greg W: consider changing "signed" to "referenced" in "type of object being signed" 19:01:33 jcc: In E05 propose changing the word "signed" to "processed". 19:01:59 sean: implementation may need Type for RetrievalMessage processing 19:04:15 RFC 4051 section 3.2 defines many additional RetreivalMethhod types 19:05:58 fjh: action-10 is reassigned to Konrad 19:08:39 fjh: we think that E05 might be correct due to RFC 4051 section 3.2 and other language in that section may need to be adjusted. 19:11:58 General agreement to this 19:12:22 Topic: E06, base64 URI 19:12:40 question whether "base64" should be allowed or only URI allowed 19:12:54 Thomas suggests interop test for URI use for this 19:15:25 E06 edits accepted 19:19:20 klanz2: "#base64" is different than "base64" 19:19:51 Section 6.6.2 describes base64 URI for transform 19:20:46 see also 6.1 19:21:14 thomas: base64 encoding is manditory, URI declares the encoding in 6.1 19:21:31 ... No section that lists encoding algorithms 19:22:42 base64 transform URI not listed in 6.1 (only base64 encoding URI) 19:24:23 update to errata would be to complete the list of transforms in 6.1 19:25:52 tlr: explain what the base64 URI means in an encoding context 19:27:40 GregB has joined #xmlsec 19:31:51 q? 19:32:24 Konrad: "base64" is a URI 19:32:49 discussion whether this is an appropriate URI, issue of scheme 19:32:51 q+ 19:33:26 q? 19:33:29 thomas: non normative change 19:36:42 juan carlos: usage of attribute is an application matter, so is it a concern here for platform 19:37:01 Ed: plain base64 is not defined anywhere in the spec, but the URI is 19:37:17 s/platform/platform?/ 19:38:21 Ed: are we going to have a new namespace for dsig? 19:38:34 Gak no....! 19:38:47 http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html 19:39:05 tlr: our charter precludes us creating a new namespace for dsig 19:40:54 tlr: the base64 URI issue has been settled in previous attribute testing. base64 was only tested as a URI 19:41:39 Thomas proposed closing the discussion on E06 and accepting the edits 19:42:43 E07 accepted 19:43:25 deastlak: E08 looks correct to me 19:44:45 E08 accepted 19:46:02 q+ 19:46:10 fjh: do we need to go through dsig errata line by line or can we review Thomas' proposed changes? 19:47:37 q- 19:48:04 q- 19:48:09 ack 19:48:14 ack Ed 19:49:38 fjh: by default the usage of URI is optional and the DTD requires it 19:50:22 on break 19:50:31 return in 15 minutes 20:00:04 PHB has left #xmlsec 20:02:30 To clarify the XML DSig namespace question above -- my question was whether the current "xmlns="http://www.w3.org/2000/09/xmldsig#"" might be changed to indicate a later version, say "xmlns="http://www.w3.org/2007/12/xmldsig#"", based on this WG's activities. Answer: No, that implies changes beyond the scope of this WG. 20:15:01 TOPIC: Interop discussion and planning 20:15:44 tlr: immediate next step for Dsig is an updated editors draft. 20:17:32 tlr: is the inheritance issue something that will need to be in interop testing? 20:18:19 fjh: yes, and it may cause some schedule slip. 20:20:23 tlr: what are people expecting as timelines with regard to implementing and testing? 20:22:26