See also: IRC log
<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/
tlr: we'll hear more after this call
<fjh> Approve 14 September 2010 minutes
<fjh> http://www.w3.org/2010/09/14-xmlsec-minutes.html
RESOLUTION: Minutes from 14 September 2010 approved.
<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
<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
<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
<fjh> please complete your actions
<fjh> Open actions are listed in Tracker at <http://www.w3.org/2008/xmlsec/track/actions/open
<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> 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].