XML Security Specifications Maintenance Working Group Teleconference
21 Aug 2007

<fjh> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0054.h tml

<klanz2> re: xpointer http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0055.h tml

<EdS> starting at 9am, going for 90 min, is good for me

fjh: change meeting from 90 mins to 1 hour - only Hal has a problem

<klanz2> +1 to fjh (+30 mins on demand)

<tlr> +1 to 90 min

hal: only problems every other week

fjh: keep it simple - 90 mins every week - 1 hr + 30 mins on demand
... Phil to scribe

<fjh> minutes from last week http://www.w3.org/2007/08/ 14-xmlsec-minutes

next week

fjh: next week

resolution: last week's minutes approved

fjh: action 26 open

<tlr> http://www.w3.org/2007/xmlsec/w s/venue is the logistics page

<scribe> Action 50 to done [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action01]

<tlr> I need to set up registration, though

<scribe> Action 65 to open [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action02]

<klanz2> Re ACTION-72: XPointers with location steps basically in every Austrian eGov Signature, this maight change for future signature generation, but legacy signatures will remain. EBICS a german and potentially future European Payment/Banking/MoneyTransfer system has currently use of xpointer() scheme.

<scribe> Action 72 to done [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action03]

There has been a paper submitted already to the workshop - there should therefore be enough discussion already. Sent email to ask if worth getting EBICS involved too

klanz2: is it worth getting in touch direct with EBICS

action 1 - is there a danger in changing the reference from the previous candidate rec to the new working draft?

NO danger

<scribe> Action 74 still open [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action04]

<scribe> Action 75 to still open [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action05]

<scribe> Action 79 to closed [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action06]

action 80 closed

fjh: XML sig draft needs to be closed and start editing

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0041.h tml

TOPIC: xpointer

about warning wrt deprecating xpointer pointer scheme

<tlr> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0055.h tml

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0040.h tml

klanz2: change to the wording proposed by Thomas is that we want to see a change of "minimal usage" to "usage" and "support for use" of xpointer to "use of xpointer"

only 1st sentence is changed

tlr: fine with edits. Slightly -ve on additional text but can live with

<tlr> The original edition of this specification [XMLDSIG-2002]

<tlr> referenced the XPointer Candidate Recommendation

<tlr> [XPTR-2001]. That Candidate Recommendation has been

<tlr> superseded by the [xptr-fwk], [xptr-xmlns] and

<tlr> [xptr-element] Recommendations, and -- at the time of this

<tlr> edition -- the [xptr-xpointer] Working Draft. Therefore,

<tlr> the use of the xpointer() scheme beyond the usage discussed

<tlr> in this section is discouraged.

pasted section excludes change to 1st sentence

<tlr> change to first sentence:

<tlr> The original edition of this specification [XMLDSIG-2002]

<tlr> referenced the XPointer Candidate Recommendation

<tlr> [XPTR-2001] and some implementations support it optionally.

fjh: explains rationale for not using original xpointer spec

klanz2: can we accept the changes?

<tlr> ", and some implementations supported the xpointer() scheme."

tlr: proposes above

klanz2: remove the "ed" - i.e.

<klanz2> ", and some implementations support the xpointer() scheme."

<tlr> PROPOSED: to accept wording proposal from http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0055.h tml including change to first sentence

<tlr> RESOLUTION: to accept wording proposal from http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0055.h tml including change to first sentence

TOPIC: exclusive canonicalization

fjh: propose not to make the change

close the issue with no action?

tlr: might be useful to talk about E canon in the best practices doc

tony says some material might be captured in ws-sec

should not be seen to duplicated Exclusive canonicalisation

<fjh> exclusive canonicalization is explicitly mentioned in

<fjh> section 6.5

seems current text is clear enough - since no strong proposals to reference Exclusive Canon

<tlr> PROPOSED: not to make further changes to list of algorithms in 6.5

<klanz2> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-NamespaceContext< /a>

klanz2: maybe worth making a note that this stuff is around

<tlr> fjh: it's in there

<sean> see last paragraph of section 6.5

<fjh> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-c14nAlg

hal: concern that there might be an implication that exclusive is no good

tlr: this sort of concern can be dealt with in announcing the doc

<fjh> +1

tlr:in announcing this - a clarification of relation to exclusive is worth adding

<EdS> +1

klanz2: maybe worth adding a sentence " unused ancestor context from a canonicalized subdocument and is not suceptible to inheritance problems"

PROPOSED: in communicating the update to XML core we shall call attention to the fact that exclusive canon' does not suffer from the xml ID problem

<klanz2> fine with me

<fjh> also with 2nd edition XML Signature

<tlr> PROPOSED: in communicating update to xmldsig-core, to call attention to fact that xml-exc-c14n does not suffer from xml:id issue, and ask XML Core WG to do same in announcing xml-c14n11

tlr: earmark for easy future spec work

