Draft minutes 2007-08-14

Thanks to Sean for scribing.  The updated draft minutes are here:

  http://www.w3.org/2007/08/14-xmlsec-minutes.html

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>







----- Forwarded message from Sean Mullan <Sean.Mullan@Sun.COM> -----

From: Sean Mullan <Sean.Mullan@Sun.COM>
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 14 Aug 2007 13:05:01 -0400
Subject: Re: minutes
Original-recipient: rfc822;sean.mullan@sun.com

   [1]W3C

                                   - DRAFT -

      XML Security Specifications Maintenance Working Group Teleconference

14 Aug 2007

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
          Frederick Hirsch, Sean Mullan, Thomas Roessler, Rob Miller, Ed
          Simon, Hal Lockhart, Konrad Lanz

   Regrets
   Chair
          Frederick Hirsch

   Scribe
          Sean Mullan

Contents

     * [4]Topics
         1. [5]Administrivia
         2. [6]XML Signature Draft
     * [7]Summary of Action Items
     __________________________________________________________________



   <trackbot-ng> Date: 14 August 2007

   <scribe> Meeting: XML Security Specifications Maintenance WG Conference
   Call

   <scribe> Scribe: Sean Mullan

   zakim +aaa is rmiller3

   <scribe> Agenda:
   [8]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/00
   38.html

