See also: IRC log
<trackbot> Date: 17 February 2009
<fjh> Scribe: Juan Carlos Cruellas
<tlr> (Maybe we should pick Florida for the next face-to-face...)
<jcruella> Meeting: XML Security Working Group Conference Call
<jcruella> Chair: Frederick Hirsch
<jcruella> Scribe: Juan Carlos Cruellas
<jcruella> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0050.html
<jcruella> FH: Konrad scheduled to scribe next week
<jcruella> Liaisons and coordination: nothing to report
<jcruella> FH: Announcements: at the end of the meeting would like to have resoultions on making publicly available the drafts
<jcruella> 2a) Minutes from 3 February 2009, for approval:
<jcruella> FH: could we approve minutes of 10 February 2009
<fjh> http://www.w3.org/2009/02/10-xmlsec-minutes.html
<jcruella> FH: propose to approve these minutes of 10th February meeting at the next meeting.
<fjh> ISSUE-98 Reference format needs to be unified
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0040.html
<jcruella> fjh: the algorithm document has been updated.
<jcruella> tlr: it now contains all the algorithms desired.
<fjh> XML Signature 1.1
<jcruella> fjh: the other document is the XMLSig 1.1, which has been updated by TLR at least twice
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0046.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0049.html
<fjh> Transform Simplification
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0047.html
<jcruella> fjh: done editorial cleanup, not significant changes since last update
<fjh> Derived key draft
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0057.html
<jcruella> fjh: one item. Magnus reached a number of questions. He asked additional eliptic curves algorithms.
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0012.html
<jcruella> fjh: any thought about this? my own one is that we could do some work on this. Should we recommend other algorithms at different security levels?. And what about hash algorithms? should we add some more?
<jcruella> bal: I would defer this...was a little confuse by Magnus message...I think that we have this solved in the draft: section 6 list of required and recommended.
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Algorithms
<fjh> suggest we defer after first public working draft
<fjh> http://www.w3.org/2002/09/wbs/42458/fpwd-ecc/results
<jcruella> fjh: thanks for working on the questionnaire. It looks like there are different views
<jcruella> Results at: http://www.w3.org/2002/09/wbs/42458/fpwd-ecc/results#xq5
<tlr> "pregnant chads" anyone?
<fjh> required - 5, recommended - 8 abstain - 3
<fjh> cannot live with 2 each way
<jcruella> brian: I thought that people could say what the concerns are
<fjh> working group now can express their concerns leading to cannot - live with. A round to see what the concerns are?
<fjh> other concerns as well, also non-technical vs technical
<jcruella> fjh: start with people that say they can not leave with.
<jcruella> tlr: brian, Chris, Robert, Ken
<gedgar> +q
<jcruella> chris:
<jcruella> ...we have third parties soft, they are not willing to add certain algorithms... required, we may roll out in the implementations...
<kgraf> +q
<jcruella> fjh: mention that this is what we want in the first public draft, not necessarily in the final document. Maybe should distinguish concerns on what should be in the first draft from what is in the final doc....
<jcruella> GeraldEdgar: concern on robustness security level ....
<tlr> fjh: different algorithm available?
<gedgar> yes..thanks thomas
<tlr> gerald: if it has same level of security, yes. But need to support Suite B.
<fjh> gerald notes that simpler to ask suppliers to support Suite B and get level of security
<fjh> gerald notes also helps with international issues
<jcruella> ken:
<fjh> ken also have 3rd party products built into products so don't want to requre them to build in ecc
<jcruella> ken: do not violently opose to this...I could be convinced to live with this.
<jcruella> bal: question: want understand what is third partie issue?
<jcruella> ...ken says that there are third parties in their products...
<jcruella> ...but in chris' it is a matter of other soft to plug in...
<jcruella> bal: I am not sure that requiring support is the same as requiring generation. It is requiring verification
<fjh> bal notes but requires validation
<jcruella> chris: but their implementations would not be able to manage
<fjh> bal notes need two mandatory algs in spec in case one is no longer usable
<fjh> bal notes spec might be around a long time
<fjh> bal concerned about ws* and other profiles which will only go with what is mandatory to implement
<fjh> bal also notes some customers are asking for suite B
<fjh> bal notes suite b is a major feature of 1.1
<Zakim> Thomas, you wanted to ask whether we need to bring some of these third parties into the discussion
<fjh> tlr asks can we get those 3rd party implementers to participate in this WG?
<fjh> tlr asks is it a public procurement issue?
<fjh> tlr notes with 1st edition RSA got profiled even though not mandatory
<jcruella>tlr asks where is the critical difference between required and recommended, Brian?
<fjh> hal notes that draft requires alg for both signing and verification
<fjh> hal asks about compliance requirements
<jcruella> hal notices that another point is that this will drive for major vendors.
<fjh> hal notes that argument for alternate alg is weaker since all depend on SHA hashing
<tlr> ACTION: thomas to fix algorithm links in 6.1 (see e-mail just sent to list) [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-213 - Fix algorithm links in 6.1 (see e-mail just sent to list) [on Thomas Roessler - due 2009-02-24].
<fjh> hal notes that it may not be appropriate to require a new algorithm that has not been in use for a while
<jcruella> fjh: w* not profile soon...
<jcruella> ...another point: did not understand the question on the eprocurement..
<jcruella> tlr: think it was not critical...
<fjh> bal notes only RSA-SHA1 is supported in WS* so they will probably need an update
<fjh> bal notes RSA was widely deployed at time of 1st edition
<jcruella> bal: RSA widely deployed, DSA was there because of basic requirements. Here we have the case that none of the algorithms in 1.0 are actually mandatory. Do not think the situation is the same as in 2000. do not think requiring long keys is worth.
<fjh> bal notes it is essential to be able to be agile if crypto alg is not useable
<jcruella> fjh: brian, we have two responses to the " can not live with this requirement" if there are products from other parties....
<kgraf> +q
<jcruella> Bal: my concern is that we would prefer to see recommended algs, and see more than one, before seeing required algorithms.
<fjh> kgraf notes that alternative is to have recommended algs and require two or more to be implemented. Some small environments with only one algorithm, and if fails, then change to another.... as oppposite to have several algorithms in the implementation
<fjh> impact on interop?
<jcruella> ......
<fjh> bal notes that with new 1.1 standard, 3rd party will have to update anyway to be compliant with 1.1. Still have 1.0
<jcruella> hal notes that changing rsa-sha combination is minor compared to the ec algs.
<kgraf> +q
<fjh> tlr asks if objection about specific second alg but against having two mandatory algs
<fjh> ken is against requiring any algorithm
<jcruella> brian: objection to require any algorithm... not objection against one specific algorithm , but to require any algorithm
<jcruella> fjh: two different things: objections to ec, objections to require algorithms...
<fjh> hal notes we need one mandatory to implement to get interoperability
<fjh> +1
<jcruella> hal: strongly against not mandatory idea.
<jcruella> hal: new hash algorithm....the advance in theory could conceivably discover new algorithms invalidating sha family...since this is first public draft, put it as it is and get feedback from outside
<fjh> hal required is likely to get more feedback in first public working draft
<jcruella> Ken: I would agree in making this draft public, with the idea of getting feedback from outside.
<jcruella> tlr: would be useful to have an editorial note summarizing this discussion today
<gedgar> +1 on making this required for this working draft and see what response we receive.
<esimon2> Didn't we at one point, given algorithm lifespans, consider keeping XML Signature and XML Encryption algorithm-neutral and then supporting plug-in profiles of algorithm suites? (Interoperability would then be on an algorithm suite basis.)
<tlr> PROPOSED: To use ECC as REQUIRED algorithms in xmlenc 1.1 and xmldsig 1.1 FPWDs, with an editor's note that highlights issues concerning recommended vs required algorithms and solicits further feed-back.
<jcruella> fjh: how to proceed with the note?...will you propose some text, circulate it, people would agree and then close the document?
<jcruella> tlr: taking into account that publication will likely take place next week, we could have discussion on the list...
<jcruella> fjh: if there are not major issues raised in the email we may proceed to publish
<jcruella> RESOLUTION: the WG agrees o use ECC as REQUIRED algorithms in xmlenc 1.1 and xmldsig 1.1 FPWDs, with an editor's note that highlights issues concerning recommended vs required algorithms and solicits further feed-back.
<fjh> Chris and Ken noted that they could live with having REQUIRED in the FPWDs with a note indicating the issues
<jcruella> ACTION: Thomas to write down a note summarizing discussion on algorithms to be included in the draft to be made public -due 17/02/2209 [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-214 - Write down a note summarizing discussion on algorithms to be included in the draft to be made public -due 17/02/2209 [on Thomas Roessler - due 2009-02-24].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0048.html
<jcruella> tlr: do not think we need to take any action.
<jcruella> fjh: any other XMLSig 1.1 or XMLSEC 1.1 issue?
<tlr> ACTION: thomas to fix contributors' list [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-215 - Fix contributors' list [on Thomas Roessler - due 2009-02-24].
<jcruella> fjh: we should have a list of members at this point of time for the documents to go public
<jcruella> tlr: links in drafts have to be fixed... I will do that.
<jcruella> fjh: we will go trhough the actions so that we are sure that we do not forget anything....
<jcruella> ...maybe we may make the resolution now and then agree in the modifications...
<jcruella> fjh: I did some editorial changes to Patrick's last version capturing all the discussions. Pratik, did you have time to look at it?
<jcruella> Pratik: did not have time to do it yet...
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0047.html
<jcruella> fjh: unless we have an issue I think that we should agree in making it public.
<jcruella> fjh: did some fixing in the draft.
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0055.html
<fjh> This use case and requirements document is intended to summarize use
<jcruella> fjh: added some text in the introduction ...would like to agree to incorporate it in the public document
<jcruella> fjh reads the text proposed.
<jcruella> RESOLUTION: the WG agrees in updating the use cases document as proposed by Frederick in his message http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0055.html
<jcruella> ACTION: Thomas to add the text proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0055.html in the introductory section of the use case document [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-216 - Add the text proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0055.html in the introductory section of the use case document [on Thomas Roessler - due 2009-02-24].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0044.html
<jcruella> tlr: by default implementing an algorithm not mentioned in the spec is optional, then any algorithm not mentioned in the spec is optional.
<jcruella> frederick... I should leave now....
<fjh> s/frederick.*$//
<esimon2> I can scribe now if you like.
<tlr> ACTION: thomas to add boilerplate language about optional algorithms [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-217 - Add boilerplate language about optional algorithms [on Thomas Roessler - due 2009-02-24].
<tlr> Scribe: esimon2
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0059.html
<scantor> +q
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html
Sean: Who has reviewed the document? Is concerned about the performance requirement. Wonders what implementations support the specific properties.
fjh: Properties up to a schema;
profile will define their use.
... If no profile, no requirement for implementation.
sean: Concerned about wording
about implementation should fail.
... May need XML Signature to specify property handling.
tlr and fjh: Profiles will define what values mean.
<fjh> tlr properties expect to be commonly used in profile. Common processing here. If profile mandates use, then processing
sean: Java has API for getting signature properties, then app can decide if properties conform or not.
fjh and sean: Problem seems to be that the term "validation" is ambiguous.
<fjh> if property is used then property validation succeeds if ...
Need wording that decouples property validation from core validation.
<fjh> tlr: The interpretation of this property defines a profile, expected application behaviour is to match that profile.
<fjh> tlr expected application behavour is to compare usage URI against expected URI
<scantor> +1
<fjh> tlr expires, expected application behaour to compare against reference time
tlr: replay protection is the only one where behaviour is going to be reasonably universal
<fjh> ACTION: tlr to send proposed changes to properties document on mail list [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-218 - Send proposed changes to properties document on mail list [on Thomas Roessler - due 2009-02-24].
Skipping best practices...
Open action review...
<fjh> http://www.w3.org/2008/xmlsec/track/actions/open
<fjh> close ACTION-105
<trackbot> ACTION-105 Get in touch with RFC 4050 authors closed
close ACTION-122
<trackbot> ACTION-122 Write up more detailed proposal in time for January F2F closed
close ACTION-125
<trackbot> ACTION-125 draft best practice around xpath filter 2 closed
<tlr> pending
close ACTION-164
<trackbot> ACTION-164 Write headings for each section to expand definition, explain not normative etc. closed
<tlr> ACTION-164: OBE
<trackbot> ACTION-164 Write headings for each section to expand definition, explain not normative etc. notes added
<fjh> action 164 was reorg of algs doc, done by Thomas
<trackbot> Sorry, couldn't find user - 164
<tlr> ACTION-164: was reorg of algs doc, done by Thomas
<trackbot> ACTION-164 Write headings for each section to expand definition, explain not normative etc. notes added
<tlr> ACTION-186?
<trackbot> ACTION-186 -- Brian LaMacchia to update proposal language for approval next meeting -- due 2009-02-03 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/186
close ACTION-186
<trackbot> ACTION-186 Update proposal language for approval next meeting closed
close ACTION-191
<trackbot> ACTION-191 Research Appendix A.5.7 (\"Point to Octet String\") conversions for ECC closed
<bal> change
<bal> <complexType name="ECPointType">
<bal> <sequence>
<bal> <element name="X" type="ds:CryptoBinary"/>
<bal> <element name="Y" type="ds:CryptoBinary"/>
<bal> </sequence>
<bal> </complexType>
<bal> to (for example):
<bal> <simpleType name="ECPointType">
<bal> <restriction base="ds:CryptoBinary"/> </simpleType>
<tlr> http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0005.html
<tlr> ACTION: thomas to change schema according to http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0005.html [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-219 - Change schema according to http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0005.html [on Thomas Roessler - due 2009-02-24].
<tlr> ACTION: bal to say on maling list how the EC point is to be converted [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-220 - Say on maling list how the EC point is to be converted [on Brian LaMacchia - due 2009-02-24].
<fjh> RESOLUTION: Accept the changes proposed by Magnus in http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0005.html
Can we public use cases and requirements as first public working draft?
<tlr> RESOLUTION: to publish use case/rec document as FPWD intended to go to Note
<tlr> RESOLUTION: to publish to XML Signature 1.1 as FPWD, intended to go to Rec
<tlr> RESOLUTION: to publish XML Encryption 1.1 as FPWD, intended to go to Rec
<tlr> RESOLUTION: to publish xmlsec-algorithms as FPWD, intended to go to Note
<fjh> XML Signature Transform Simplification: Requirements and Design
<tlr> RESOLUTION: to publish transform requirements as FPWD intended to go to NOTE
<fjh> http://www.w3.org/2008/xmlsec/Drafts/derived-key/derived-keys.html
<tlr> RESOLUTION: to publish derived-keys as FPWD intended to go to Rec
<tlr> RESOLUTION: to publish xml signature properties as FPWD intended to go to Rec, pending agreement to changed validation processing
<fjh> review short names
<tlr> ACTION: thomas to send e-mail on short names; WG review by EOB next day [recorded in http://www.w3.org/2009/02/17-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-221 - Send e-mail on short names; WG review by EOB next day [on Thomas Roessler - due 2009-02-24].
<tlr> RESOLUTION: to publish xml signature best practices as Working Draft