See also: IRC log
<trackbot> Date: 14 September 2010
<scribe> ScribeNick: csolc
<scribe> Scribe: Chris Solc
<fjh> updated roadmap, please review http://lists.w3.org/Archives/Member/member-xmlsec/2010Sep/0004.html
fjh has update the road map.
<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/
<fjh> ACTION-652?
<trackbot> ACTION-652 -- Thomas Roessler to request conference bridge for XML Security TPAC F2F meeting -- due 2010-10-01 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/652
meeting planning
<fjh> meetings on 5, 12 October cancelled, http://lists.w3.org/Archives/Member/member-xmlsec/2010Sep/0006.html
<fjh> cancel 9 November (week after F2F), and 23 November
RESOLUTION: : meeting canceled for 9 and 23rd November calls
<fjh> Widget Signature test case review and help
<fjh> Opera would like to announce the first release of the test suite for the Digital Signatures for Widgets specification [1]. The test suite is here: http://dev.w3.org/2006/waf/widgets-digsig/test-suite/ The WebApps WG is seeking review of the test cases from members of XMLSec and WebApps, the community at large, as well as any vendors who are implementing. The deadline for comment is the 30th of September."
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0021.html
<fjh> Seeking help generating test with ECDSAwithSHA256 sig
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0022.html
<fjh> Approve 7 September 2010 minutes
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Sep/att-0005/minutes-2010-09-07.html
RESOLUTION: Minutes for 7 September approved
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0025.html , ACTION-649, ACTION-650, ACTION-651
fjh: in effect we are replacing the second edtion spec with the 1.1 spec.
scantor: each new version of the spec is associated namespace of the schema.
fjh: the namespace uri is associated with the schema based on the current spec
tlr: we are leaving the
discussion about errata
... what should whe have the uri for the namespace point
to.
<fjh> tlr proposal: The normative situation should be that X509SerialNumber is a facet of xsd:string, with appropriate constraints on the lexical space.
<fjh> bal concern re existing bindings
bal: more confused by tlr
message
... the normative meaning of the namespace changes everytime we
publish the spec
tlr: that is correct
bal: how are users supposed to write software when the namespce points to different schemas.
<fjh> scantor: if lexical space is the same, then cannot receive content that differs from what was allowed earlier
tlr: we are changing the schema so that signatures validate.
bal: do users use the current
schema to generate their data bindings?
... is worried about the data bindings because now internally
the values is represented as a string instead of a number
<tlr> not parsers -- schema validators
<fjh> magnus - this is limitation on xml parsers, not a problem with ASN.1
<tlr> "new type" = "new element"?
magnus: what would be cleaner is to define a new type for serial number
<fjh> would there be confusion of which to use if new type is added
<tlr> Deprecate the old element, add a new one to the xmldsig11 name space.
<fjh> tlr: not xml parser, but validator is concern
<fjh> pratik notes this is a concern for implementation, in java integer will map to big int, string will map to string in data binding, makes a difference despite facet
<tlr> indeed
scantor: to ensure exsting impementations they can keep a local copy of the schema
tlr: when we look at signature
validation, do not want schema validation
... we probably don't want to validate the schema
scantor: we don't say not to validate, they say to be careful when validating
<Zakim> fjh, you wanted to ask about confusion about new type
<fjh> scantor notes validation is tied to id processing, so hard to just drop validation, hence also complicated code
<fjh> discussion about possibility to replace X509SerialNumber with new alternative element
<fjh> could also argue not to recommend using this
should use a hash of the cert or ski instead of serial number.
<fjh> alternate proposal - add new element as alternative, deprecate use of IssuerSerialNumber and recommend hash of cert or SKI instead
<tlr> ACTION: scantor to devise proposal for X509SerialNumber that does not involve changes to the /2000/09/xmldsig schema. [recorded in http://www.w3.org/2010/09/14-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-665 - Devise proposal for X509SerialNumber that does not involve changes to the /2000/09/xmldsig schema. [on Scott Cantor - due 2010-09-21].
<fjh> ACTION-655: propose to add new element to X509IssuerSerial as replacement for X509SerialNumber, text to deprecate X509SerialNumber
<trackbot> ACTION-655 Start email thread on which parameters to be treated as group notes added
<fjh> ACTION-655: also propose text to promote use of hash of cert or SKI etc
<trackbot> ACTION-655 Start email thread on which parameters to be treated as group notes added
Hal: thumb print has an advantage because it doesn't require any thing special in the cert
<tlr> sure
<tlr> ACTION: thomas to review EXI response to XML Encryption [recorded in http://www.w3.org/2010/09/14-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-666 - Review EXI response to XML Encryption [on Thomas Roessler - due 2010-09-21].
<fjh> ACTION-666: http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0030.html
<trackbot> ACTION-666 Review EXI response to XML Encryption notes added
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0024.html
http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0024.html (Meiko)
<fjh> meiko notes that the example made it clear that this is getting more complicated, especially with regards to choices of C14N parameters
fjh: do we need the old backward compatibility options.
<tlr> so let's kill that option
<fjh> pratik notes we might not need options around comments, could simplify there
<fjh> we should simplify where we can
fjh: why do we need to be backward compatible.
<fjh> discussion of how to simplify c14n2
<Gerald-E> To make a decision to desice on what is mandatory.
<fjh> suggestion to determine what is mandatory, and what is optional, consider removing optional
scantor: canonicalization shouldn't have options.
tlr: should have a hard look at params and see if we can remove any options.
hal: have two conflicting goals, an easy to implement spec and an easy to use spec
<tlr> comments, exclusiveMode, ...
http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0013.html (Meiko)
meiko: do we want to optimize for signer or verifier
hal: before you start processing you need to know algorithm.
fjh: could just put a warning in
the doc
... signing out of the box may not work in one pass....
... is there a problem putting this in the doc:
pdatta: should put this in the doc
fjh: may want to talk about reciever and sender issues.
pdatta: in applications shouldn't process the data untill the signature is verified. therefore 2 pass
fjh: we should add it to the doc.
<fjh> ACTION: pdatta to add text regarding potential 1-pass issues to XPath document, using proposal from Meikohttp://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0013.html [recorded in http://www.w3.org/2010/09/14-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-667 - Add text regarding potential 1-pass issues to XPath document, using proposal from Meikohttp://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0013.html [on Pratik Datta - due 2010-09-21].
<fjh> proposed RESOLUTION: Add text to XPath document regarding 1-pass issues, using proposal from Meiko as starting point
RESOLUTION: Add text to XPath document regarding 1-pass issues, using proposal from Meiko as starting point
http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0026.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0026.html
fjh: is it worth mandating an
algorithm
... signed info is a special case
<fjh> meiko why have parameters in 2.0 mode for SignedInfo
scantor: we have the same issues with whitespace in signed info.
<fjh> proposed RESOLUTION: ISSUE-183 can be closed with no action
RESOLUTION: ISSUE-183 can be closed with no action
<fjh> issue-183 closed
<trackbot> ISSUE-183 Constrain 2.0 SignedInfo canonicalization choice for 2.0 model? closed
http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0014.html (Meiko)
RESOLUTION: Adopt the proposed update http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0014.html (Meiko)
<fjh> ACTION: fjh to update best practices with proposal from Meiko [recorded in http://www.w3.org/2010/09/14-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-668 - Update best practices with proposal from Meiko [on Frederick Hirsch - due 2010-09-21].
<Gerald-E> I may be able to attend in person, but I still need aproval
http://www.w3.org/2002/09/wbs/42458/tpac2010xmlsec/
<fjh> http://www.w3.org/2002/09/wbs/42458/tpac2010xmlsec/results
please propose ideas for the agenda.
there is a publication freeze a week before TPAC
<fjh> roadmap http://www.w3.org/2008/xmlsec/wiki/Roadmap
fjh: would like to go to last call at TPAC
brich: should reserve a couple of hours for interop issues.
<fjh> ACTION-604?
<trackbot> ACTION-604 -- Hal Lockhart to propose change for best practices for ISSUE-170 -- due 2010-07-06 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/604
<fjh> ISSUE-170?
<trackbot> ISSUE-170 -- Should we recomend signing namespaces as part of Best Practice 12 (dependency on ACTION-538) -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/170
<fjh> scantor : signing namespace declaration is impossible due to c14n
hal: what is the issue, signing namespaces, the prefix, the namspace uri or the content that the namespace uri points too.
<fjh> meiko: sign namespace declarations in specific way, prefix
<fjh> hal: both changes to spec and best practices are possible, what should we do for best practices
<fjh> can we give advice related to attacks related to namespaces
<Cynthia> is this part of the paper: http://www.balisage.net/Proceedings/vol5/html/Kay01/BalisageVol5-Kay01.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0002.html
<Ed_Simon> "The curse of namespaces in the domain of XML signature": http://portal.acm.org/citation.cfm?id=1655129
<Cynthia> I think the one I have is the wrong one, sorry...
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Aug/0006.html
<scantor> http://lists.w3.org/Archives/Public/public-xmlsec/2009Nov/att-0019/Camera-Ready.pdf
<fjh> Analysis of Signature Wrapping Attacks and Countermeasures
<fjh> Two issues need, one whether to change spec, other to change best practices, raise issues based on review of paper to be distributed by Meiko, also above paper.
<fjh> consider refining and/or closing ISSUE-170, ACTION-604, ACTION-538
<fjh> ISSUE-170?
<trackbot> ISSUE-170 -- Should we recomend signing namespaces as part of Best Practice 12 (dependency on ACTION-538) -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/170
<fjh> this one is focused on best practices only
<fjh> ACTION-538?
<trackbot> ACTION-538 -- Meiko Jensen to provide proposal related to namespace wrapping attacks once XPath profile available -- due 2010-03-09 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/538
<fjh> ACTION-604?
<trackbot> ACTION-604 -- Hal Lockhart to propose change for best practices for ISSUE-170 -- due 2010-07-06 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/604
<fjh> ACTION: fjh to update list of tracker products to be more sensible [recorded in http://www.w3.org/2010/09/14-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-669 - Update list of tracker products to be more sensible [on Frederick Hirsch - due 2010-09-21].
please look at issues and actions.
there is a meeting next week