See also: IRC log
<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: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0038.html
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> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0024.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 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
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0010.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 - http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-Canonical11
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
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0017.html
Editors Note: There has been a correction to Appendix A of the C14N11 Candidate Recommendation. This correction is available
at 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
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
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2007JulSep/0012.html
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2007JulSep/0015.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