See also: IRC log
<trackbot-ng> Date: 18 September 2007
<scribe> Meeting: XML Security Maintenance Working Group Conference Call
<scribe> Scribe: Juan Carlos Cruellas
<fjh> Chair: Thomas Roessler
tlr: asks klanz2 on minutes version
konrad: he has sent already.
tlr: will approve next meeting
... remind booking hotel for November plenary, as there is a deadline
... 20(?) people at the workshop
... there will be some slight changes in the final agenda. Somebody will not be able to attend
hal: requests shift in his presentation
tlr: anything else on workshop?
action#26: is still open
action#71: sean: still open.
action#74: to no further progress.
action#82: konrad plans to close it today.
action#83: as above.
bruce: on xpointers...
... would like to talk about certain URI fragments in the document.
tlr: review afterwards
Juan Carlos: konrad, Sean and Juan Carlos coordinated incorporation of new material to the interop
scribe: document... from what I have seen we all have committed new versions to the cvs
konrad: the document contains enough
information as to allow people to start doing interop
... use firefox and they will get the output scroll bar...
... they will get nicer view.
<tlr> ACTION#91: closed
konrad: we are allowed to introduce additional material if we identify it...
sean: do not see changes document that I made yesterday at the in the html document pointed by the url in the agendta
<klanz2> ah, herte it is Add links to test signatures in sections 126.96.36.199 and 188.8.131.52.
<klanz2> I'll do that now
tlr: transform the xml to html: konrad or jcc
may do it.
... konrad, could you please do it?
action 92 sent that note, not feedback CLOSED
<tlr> ACTION#92: CLOSED
action 93 konrad will do it today: OPEN
<tlr> ACTION-93 continued
bruce: go to the html document testcases.html
<klanz2> built the document, sean check if your changes are there
bruce: some "#" missed when identifying values of URI fragments.
<klanz2> yes brich is right
<klanz2> I'll just fix that now
<klanz2> SHOULD BE FIXED
<klanz2> @jcc done
bruce: this problem happens in all the test cases for xpointers using xpointer framework
<scribe> ACTION: klanz2 to fix the xpointers in the xpointer framework adding the missing "#" sign to the URI fragments [recorded in http://www.w3.org/2007/09/18-xmlsec-minutes.html#action05]
<trackbot-ng> Created ACTION-94 - Fix the xpointers in the xpointer framework adding the missing \"#\" sign to the URI fragments [on Konrad Lanz - due 2007-09-25].
<tlr> ACTION: sean to generate new test signatures for xpointer [recorded in http://www.w3.org/2007/09/18-xmlsec-minutes.html#action06]
<trackbot-ng> Created ACTION-95 - Generate new test signatures for xpointer [on Sean Mullan - due 2007-09-25].
bruce: Second issue for xmlpointers test cases: unclear for xpointer framework test cases whether the canonincalization is 1.0 or 1.1
<klanz2> well there is a RECOMMENDATION for c14n1.1 in the spec
<klanz2> in the section for reference generation
<sean> +1 to konrad
"The ds:Reference for enveloped signatures will contain two Transform elements, namely; the enveloped signature transform and the one indicating canonical XML 1.0 (these test cases are not designed to deal with canonical XML 1.1). The ds:Reference for enveloping signatures will contain only the second one."
tlr: should not we have the same test cases for c14n1.1?
<klanz2> updated '#' issues in http://www.w3.org/2007/xmlsec/interop/xmlsig-interop-doc/testcases.html#TestCases-SchemaBasedXPointers press shift reload
juan carlos: xpointer framework test cases were requested without looking at the cannonicalization...
sean: these test cases should use canonicalization 1.1
<klanz2> May I propose to use two references one using 1.0 and one using 1.1 if this has value in the defined testcases to demonstrate some difference
<klanz2> if not let's just use 1.1
sean: should move away from 1.0
konrad: worth to use both... in order to go deeper in behaviour.
tlr: people support using 1.1
bruce: support 1.1. Either one would be OK. Do not see difference in process
tlr: we agree that canonicalization 1.1 should be present
<tlr> RESOLUTION: xpointer test cases to be changed to c14n 1.1
<scribe> ACTION: klanz2 to switch xpointer test cases to c14n1.1 [recorded in http://www.w3.org/2007/09/18-xmlsec-minutes.html#action08]
<trackbot-ng> Created ACTION-96 - Switch xpointer test cases to c14n1.1 [on Konrad Lanz - due 2007-09-25].
<klanz2> is the way the xpointer test cases are designed xml:base tested as well ?
<klanz2> I just looked into the cvs it is not have xml:base attributes
<klanz2> no that's it
tlr: section 3.3
konrad: three new test cases checking implicit
and explicit indication of canonicalization algorithms
... some test that should use 1.1 actually do not mention any algorithm, which by defalut means that they use 1.0
sean: the test cases for this part are
... changed the way they were specified quite a bit and appreciate any comment on that...
... for the second part implemented 3 of the cases that seem to be the most important ones...
<klanz2> Update to the XPointer test cases:
<klanz2> The ds:Reference for enveloped signatures will ebventually contain two Transform elements, namely; the enveloped signature transform and the conversion from node set data to octet stream (canonical XML 1.1).
sean: the rest seem not to explicitly check the RFCs but only thigns nice to test
<klanz2> not yet for xpointer and dname
sean: dropped material on these test cases in the cvs
bruce dropped signatures on xml:base and verified signatures from sean.
jcc: try to drop some material during this week
esimon2: three months ago we discussed the DNs encoding and reversibility
<klanz2> ed: encoding rules /issue of reversibility / security considerations /trying to get corrwect certificate
<klanz2> ... are the reversibility issues
<klanz2> ... sean & ed: attrubute type makes a difference
esimon2: sean mentioned some questions, like if
the attributetype makes a difference and whether
... there could be an attack on that...
<klanz2> could there be an attack, when a different certificate sneaks in
esimon2: or you get a different certificate...
sean: does anyone follow the PKIX group progress?
konrad updated the document in terms of xpointers
juan carlos: should be considered in the future
konrad: substituion attacks could be
... strict rules for requesting certificates... should not this disminish the danger?
ed: it is also a matter of accuracy: with ASN1 you are exactly referring the right certificate...
konrda: substitution attacks are managed outside XMLDSIG (XAdES, for instance ensure data from the certificate so that substitution may be detected)
<klanz2> dialing in again
sean: review the whole RFC of encoding
... what we are doing in XMLDSIG is requiriung reversibility to a spec that did not pursued tahat
... we could come up witha mechanisms that grants that there is no loss of information in either way...
<klanz2> is this ismilar to xml encoding rules?
next XMLDSIG versiohn should incorporate this feature
hal: in Web services security... referring to a certificate is not easy ... and doing a DN comparison is something commonly done...
sean: something to investigate in the next months to come
ed: interesting to explore this reversibility between ASN.1 and XML for DNs.
tlr: what I heard seems to go farther than best
... and could be a relevant item for a future working group
esimon2: will not be present in workshop but yes in November, in Boston
<klanz2> maybe its worth to point from the wiki to the minutes
tlr: should we add this into the wiki?
ed: enough with the minutes...we will have to deal with this in the future
<esimon2> I will be dialing into the WorkShop next week though I will not be there in person.
<klanz2> @ED, maybe you'd like to add the DNAME Reversibility topic here
tlr: proposal for modifying decryption
transform... hanging for number of days.. what people think?
... any interest on that now?
<klanz2> any, luck with alex sanin ?
tlr: as we have not been able ot progress on this issue it might happen that we drop the issue
tlr: come back to item 6
... should interop progression tests? to incorporate xmlsig former tests conveniently updated?
konrad: almost impossible to update former tests in xmlsig for incorporating c14n1.1 there
<esimon2> Thomas -- I keep getting cut off IRC; please send me the raw version after the meeting ends so I can write up something re the reversibility issue re Konrad's suggestion. Thanks, Ed
konrad: proposes to leave them as they are as legacy test cases
sean: doable, they have tools that already
created all of them
... could modify them to nsert c14n1.1 in them...
tlr: it could be useful
bruce: not sure...not familiar with these tests so not able to assess their difficulty
sean: would not be expecting the others generatign signatures, but verifying them
konrad: agree with sean if we keep this informally.
tlr: sean could generate these signatures and verification test cases could be performed on them
sean: will generate and drop them in the cvs
bruce: is it possible to know the format so that we may prepare the test framework?
sean: propose to generate the merlin 23
signature (the big one) with the c14n11 canonicalization there
... only the big one, not the rest
konrad: sean mentioned some test cases that never were tested...would it be worth to do something on them at the interop?
<klanz2> also for the ok if we have time list
<klanz2> I can hear you okay
tlr: need for an agenda bit more formal
<tlr> tlr: interop, any other business?
<tlr> frederick: other participants?
<tlr> klanz2: comment mailing list?
<tlr> tlr: public-xmlsec-comments
<klanz2> Action to tlr to create a small sction on the public page referring to the comments mailing list plus some list to relevant material
<tlr> ACTIONS: frederick to point addtl participants at comment mailing list
tlr: question on organizational issues.
very few registration so far.
<klanz2> just me
scribe: who will be at the interop?
<sean> just me
jcc: only me
<brich> just me
tlr: thank you...that is enough
bruce: is there somewhere something of the type
"must do" for the interop?
... xml space attribute "must do", xpointers "may do"
konrad: the more we may bring the better
<brich> my "must-do" assumption was ID, SPACE, LANG, BASE
sean: test cases using XSLT may put problems as XSLT itself is not mandatory
konrad: some test case that includes binary input in one of the transforms steps..
sean: it has to be optional at the end of the day
tlr: the goal will be to have the things ready
for progressing the canonicalization spec
...tlr: no public report of the interop...
<brich> some interops publish only impl A, B, C...
tlr: might be one way... although it will
depend on the final result...
... would not like to make a decission just now
<klanz2> we do need a certain number implementations and I'm confident we'll all be quite successful ...
jcc: proposes that everybody is free to decide whether is mentioned or not in the public report
tlr: need to think more about that: anonymous report as proposed by brich could be one way
<klanz2> xmldsig/defCan-2 and xmldsig/defCan-3 contains an xslt transform and I'll put "(optional) " next to the test name
tlr: thank you everybody for attend the meeting.
<klanz2> bye bye, lookin forward