XML Security Working Group Teleconference
08 Dec 2009

Date: 08 December 2009

Administrative

fhirsch: There is no change to the agenda.
Can there be any more changes made before last call?

tlr:Can there be some commitment for review before last call

fhirsch: Should last call be moved out to Jan?

<fhirsch> web security mailing list

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0001.html

<fhirsch> focus on browser facing side of security but other topics related to web security

trl: forum to talk about general issues about web security topics

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0004.html

fhirsch, watch for fishing spam on the w3c mailling lists

Minutes Approval

<fhirsch> 17 November, updated

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Dec/att-0007/17-xmlsec-minutes.html

RESOLUTION: 17 November minutes approved

<fhirsch> 24 Nov

<fhirsch> http://www.w3.org/2009/11/24-xmlsec-minutes.html

RESOLUTION: 24 November minutes approved

tlr: will move minutes into the correct places on the web site

Editorial updates

<fhirsch> converted signature 1.1 and encryption 1.1 to re-spec

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0014.html

fhirsch: TOC will be updated automatically, header page and bibliography have also been updated

Call for members to review changes.

fhirsch: xml signature 1.1 has RNG schema material, encryption has placeholder
... is there anyone available to review the RNG schema sections?

<fhirsch> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Schema

BSP Review

<fhirsch> ACTION: Frederick to forward BSP comments to Paul cotton [recorded in http://www.w3.org/2009/12/08-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-458 - Forward bsp comments to paul cotton [on Frederick Hirsch - due 2009-12-15].

Management Data

<fhirsch> issue-157?

<trackbot> ISSUE-157 -- Xml signature 1.1 section 4.10 The MgmtData Element refers to non-existent XML Encryption WG -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/157

fhirsch: trl proposed dropping this sections

<fhirsch> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-MgmtData

<fhirsch> The <xenc:EncryptedKey> and <xenc:Agreement> elements defined in [XMLENC-CORE1] as children of ds:KeyInfo can be used to convey in-band key agreement information, or encrypted key material.

fhirsch: should remove the existing paragraph on MgmtData and replace it with the text entered above, keep type and schema, add Use of the MgmtData element is deprecated.

<fhirsch> part 2 - add new section, Conveying Key Information, with text above

fhirsch: don't think this would prevent last call

RESOLUTION: the MgmtData changes are accepted

<scribe> ACTION: fjh Edit Signature 1.1 with the MgmtData changes [recorded in http://www.w3.org/2009/12/08-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-459 - Edit Signature 1.1 with the MgmtData changes [on Frederick Hirsch - due 2009-12-15].

<tlr> +1 to cancelling these two calls

RESOLUTION: 29 December meeting canceled

tlr: no status update on ECC
... probably won't have much to report this year.

Requirements

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Dec/0003.html

shivaram: signature 1.1 requirements are ok.

<fhirsch> ACTION: fjh look if diff of 1.1 editors draft from 2nd edition is possible [recorded in http://www.w3.org/2009/12/08-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-460 - Look if diff of 1.1 editors draft from 2nd edition is possible [on Frederick Hirsch - due 2009-12-15].

shivaram will look at the encryption requirements in the next week

Last call for Signature 1.1

should we go to last call next week or wait until Jan?

fhirsch: given there is no compelling reason to go next week, and to avoid any mistakes maybe we should wait.

RESOLUTION: last call for signature 1.1 will be Jan 5

XML Encryption 1.1

<fhirsch> issue-155?

<trackbot> ISSUE-155 -- Add AES-GCM to XML Encryption 1.1 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/155

AES-GCM status?

<fhirsch> need to resolve tag issue

fhirsch:what is the status of concatKDF

pdatta: sha algorithm does work with bit strings

brich: is there an algorithm that supports this?

<fhirsch> Bruce notes bit string hash not available on java implementations

<fhirsch> is there a possible inter-op issue with bit strings, versus bytes

fhirsch: we should wait on this, to see on who can actually implement this.

EXI and XML Encryption

<tlr__> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0005.html

<tlr__> action-439?

<trackbot> ACTION-439 -- Thomas Roessler to draft text for xml encryption 1.1 for handing EXI -- due 2009-12-01 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/439

<scribe> ACTION: brich Start a discussion on the list about concatKDF bit string hash interoperability issues [recorded in http://www.w3.org/2009/12/08-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-461 - Start a discussion on the list about concatKDF bit string hash interoperability issues [on Bruce Rich - due 2009-12-15].

<fhirsch> http://www.w3.org/TR/xmlenc-core1/#sec-Processing-Encryption

<Zakim> fhirsch, you wanted to ask about last sentence

tlr: looking for a reviewer

<fhirsch> I can take a look

<fhirsch> at end of Dec

esimon: should get implementers to do a review

<fhirsch> issue-141?

<trackbot> ISSUE-141 -- C14N 1.1 processing of non-element, non-PI nodes in a node set -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/141

<tlr__> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0007.html

<fhirsch> proposed resolution - accept proposed ISSUE-141 resolution

<tlr__> ACTION: Thomas to add ISSUE-141 erratum to C14N 1.1 errata [recorded in http://www.w3.org/2009/12/08-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-462 - Add ISSUE-141 erratum to C14N 1.1 errata [on Thomas Roessler - due 2009-12-15].

HMACOutputLength erratum

RESOLUTION: accept the proposed change by tlr for ISSUE-141

<fhirsch> HMAC output length

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0010.html

<tlr__> For best interoperability, signature applications SHOULD set the HMACOutputLength parameter to a value that is a multiple of 8. If the HMACOutputLength parameter is not divisible by 8, verifiers MAY use the nearest multiple of 8 that is smaller than HMACOutputLength instead; the previous considerations about minimum values for HMACOutputLength apply. This optional cut-off is equivalent to ignoring the rightmost 1-7 bits of the HMAC's output.

<tlr__> ACTION: Thomas to add HMAC erratum to signature 1.0 action [recorded in http://www.w3.org/2009/12/08-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-463 - Add HMAC erratum to signature 1.0 action [on Thomas Roessler - due 2009-12-15].

<fhirsch> action-436?

<trackbot> ACTION-436 -- Thomas Roessler to review requirements for issue-63 text -- due 2009-12-01 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/436

RESOLUTION: The Above text is accepted for the HMAC output Length Erratum

<scantor> http://lists.w3.org/Archives/Public/public-xmlsec/2009Nov/0050.html

ACTION-434

<fhirsch> action-434?

<trackbot> ACTION-434 -- Scott Cantor to propose "final" disposition of Referencing syntax -- due 2009-11-13 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/434

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Nov/0050.html

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Nov/0051.html

<fhirsch> proposal to move URI into transform selection, define what absence of URI attribute means at top level

fhirsch:shouldn't reproduce all the bizarre rules in the old spec.

fhirsch:does any one use the missing uri today?

<fhirsch> smallest change to existing text is to leave URI out at top level, no need to update that model then, e.g. with ids and fragments etc

<fhirsch> new text in selection can be simple and clean, since not backward compatible

<fhirsch> scott notes concern is that #id throws away comments

<fhirsch> what is risk if URI removed from Reference element for new transform

scantor: we can't change what #id and xpointer(id) for backwards compatibility reasons.

<fhirsch> if URI not at Reference then new model, risk that old code omitted, but Scott suggests not common case

<fhirsch> Sean notes if no URI now, then need specific deference code, so Scott notes that could switch between models based on transforms needed

RESOLUTION: We will remove the uri from the reference element and put in the transform element.

Namespace wrapping attack

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0012.html

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0022.html

pdatta: if have an xpath filter then you are venerable
This is because the Namespace prefixes can be stripped out be the canonicalization algorithm.
Thus thus they wouldn't be covered by the signature.
In turn this would allow some one to change the namespace uses by the signature prefix
This is an issue for signature 1.0 and 1.1

<fhirsch> ed propose namespace declarations on xpath transforms be signed, for 1.1 and 1.0

<fhirsch> ed checking if that is sufficient

ed:if you declare the namespace in the signed info then the namespaces are signed.

<fhirsch> Scott notes you have to be careful, inclusive might not be used for SignedInfo

fhirsch:only if you use inclusive canonicalization

fhirsch:should we ask the university investigating this issue be invited to the working group?

<fhirsch> primarily best practices issue, though possibly unclear in spec