<tlr> RESOLUTION: in communicating update to xmldsig-core, to call attention to fact that xml-exc-c14n does not suffer from xml:id issue, and ask XML Core WG to do same in announcing xml-c14n11

<fjh> RESOLUTION: in communicating update to xmldsig-core, to call attention to fact that xml-exc-c14n does not suffer from xml:id issue, and ask XML Core WG to do same in announcing xml-c14n11

<tlr> actually, konrad, there are a couple Candidate Recs in there....

tlr: we should consider an update to Exclusive Canonicalization in the future, to clarify that it is valid and up to date, and to update references at the same time

PROPOSAL: do not change the spec to add exclusive canonicalization

<fjh> RESOLUTION: do not change the spec to add exclusive canonicalization

<EdS> +1

<tlr> konrad, your question about references in exclusive was a good one. Just grep for the word Candidate. #@$%&

<fjh> updated examples per sean's message - http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0050.h tml

PROPOSED: accept these changes

<fjh> Remove digest values in s10 and s13 since these should not be confused as valid

tlr: suggest to remove digest values and replace them with something which people don't confuse with a digest value of the document

either make sure the digest value is still the same for these reference statements or drop them

<fjh> 2.1.1 s10, 2.2 p9

we could turn them into test cases and capture action item to update spec accordingly once we know what the sigs are

<tlr> also section 2.3, m07

<scribe> ACTION: update the digest values in sec 2 examples when we have the test cases which produce those values [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action07]

<tlr> ACTION: frederick to update digest values in section 2 examples when we have test cases which produce values (or else insert dots) [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action08]

<trackbot-ng> Created ACTION-81 - Update digest values in section 2 examples when we have test cases which produce values (or else insert dots) [on Frederick Hirsch - due 2007-08-28].

<fjh> PROPOSAL: accept changes in http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0050.h tml

<tlr> RESOLUTION: accept changes in http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0050.h tml

<klanz2> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-Same-Document

<tlr> or else, put in VGhpcyBpcyBub3QgYW4gYWN0dWFsIGRpZ2VzdCB2YWx1ZQo= as the digest value

<tlr> http://www. w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-URI

<fjh> see 4.3.3.1 The URI Attribute

<klanz2> http://www. w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-URI

klanz: section 4.3.3.1 (uri attributes) would like to know if final text is subject to discussion from position papers (Marcus E)

if we stabilise this now, do we put this into a new draft?

<fjh> Concern about implementation and "Characters disallowed in URI references by [URI] MUST be escaped as follows in [URI]"

<fjh> tlr: suggest test case for this with URI encoded brackets

tlr: text is meant to say that you need to apply uri encoding including an xpointer

at least one well-known implementer saw there was no need to do that encoding

concern - is there a reasonable reading of the old text by which an implementation might not need to do encoding

<tlr> xpointer()

<tlr> xpointer(/)

<klanz2> xpointer('/')

do test case where we include a mandatory xpointer char e.g. (/) and where it is encoded

tlr: just test at interop

<fjh> ACTION: klanz2 add test case for XPointer URI encoding, including bracket characters [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action09]

<trackbot-ng> Created ACTION-82 - Add test case for XPointer URI encoding, including bracket characters [on Konrad Lanz - due 2007-08-28].

klans2: wants to make sure that current text expresses the correct meaning

there are some characters which you don't have to escape which everyone should be able to read when parsing a uri

tlr: if you have specific concerns about specific chars, prepare a test case.

<fjh> note following sentence - "XML signature applications MUST be able to parse URI syntax. "

<fjh> tlr: hence must be able to perform escaping

<fjh> tlr: WG believed change is not conformance effecting. Can we produce test case that shows conformance impact of change?

tlr: klanz2 must produce a test-case to prove that there is an effect on conformance

klanz2: not happy with the MUST here

<tlr> note the word "must" was in there before

klanz2: need more time to think

fjh: need stable doc for interop so want to freeze on this call

tlr: onus on Konrad to produce test case which shows that text change is conformance affecting

<tlr> PROPOSED: to consider xmldsig-core closed, pending interop testing, SOTD, and acknowledgements

<tlr> RESOLUTION: to consider xmldsig-core closed, pending interop testing, SOTD, and acknowledgements

<tlr> PROPOSED ACTION: konrad to look for test cases that might indicate the change to 4.3.3.1 is conformance-affecting

<tlr> ACTION: konrad to look for test cases that might indicate the change to 4.3.3.1 is conformance-affecting [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action10]

<trackbot-ng> Created ACTION-83 - Look for test cases that might indicate the change to 4.3.3.1 is conformance-affecting [on Konrad Lanz - due 2007-08-28].

workshop

Please see the full minutes for detail.

Interop

<tlr> <a><b><c><d><e><f>

<fjh> sean needs resolution of issue noted in email

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0049.h tml

<tlr> remove <b> to <e>

<klanz2> that is what i wanted to propose

<tlr> see? ;-)