See also: IRC log
Date: 08 December 2009
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
<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
<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
<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].
<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.
<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
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
<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.
<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].
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
<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.
<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