See also: IRC log
<trackbot> Date: 03 February 2009
<fjh> trackbot-ng, start telcon
<trackbot> Meeting: XML Security Working Group Teleconference
<trackbot> Date: 03 February 2009
<tlr> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0081.html
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0000.html
<fjh> Next meeting 10 Feb - Konrad Lanz to scribe,
<fjh> 17 Feb, Juan Carlos Cruellas scheduled to scribe
<fjh> 17 Feb, Juan Carlos Cruellas scheduled to scribe
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0000.html
<fjh> 2-6 NovemberTPAC2009, Santa Clara Marriott, Santa Clara, CA, USA
RESOLUTION: Plan to have a F2F Meeting with November TPAC in Santa Clara
<fjh> FIPS-186-3 (DSAwithSHA256) status:
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0076.html
<fjh> W3C 3rd Party Licensing Commitments material
<fjh> http://www.w3.org/2004/01/pp-impl/42458/nmlc
tlr: should be done in weeks or
at most a couple of months
... would like to have a reference to an actual document (not a
forward reference to a future doc)
minutes approval ...
RESOLUTION: Minutes from F2F, 13-14 January 2009 approved
RESOLUTION: Minutes from 27 January 2009 approved
fjh: added issue to add algorithms "XPATH 2 Filter" and "Exclusive Canonicalization" to the list in section 6.0 of XML Signature 1.1
<esimon2> agreed
csolc: what is requirement?
... SHOULD, MUST?
... for xpath filter 2
<esimon2> http://www.w3.org/TR/xmldsig-filter2/
tlr: it is recommended
... section 6.6
<fjh> http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-TransformAlg
<tlr> http://www.w3.org/TR/xmldsig-core/#sec-TransformAlg
<csolc> +1 to brian
bal: proposal is to add these to recommended sections for transform and c14n? (but not required)
fjh: should exc c14n be required?
<fjh> bal notes add exclusive to canonicalization in 6.1, add xpath filter 2 to transform in 6.1 plus other text
tlr: exc does not have problems with xml:id
bal: having 3 required c14n algs none of which are very efficient seems a bit overkill
<bal> adding these two algs means we have to update the lists in section 6.1 to include both exc-c14n and xpath filter 2 as Recommended
RESOLUTION: add exc c14n alg as recommended to xml signature 1.1
<bal> and then we have to add text to sections 6.5 and 6.6
<fjh> in section 6.1
<Zakim> Thomas, you wanted to ask about xpath filter
tlr: in best practices say xslt is bad idea to use/accept it and xpath is inefficient, use xpath 2 instead so ...
should we change xslt and xpath transform requirements?
csolc: if we move xpath to
optional should we change xpath 2 to optional?
... because implemented using xpath?
tlr: xpath 2 is more useful in
practice
... recommend that xpath 2 is the one of the two that you want
to pick
fjh: (not as chair) 1.1 should be more consistent with 1.0, should we be more conservative with changes?
<tlr> XSLT -> optional?
<klanz241> Hello, I have about 30 minutes to call in ...
<scribe> ACTION: tlr draft text on section 6.1 about XPath, XPath Filter 2 and XSLT best practices [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-196 - Draft text on section 6.1 about XPath, XPath Filter 2 and XSLT best practices [on Thomas Roessler - due 2009-02-10].
<tlr> XPAth filter 2 -> recommended?
<tlr> xpath filter -> optional?
<fjh> Updated with algorithms section
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0075.html
<fjh> please review this
fjh: updated alg. section of requirements doc, please review
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm
fjh: editors, do we need to walk-thru changes?
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview_diff.htm
tlr: versioning namespace section
...
... section 1.3
<tlr> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Versions
tlr: look at editor's draft
... added ec key value example
... moved around versioning material
... please review
<tlr> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-CoreSyntax
<fjh> All please review 1.3 in sig 1.1
tlr: section 4 added new schema 2009
<tlr> &dsig;
tlr: few more edits referring to 2006 namespaces with the new 1.1 prefix
<csolc> do we also want to update the list of contributors
<csolc> for 1.1
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0055.html
scantor: proposed deprecation text for AI but not convinced its what people wanted
<csolc> +1
scantor: add first paragraph only from text
RESOLUTION: add first paragraph from Scott's RetrievalMethod proposal to section 4.4.3
<scribe> ACTION: fjh to add first paragraph from Scott's RetrievalMethod proposal to section 4.4.3 [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-197 - Add first paragraph from Scott's RetrievalMethod proposal to section 4.4.3 [on Frederick Hirsch - due 2009-02-10].
<scribe> ACTION: fjh to add exc c14n to 6.1 of XML Sig 1.1 [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-198 - Add exc c14n to 6.1 of XML Sig 1.1 [on Frederick Hirsch - due 2009-02-10].
<fjh> Update examples use of algorithms
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0067.html
RESOLUTION: accept Sean's change to examples for 1.1
<scribe> ACTION: fjh to make changes to examples for 1.1 [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-199 - Make changes to examples for 1.1 [on Frederick Hirsch - due 2009-02-10].
<fjh> Schema cleanup
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0080.html
tlr: action 151 done
<fjh> additional suggestions were also completed as well.
<fjh> ECC Algorithms Schema update
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0068.html
<fjh> also, consistency of style of XML Signature schema?
magnus: not that current proposal
doesn't work but my proposal has addl benefits
... extensibility
... modularity, consistency
fjh: how do we move forward?
<fjh> bal against penalty if not used
bal: don't want to pay penalty of adding second type where it won't be used
magnus: there is possibility and
already adding a number of new types anyway
... don't always know about future usage
bal: exist in 4050 but nobody uses them, everyone useds name curves
klanz: smart card impls may use something not mainstream, do we want to lock them out?
magnus: certain future usages may
be harder with current proposal
... make both proposals and get feedback from public
bal: object to having 2 in
draft
... some impls in pipeline may need to start ecc support
magnus: would like to see two proposals in doc
bal: we should only have one
fjh: revisit topic next week
I agree an extra week to review would be great
<bal> <element name="ECKeyValue" type="dsig11:ECKeyValueType"/>
<bal> <complexType name="ECKeyValueType">
<bal> <sequence>
<bal> <choice>
<bal> <element name="ECParameters" type="dsig11:ECParametersType"/>
<bal> <element name="NamedCurve" type="dsig11:NamedCurveType"/>
<bal> </choice>
<bal> <element name="PublicKey" type="dsig11:ECPointType"/>
<bal> </sequence>
<bal> </complexType>
<tlr> Scott has a point there
<scribe> ACTION: magnus to send an email showing details on how proposal is different [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-200 - Send an email showing details on how proposal is different [on Magnus Nyström - due 2009-02-10].
<klanz241> s/what is there/TBD/
<klanz241> @tlr, and has the same effect as having no WD ...
<fjh> where we are at - prefer one choice? but have different views of which?
<fjh> tlr if we can demonstrate 2nd use case, then magnus approach would be viable
tlr: lets make clear plan to resolve this next week
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0078.html
tlr to check on this issue
<bal> i thought these got fixed in the current versions...
tlr: this is probably done
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0070.html
bhill: not aware of any use cases that can be exploited
<tlr> +1
fjh: not sure whether we should do this in 1.1
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0071.html
fjh: konrad sent a bunch of material
konrad: think previous work was too careful with whitespace
<fjh> http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#nameddest=subsection.4.1.3
konrad: reference can be made robust against whitespace
<fjh> http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#nameddest=subsection.4.2.1
konrad: suggest removing whitespace parameter for c14n in future
<fjh> this is 2.0 issue
konrad: could be 1.1 issue
csolc: 1.1 minimal changes, not
new transforms, sounds like 2.0 thing
... rather be more restrictive for now, defer stripping til
2.0
klanz: small step just optional parameter
tlr: don't want any more optional features
<klanz241> @tlr, please use arguments not feelings ...
tlr: are you suggesting c14n with ws removal would apply generally to documents?
<klanz241> http://www.w3.org/TR/xmldsig-core/#sec-CanonicalizationMethod
<klanz241> just needs an identifier
fjh: suggest we defer to
2.0
... requires more thought
<tlr> klanz241, the argument is there is a too large set of optional features already, therefore "abhor"
fjh: make a concrete proposal to what would change in 1.1
<scribe> ACTION: konrad to make concrete proposal on insignificant whitespace c14n for 1.1 [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-201 - Make concrete proposal on insignificant whitespace c14n for 1.1 [on Konrad Lanz - due 2009-02-10].
scantor: is just for
SignedInfo?
... not sure I see the benefit
<csolc> +1
<klanz241> Proposal: Add a parameter to C14n that allows the removal of pure whitespace nodes
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0074.html
fjh: is ACTION-176 best for BP or for spec itself?
scott: there is stuff there, good enough what we have
fjh: so we don't need to deal with this one
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/
fjh: updated speling
mitsakes
... next topic on this one was key wrapping
... this is from thomas
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0042.html
http://www.w3.org/TR/xmlenc-core/#sec-Alg-SymmetricKeyWrap
http://www.w3.org/TR/xmlenc-core/#sec-Alg-SymmetricKeyWrap
tlr: do we need to duplicate
algorithm description, is it different?
... additionally, input 64 bits, but draft for new version with
padding, create uris for that
... should we deprecate existing keywrap and switch to padded
key wrap
fjh: both 5.6.2 and 5.6.3?
tlr: yes, but need to check AES reference
<bal> rfc was informational, no guarantee standards track
<tlr> current AES key wrap RFC: http://tools.ietf.org/html/rfc3394
<tlr> http://tools.ietf.org/html/draft-housley-aes-key-wrap-with-pad-00#ref-AES-KW1
bal: suggest stick with what cms
uses, code already exists, not go with new algs
... copied since we did not want to reference informational
rfcs, wanted to have stable normative text
magnus: keyprov ietf group need keywrap with different lengths, argument for new padding
<magnus> keyprov ietf group needs key wrapping
<bal> issue with referencing infor. rfcs
<scribe> ACTION: tlr to check on issue with referencing informational RFCs for material in XML Encryption [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-202 - Check on issue with referencing informational RFCs for material in XML Encryption [on Thomas Roessler - due 2009-02-10].
<tlr> cannot ref internet draft from candidate or proposed but ok from working draft
http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0077.html
bal: is new padding scheme backward compatible
http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0050.html
<fjh> do we need suite b ref?
<magnus> do we have right ref?
http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0016.html
additional discussion, did reference change impact schema, if so then may need to update reference
magnus: encode as in RFC3279
action bal check on proper EC Point conversion reference
<trackbot> Created ACTION-203 - Check on proper EC Point conversion reference [on Brian LaMacchia - due 2009-02-10].
magnus: issue with hash component missing in schema
<tlr> bal: specification of hash used to validate seems to have been change that was made between different versions of X.962
bal: repeats what magnus said, Domain Parameters missing hash, 962 has newer version
magnus: use newer version of 962 as base
<tlr> bal: support having hash function agility
bal: need hash algorithm algorithm
<scribe> ACTION: bal to review new 962 and review hash proposal from magnus [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-204 - Review new 962 and review hash proposal from magnus [on Brian LaMacchia - due 2009-02-10].
<tlr> ACTION: bal to review new version of 962 and work with magnus on proposal [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-205 - Review new version of 962 and work with magnus on proposal [on Brian LaMacchia - due 2009-02-10].
<tlr> ACTION-205 closed
<trackbot> ACTION-205 Review new version of 962 and work with magnus on proposal closed
<tlr> not ready for publishing
http://www.w3.org/2008/xmlsec/Drafts/xmlsec-algorithms/Overview.html
<tlr> ... can try to make progress ...
tlr: include mandatory etc , look at 1st half for idea of approach
<tlr> if make progress then likely to happen this week, if not early next week
http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0065.html
<fjh> pratik sent out summary of changes
<scantor> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0000.html
<fjh> look at changes and draft for next week
Signing HTTP messages
http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0040.html
<scantor> just wanted description for now if we need to go back later
<scantor> .. for 2.0 maybe
<fjh> but better to be in doc?
<scantor> referencing based on uris
<scantor> ... uris maybe not best way to solve this problem
<scantor> ... inclined to wait til 2.0 because ref model will change
defer to when we have 2.0 discussions of referencing models
http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/
http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0038.html
<fjh> section 2.4.3 not really about replay attacks
<smullan> ... suggest it be a higher level topic
<smullan> RESOLUTION: make long-lived signatures a new best practices topic
<smullan> ACTION: fjh to make long-lived signatures a new best practices topic [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-206 - Make long-lived signatures a new best practices topic [on Frederick Hirsch - due 2009-02-10].
http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0054.html
<smullan> +1
<smullan> RESOLUTION: accept Scott's proposal on schema normalization best practice
<smullan> ACTION: fjh to incorporate Scotts proposal on schema normalization best practice [recorded in http://www.w3.org/2009/02/03-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-207 - Incorporate Scotts proposal on schema normalization best practice [on Frederick Hirsch - due 2009-02-10].