XML Security Working Group Teleconference

21 Sep 2010


See also: IRC log


Cynthia_Martin, Thomas_Roessler, Meiko_Jensen, Frederick_Hirsch, Brian_LaMacchia, Chris_Solc, Bruce_Rich, Hal_Lockhart, Gerald_Edgar, Ed_Simon, Scott_Cantor
Pratik_Datta, Shivaram_Mysore


<trackbot> Date: 21 September 2010

<tlr> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0047.html

<tlr> action-666?

<trackbot> ACTION-666 -- Thomas Roessler to review EXI response to XML Encryption -- due 2010-09-21 -- OPEN

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

<tlr> action-666 due next week

<trackbot> ACTION-666 Review EXI response to XML Encryption due date now next week

<fjh> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0047.html

<tlr> ScribeNick: mjensen


Ed: talk about Magic Signatures?

fjh: added to agenda

<fjh> Please complete WG questionnaire: http://www.w3.org/2002/09/wbs/42458/tpac2010xmlsec/

<fjh> If attending remember to complete TPAC registration (separate from WG questionnaire)

<fjh> http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/

ECC status update

tlr: we'll hear more after this call

Minutes Approval

<fjh> Approve 14 September 2010 minutes

<fjh> http://www.w3.org/2010/09/14-xmlsec-minutes.html

RESOLUTION: Minutes from 14 September 2010 approved.

Editorial Updates

<fjh> Please review completed BestPractices update

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0045.html

<fjh> Meiko reviewed it and noted that it is ok. Also tracker products update completed, please review

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0046.html

Proposal for X509SerialNumber, ACTION-665

<fjh> ACTION-665?

<trackbot> ACTION-665 -- Scott Cantor to devise proposal for X509SerialNumber that does not involve changes to the /2000/09/xmldsig schema. -- due 2010-09-21 -- PENDINGREVIEW

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

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0041.html

tlr: do we want to go with no defaults and then say which algorithms should be mandatory?

hal: SHA-256 should be mandatory

<fjh> +1 to SHA-256 as mandatory algorithm, explicit choice of algorithm allowing future algorithm supprot

<brich> +1

<fjh> are we discussing whether SHA-1 is mandatory to implement? If no default, not an issue?

<scantor> presumably the default algorithm to use in the extension should be one of the MTI algorithms in the spec itself

<fjh> bal notes neither SKI generation or SHA-1 defined in X.509 spec

fjh: question is whether support for SHA-1 is mandatory or optional.

<fjh> if alg is explicit then sha-1 issue not a big deal, no default, make sha-1 optional

<fjh> bal notes that if we have two X509Digest elements in parallel to have two different hash values then element reuse might be hard

<fjh> suggests we might want element definition that could have more than one

<scantor> I don't understand that argument, so would suggest sending something to list

<scantor> nothing else in KeyInfo is done that way, so I can't imagine we'd start with this one

<scantor> (sorry I can't call in, I'm in a meeting)

<tlr> +1 to taking this to the mailing list

<bal> we don't use raw hash values in X509Data anywhere

<bal> i'll send a msg to the list

<tlr> I'll follow up to bal

<bal> (anywhere else)

discussion is continued on the list

<fjh> magnus reiterates that SHA-1 is deprecated and should not have default, agreeing

Namespace injection paper

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0050.html

<fjh> suggestion that XPath profile could require rewrite of XPath expression to create prefix-free expression to address namespace injection attack

put to the list

due to copyright issues paper will be kept in member space

Additional action and Issue Review

<fjh> please complete your actions

<fjh> Open actions are listed in Tracker at <http://www.w3.org/2008/xmlsec/track/actions/open

Magic Signatures

<fjh> Ed's review: http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0049.html

Ed got responses from the magic signatures' spec maintainers

hal: agrees with Ed's inputs to their document
... but where would that appear?
... they made a lot of work to get magic signatures bullet-proof somewhat

<fjh> hal: two requirements addressed by magic signature and not XML Sig - 1. express signature meta data in non-XML form, 2. enable validation in despite varieties of processing

ed: we should have a separate document relating XML Signatures to magic signatures

<scantor> if you insist on detached or enveloping signatures and sign only blobs, XML signature gets easy too

fjh: XML Signature is meeting different requirements, no bad or good

ed just sent an email to them with more comments

<fjh> http://salmon-protocol.googlecode.com/svn-history/r109/trunk/draft-panzer-magicsig-experimental-00.html

Proposal for X509SerialNumber, ACTION-665 (again)

<fjh> need clarity in spec and also reuse of element in other contexts

<fjh> scott notes granularity of re-use is KeyInfo, not components of KeyInfo

<fjh_> ACTION: fjh to add link to Meiko's paper (member only) and reference to web site [recorded in http://www.w3.org/2010/09/21-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-670 - Add link to Meiko's paper (member only) and reference to web site [on Frederick Hirsch - due 2010-09-28].

Summary of Action Items

[NEW] ACTION: fjh to add link to Meiko's paper (member only) and reference to web site [recorded in http://www.w3.org/2010/09/21-xmlsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/09/30 12:19:29 $