See also: IRC log
Next meeting: 31 July, no meeting next week
fjh: Tech plenary draft agenda is available.
... still soliciting papers for workshop ...
... please follow up on interop questionnaire ...
... minutes for last time ....
<FrederickHirsch> http://www.w3.org/2007/07/10-xmlsec-minutes
tlr: umh, did I update the version in datespace
http://www.w3.org/2007/07/10-xmlsec-minutes.html
That's the updated version.
RESOLUTION: minutes approved
ACTION-26: note for submission to CG; continued
<FrederickHirsch> action-50 to be assigned to THomas, 31 July
ACTION-50: reassign to Thomas; new due date on 31 July
ACTION-53: work toward publication of decryption transform; blocked on XPointer issue
ACTION-56: done
ACTION-58: done; might need some refinement in terms of test cases
ACTION-61: done; haven't heard back
ACTION-62: clarify testing issues; done
ACTION-63: done
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0018.html
<fjh> i can scribe for thomas in this section
<fjh> Both decrypt transform and xml dsig core include effectively normative reference to XPointer, but to CR
<fjh> this was returned to WD, split into three, two went to REC
xpointer() XPointer scheme
<fjh> one part that includes material referenced did not , i.e
<fjh> DSig core can reference XPointer REC and Element scheme() XPointer
<fjh> look at 4.3.3.2
<fjh> look for paragraph "When a fragment is not preceded "
<fjh> barename now called shortname
<fjh> three kinds of XPointer - barename (still exist, shortname) in XPointer framework
<klanz2> do you have a link for the short name definition
<fjh> second, #xpointer(/), identifies root element in nodeset
<fjh> yes, in XPointer Framework...
<fjh> syntax for element XPointer only allows document, but would lose comments after closing tag of document element
<fjh> so cannot use element XPointer for this
<fjh> hence definition in this draft
<fjh> XPointer framework REC is http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
<fjh> XPointer element scheme REC http://www.w3.org/TR/2003/REC-xptr-element-20030325/
<fjh> looking at 4.3.3.3
<fjh> no XPointer evaluation context defined in framework
<fjh> edit for this, also to remove location-set
<fjh> i.e. no context, no location-set (point nodes, range set)
<klanz2> lost the call
<fjh> full xpointer, now is scheme based xpointer (equivalent distinction)
<jcc> q
fjh: intent of the changes to do what was done
before, but not refer to xpointer
... select portion of text? ...
... change implementations that relied on that? ...
tlr: well, that's OPTIONAL. Also, step 2 suggests that a partially selected text node would be fully referenced in the old model, no?
jcc: same question, q-
<fjh> not conformance affecting
phb: it's ok
<EdSimon> I think we need time to review the changes before the next call in two weeks.
<EdSimon> I'm good with merging.
<fjh> ok with merging
<scribe> ACTION: tlr to merge into main editor's draft [recorded in http://www.w3.org/2007/07/17-xmlsec-minutes.html#action01]
<trackbot-ng> Created ACTION-64 - Merge into main editor's draft [on Thomas Roessler - due 2007-07-24].
fjh: sense of group -- pretty close, no major rework?
klanz2: ok
<fjh> tlr: do we have test cases for C4N with comments?
jcc: can take an action
<scribe> ACTION: juan carlos to develop/retrieve test cases for C14N with comments, scheme-based xpointers [recorded in http://www.w3.org/2007/07/17-xmlsec-minutes.html#action02]
<trackbot-ng> Created ACTION-65 - Carlos to develop/retrieve test cases for C14N with comments, scheme-based xpointers [on Juan Carlos Cruellas - due 2007-07-24].
<fjh> tlr: inform coordination group of this approach regarding XPointer behaviour
<scribe> ACTION: thomas to inform xml cg of intent to squat on xpointer(/) and xpointer(id(ID)) [recorded in http://www.w3.org/2007/07/17-xmlsec-minutes.html#action03]
<trackbot-ng> Created ACTION-66 - Inform xml cg of intent to squat on xpointer(/) and xpointer(id(ID)) [on Thomas Roessler - due 2007-07-24].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0012.html
<hal> +1
fjh: defer to XML Signature vNext
ed: agree
<scribe> ACTION: Ed Simon to update wiki to list XPath 2.0 and XSLT 2.0 identifiers [recorded in http://www.w3.org/2007/07/17-xmlsec-minutes.html#action05]
<trackbot-ng> Created ACTION-67 - Simon to update wiki to list XPath 2.0 and XSLT 2.0 identifiers [on Ed Simon - due 2007-07-24].
<fjh> tlr: for items we defer to v.next, if urgent issue we can write note or members can do member submissions
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0024.html
fjh: thanks for doing that; very helpful
sean: went through the grammars, looked at
changes section in 4514
... three possible places with incompatibilities ...
... but they're (a) obscure, and (b) fix obvious bugs in 2253 ...
... first one, 2253 if you look at grammar doesn't allow attribute type
keywords of length 1 ...
... highly unlikely that's enforced ...
... would forbid C='US' ...
... used widely ...
... second one, RFC 2253 didn't allow '\ ' to escape a space ...
... another bug in the grammar ..
... doubt there are any implementations that enforce this one ...
... last one, RFC 4514 requires null characters to be escaped ...
... 2253 doesn't say anything about them ...
... worth writing a test case for each ...
... to make sure implementations aren't broken ...
fjh: write test cases, what else do we need to do?
sean: umh
fjh: I'm asking the wrong question. We've narrowed down the issues. These are reasonable changes, we'll look if we have any issues -- not sure that's really needed.
sean: I'm just suggesting that test cases are final action. If we do find problems, that's better fixed in the implementation than in the spec.
<fjh> Summary, agree that ok to change normative reference, to 4514, if these issues arise, then implementation has serious issue, an implementation issue
tlr: to summarize, we're fine changing the reference. If the differential use cases demonstrate strict RFC 2253 compliance, then that suggests insane implementation.
fjh: sounds reasonable
sean: would like to hear from Konrad
klanz: read e-mail; think that's fine
fjh: what else do we need to do?
tlr: umh?
fjh: where do we record this?
<fjh> record this in transition request as annotation to changes
<fjh> record in readme for test case
tlr: annotation to changes; transition request
sean: readme for test cases
fjh: track on wiki, not as separate action item
tlr: let's keep them in tracker
fjh: yeah... might indeed make it easier
<scribe> ACTION: sean to develop RFC 4514 / RFC 2253 test cases [recorded in http://www.w3.org/2007/07/17-xmlsec-minutes.html#action06]
<trackbot-ng> Created ACTION-68 - Develop RFC 4514 / RFC 2253 test cases [on Sean Mullan - due 2007-07-24].
fjh: XML escaping and well-formedness. Agreed there's no need to do more on this.
klanz2: early e-mail exchange; moot
... agree there's no open issue ...
EdSimon: yep, there was also an exchange with Sean around CDATA etc; not an issue
fjh: encoding of leading space in dname work --
anything needed?
... thought we had deferred to vNext ...
... is that an issue any more with all the changes? ...
klanz2: it's recommended to escape first space character...
<fjh> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/
tlr: RFC 4514 takes care of that
klanz2: "augment" takes care of that
<fjh> tlr: 4514 requires space at beginning to be escaped
klanz2: on the xmldsig-core side ...
fjh: ok, issue closed
... adding a warning similar to what was in the RFC
sean: record as best practice item
fjh: who would like to do this?
ed: ok, will do that along with other wiki
stuff
... would like review from Sean, Konrad ...
<fjh> warning similar to that of section 7.2 of RFC 2253: http://www.ietf.org/rfc/rfc2253.txt
<scribe> ACTION: ed to draft warning similar to that of section 7.2 of RFC 2253 as possible best practice item [recorded in http://www.w3.org/2007/07/17-xmlsec-minutes.html#action07]
<trackbot-ng> Created ACTION-69 - Draft warning similar to that of section 7.2 of RFC 2253 as possible best practice item [on Ed Simon - due 2007-07-24].
fjh: reversibility of string to DER encoding ... another warning?
jcc: yeah, that's what I was thinking
tlr: either this is the same issue as above, or the last action is wrong.
fjh: ooops, yes. Juan Carlos, please review what Ed does.
<fjh> 5c and 5d same item (in agenda)
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0005.html
jcc: that was the message sent concerning the
two attributes ...
... one appearing in ds:Reference, one appearing in ds:Object ...
... conclusion after reading in spec was ...
... ??? ...
... type attribute in ds:Reference always pointed to Object, Manifest,
whatever ...
... Type attribute in ds:Object element is MIME type ...
... which deals with media type ...
... they look a bit orthogonal ...
... but no guidance at all ...
... some kind of guidance should be given which interpretation is the right
one ...
... MIME type is string, Type is URI ...
... but we could put a MIME type into Type (??) ...
... clarify and agree what purposes of each attribute are ...
fjh: let me summarize... not an issue with the rec, but maybe some interpretation advice in best practice document?
jcc: exactly
klanz2: is there shared view that these are
orthogonal -- schema type vs. media type of encoded object?
... I agree to that interpretation ...
fjh: konrad, please send list to message, errrm, ..
<klanz2> ;-)
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0026.html
<klanz2> I'll list a send to the message ;-)
jcc: tried to clarify proposed way to build
infrastructure for infrastructure
... proposal is that last table have links to details of test cases ...
... and test cases themselves ....
... especially relevant for test cases dealing with c14n and inheritanc
e...
... first, XML document, then list of links to different signatures ...
... that participants would compute ...
... in the end, would have document reference with tables and references to
each test case ...
fjh: some c14n tests might just have input/output?
jcc: ??
fjh: maybe just look at same canonicalized output?
jcc: not at level of signature, only i/o of
c14n?
... would work for some test cases, but maybe would also like to have
negative test cases?
klanz2: enveloping signatures?
jcc: need to think more about that
... for identifying false positives, would need actual signatures ...
klanz2: doesn't prevent us from having unit tests for c14n
fjh: want to focus next call on (a) agreeing on redline as merged
fjh: also, go through Juan-Carlos' document,
test document, update, make progress on that
... please review ahead of time ...
klanz2: is there some howto for the CVS?
<fjh> tlr: test data goes into test subdirectory for interop
<fjh> tlr: try to use valid HTML instead of word etc
<fjh> ... avoid plain UTF-8 encoding
<fjh> ... general cvs instructions available on W3C
<fjh> next call - agree dsig redline (merged), decrypt to last call, normative reference to URI spec (RFC obsoleted) same doc RFC reference (Thomas to send more detailed message to list), review Juan Carlos docs
fjh: adjourned