XML Security Specifications Maintenance Working Group Teleconference -- 18 Sep 2007

<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> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Sep/0013.html

TOPIC Administrativia

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 item review

action#26: is still open

action#71: sean: still open.

action#74: to no further progress.

action#81: CLOSED.

action#82: konrad plans to close it today.

action#83: as above.

action#90: closed

action#91: closed

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 3.3.4.1 and 3.3.4.1.

<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

xpointers

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.

<brich> http://www.w3.org/2007/xmlsec/interop/xmlsig-interop-doc/testcases.html

<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."

bruce: agreed

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

Section 3.3, Implicit/Explicit rules

<tlr> http://www.w3.org/2007/xmlsec/interop/xmlsig-interop-doc/

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

Section 3.5 DNs

<tlr> http://www.w3.org/2007/xmlsec/interop/xmlsig-interop-doc/

<tlr> http://www.w3.org/2007/xmlsec/interop/xmlsig-interop-doc/testcases.html#TestCases-DistinguishedName

sean: the test cases for this part are completed
... 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

xml:id, :lang, ... implementation status

<klanz2> same

<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

Best Practices

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?

<sean> http://www.imc.org/ietf-pkix/mail-archive/msg04986.html

konrad updated the document in terms of xpointers

juan carlos: should be considered in the future

konrad: substituion attacks could be possible...
... 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 DNs...
... 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

<klanz2> s/isimilar/similar/

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 practices
... 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

decryption transform

<esimon2> I will be dialing into the WorkShop next week though I will not be there in person.

<tlr> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0012.html

<klanz2> @ED, maybe you'd like to add the DNAME Reversibility topic here

<klanz2> http://www.w3.org/2007/xmlsec/wiki/CharterDevelopmentForSignatureEncryption

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

Recommendation for regression tests?

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.

<klanz2> +1

jcc +1

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

any other business

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> positive

<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

<tlr> adjourned

- DRAFT -

XML Security Specifications Maintenance Working Group Teleconference

18 Sep 2007

Attendees

Contents