Administrivia

   Tuesday 21 August, Scribe: Giles Hogben

   Tuesday 28 August, Scribe: Phill Hallam-Baker

   <fjh> workshop papers due today

   <fjh> ... 6 or 7 submitted so far

   <tlr> you can always update ;)

   <sean> RESOLUTION: last week minutes approved

   <tlr>
   [9]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/00
   24.html

   <tlr> I am ready

   <tlr> ... to deal with actions in tracker

   <tlr> ACTION-50 will happen today

   <sean> ACTION-68 to be reviewed later by sean

   <sean> ACTION-71 open

   <sean> ACTION-72 open

   <sean> ACTION: 73 to wait for Konrad to confirm if closed [recorded in
   [10]http://www.w3.org/2007/08/14-xmlsec-minutes.html#action01]

   <sean> ACTION-75: open

   <tlr> ACTION-76 closed

   <trackbot-ng> Sorry... I don't know how to close ACTION yet

   <sean> ACTION-77: closed

   <tlr> ACTION-77 closed

   <trackbot-ng> Sorry... I don't know how to close ACTION yet

   <tlr> ACTION-78 closed

   <trackbot-ng> Sorry... I don't know how to close ACTION yet

XML Signature Draft

   [11]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0
   010.html

   <fjh> ACTION-77 should be done

   <fjh> ACTION-76 should be done, does everyone agree?

   <EdS> looks ok to me

   <EdS> Looked good to me.

   c14n11 alg change -
   [12]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-Canonical11

   [13]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-URI

   for same-document red-line

   In this specification, a 'same-document' reference is defined as a
   URI-Reference that

   consists of a hash sign ('#') followed by a fragment or alternatively
   consists of an empty URI [URI].

   <klanz2> looks good, want to take another look at it

   ACTION-78, adding a editors note/warning about C14N11 Appendix A

   [14]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0
   017.html

   Editors Note: There has been a correction to Appendix A of the C14N11
   Candidate Recommendation. This correction is available

   at
   [15]http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-
   0050/Apendix_20060625.html. The XML Security

   Specifications Maintenance WG anticipates this change will be adopted
   as part of C14N11 CR review and will use this update to

   Appendix A for Interop testing.

   URI-Literal/RFC 2732 fix

   Remove from Section 4.3.3.1, "The URI Attribute, the following text:

   "However, some Unicode characters are disallowed from URI references

   including all non-ASCII characters and the excluded characters listed

   in RFC3986 [URI, section 2.4]. However, the number sign (#), percent

   sign (%), and square bracket characters re-allowed in RFC 2732 [URI-

   Literal] are permitted."

   Change "Disallowed characters must be escaped as follows:"

   "Characters disallowed in URI references by [URI] MUST be escaped as

   specified in [URI]:"

   Remove URI-Literal from list of references

   [16]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-URI

   <fjh> not in redline yet

   <klanz2> clarify that validating implementations need to be able to
   treat escaping/not escaping

   <sean> RESOLUTION: changes are accepted, put in redline document

   Replace "Support of the xpointer() scheme [XPointer-xpointer] beyond

   the minimal usage discussed in this section is discouraged." with

   "[XPointer-xpointer] is in Working Draft status as of publication of

   this edition of XML Signature. Therefore, support of the xpointer()

   scheme beyond the minimal usage discussed in this section is

   discouraged."

   <klanz2> concerned whether discouraging is the right thing to do

   <klanz2> should not deprecate anything that was optional before

   [17]http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2007JulSep/001
   2.html

   [18]http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2007JulSep/001
   5.html

   <tlr> good thing to discourage, reduces interop risk

   <EdS> +1

   tlr do reference wd but warn that can be problematical

   <fjh> need to move this forward for interop, needs to be stable

   <klanz2> existing signatures out there that use this but don't know
   impact yet

   <klanz2> worried about implementations removing support because of
   discouraging

   <klanz2> Support of the xpointer() scheme [XPointer-xpointer] beyond
   the minimal usage discussed in this section is discouraged, this does
   not affect the optional support of xpointers in URIs.

   tlr harmful to create perception of widespread XPointer support when it
   isn't there

   <tlr> discouragement is about xpointer() scheme, not framework

   <klanz2> a little late to discourage, been there since 2002

   <tlr> wrong. It's been wrong for quite some time.

   is discouraged for future signature generation

   <EdS> may run into same issues as ?

   <klanz2> Support of the xpointer() scheme [XPointer-xpointer] beyond
   the minimal usage discussed in this section is discouraged for new
   systems generating signatures.

   <fjh> that's what discouraging would solve, try to find wording that
   addresses konrads concerns

   <tlr> yes

   <EdS> future applications use plain URI and XPath transform instead of
   xpointer

   [XPointer-xpointer] is in Working Draft status as of publication of
   this edition of XML Signature.

   Therefore, support of the xpointer()

   scheme beyond the minimal usage discussed in this section is
   discouraged.

   Therefore instead of using the xpointer() scheme, use of a plain URI
   and transform is recommended

   <klanz2> Therefore, future applications use plain URI and some
   transform (e.g. XPath ) instead of xpointer

   <tlr> good to keep discouragement, reluctant to add should

   equivalent funcationality can be achieved by using a full URL and
   appropriate transforms.

   <tlr> ... could say by using appropriate transform, not an explicit
   recommendation

   <EdS> It is recommended that new applications implement the
   functionality described for XPointer above by specifying a plain URI in
   the Reference @URI attibute and using a Transform to select the
   required fragment.

   <fjh> fjh: all in agreement to make this problem known

   <tlr> well, lots of verifiers won't work anyay

   <klanz2> don't want to discourage validators from supporting what they
   have already supported

   <EdS> change "that new applications, when creating signatures,
   implement..."

   propose "discouraged for signature generation"

   <klanz2> ok with discouraging future signature generation

   It is recommended that new applications implement the functionality

   for signature generation

   described for XPointer above by specifying a plain URI in the

   Reference @URI attibute and using a Transform to select the required
   fragment.

   <tlr> concerned that making change still allows people to rely on it in
   validators

   <sean> ... need stronger statement

   can wordsmith ed sentence and add to discourage statement, on list

   <tlr> wording in editor's draft can be read that impl that support it
   may want to drop it

   tlr "use" is softer than "support", can help address concerns raised in
   WG, takes away some pressure on implementers

   <tlr> suggest "use of that scheme" is discouraged takes a bit of
   pressure off implementors

   <EdS> Note that while the alternative to XPointer I propose is an
   alternative, it is not necessarily better than XPointer because it puts
   processing load on the client rather than the server.

   <tlr> it is valid (and optional) to support any xpointer scheme you
   might come up with.

   <klanz2> just about the support being there since 2002

   <EdS> Xpointer was a CR but then went back to WD, right?

   <tlr> eds, yes, with massive changes

   <tlr> +1 to taking it to the list

   <fjh> excl c14n - agreed to not list it as an algorithm

   <fjh> ... discuss next week

   <tlr> hash out over email; first agenda item next week should be
   xpointer decision

   <sean> need to start test cases soon

   thanks Konrad. Discussing whether you can contribute test case
   input/output files into CVS folder under interop

   use of HMAC-SHA-1 mandatory alg for signing, sip

   <klanz2> I'll look into that on monday or tuesday

   is that simpler?

   want only 1 alg, one set of key material etc

Summary of Action Items

   [DONE] ACTION: 73 to wait for Konrad to confirm if [recorded in
   [19]http://www.w3.org/2007/08/14-xmlsec-minutes.html#action01]

   [End of minutes]
     __________________________________________________________________


    Minutes formatted by David Booth's [20]scribe.perl version 1.128
    ([21]CVS log)
    $Date: 2007/08/14 14:18:42 $
     __________________________________________________________________

References

   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0038.html
   3. http://www.w3.org/2007/08/14-xmlsec-irc
   4. file://localhost/home/roessler/.tmp/14-xmlsec-minutes.html#agenda
   5. file://localhost/home/roessler/.tmp/14-xmlsec-minutes.html#item01
   6. file://localhost/home/roessler/.tmp/14-xmlsec-minutes.html#item02
   7. file://localhost/home/roessler/.tmp/14-xmlsec-minutes.html#ActionSummary
   8. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0038.html
   9. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0024.html
  10. http://www.w3.org/2007/08/14-xmlsec-minutes.html#action01
  11. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0010.html
  12. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-Canonical11
  13. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-URI
  14. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0017.html
  15. http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html.
  16. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-URI
  17. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2007JulSep/0012.html
  18. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2007JulSep/0015.html
  19. http://www.w3.org/2007/08/14-xmlsec-minutes.html#action01
  20. http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
  21. http://dev.w3.org/cvsweb/2002/scribe/


----- End forwarded message -----

Received on Friday, 17 August 2007 12:29:12 UTC