See also: IRC log
<trackbot> Date: 27 July 2010
<scribe> scribenick: pdatta
<fjh> Please complete WG attendance questionnaire as well as TPAC registration if attending in person:
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Jul/0001.html
<fjh> New WG member: Nan Ma, China Electronics Standardization Institute
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0013.html
<fjh> Magic signatures
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0016.html
cynthia: Magic signatures works with java, pgp, works in small low bandwith, memory constrained
<fjh> I do not think the positioning of magic signatures is good - it does not make clear what it cannot do, and makes it sound like xml signature is not useful.
ed: magic signature doesn't worry about canonicalization
<fjh> the introduction is misleading - makes it sound like xml signature is not useful or needed
<fjh> W3 and XML Security WG should respond?
fjh: we should have a response from the working group
<fjh> WG members agree that we need a response to this
<fjh> ACTION: fjh to initiate feedback response to Magic Signatures [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-608 - Initiate feedback response to Magic Signatures [on Frederick Hirsch - due 2010-08-03].
<fjh> ACTION: esimon2 to review Magic Signatures and comment [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-609 - Review Magic Signatures and comment [on Ed Simon - due 2010-08-03].
<fjh> ACTION: cynthia to review magic signatures and comment [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-610 - Review magic signatures and comment [on Cynthia Martin - due 2010-08-03].
<fjh> http://www.w3.org/2010/07/06-xmlsec-minutes.html
RESOLUTION: minutes from 6th of July are approved
<fjh> No new status
<fjh> ACTION-585?
<trackbot> ACTION-585 -- Thomas Roessler to review proposal for LC-2387 -- due 2010-07-31 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/585
<fjh> ACTION-549?
<trackbot> ACTION-549 -- Scott Cantor to provide proposal related to generic parameter relatedto xsiTypeAware -- due 2010-04-20 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/549
<scantor> proposal ready for inclusion in c14n 2, with the minor correction
<scantor> the signature half needs to go in a location where the option syntax within C14NMethod is defined
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0023.html
<fjh> proposed RESOLUTION: Accept Scotts proposal (as revised) http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0023.html
<scantor> we also would need to add the CURIE reference to the c14n spec
RESOLUTION: Accept Scotts proposal (as revised) http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0023.html and add CURIE reference
<fjh> ACTION: pdatta to update c14n2 with proposal and CURIE reference [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-611 - Update c14n2 with proposal and CURIE reference [on Pratik Datta - due 2010-08-03].
<scantor> I was assuming this would replace the xsi:type aware option that's there now
<scantor> just saying that could be a seperate decision
<scantor> don't need to, just wanted to make sure it was understood
<scantor> is the syntax for the options in fact missing from sig 2.0 yet?
<fjh> scott notes need for syntax/option on signature side
<scantor> I couldn't find it in the draft
<fjh> scott notes need for schema and explanation text
section 3 in C14N 2.0 has the schema http://www.w3.org/2008/xmlsec/Drafts/c14n-20/Overview.html#sec-Use
<scantor> I think sec 3 needs to be in sig 2.0
<scantor> this creates a circular dependency
<scantor> I missed this section initially, sorry
<scantor> I will propose this be moved, and add text and schema for the new option
In 1.0 time, the schema for the InclusiveNamespacePrefix was in C14n doc
<scantor> so the circular reference is ok?
<scantor> (I think you're right, though, I forgot we moved it)
<scantor> yes, I didn't mean the options would be general
<scantor> anyway, I'll drop it, I can just extend sec 3 here
<scantor> yes, I was asking if W3C was ok with the documents referencing each other?
<scantor> ok
<scantor> ok, give me an action to extend sec 3
<fjh> ACTION: scantor to extend section 3 of C14N2 to deal with options related to ACTON-549 proposal [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-612 - Extend section 3 of C14N2 to deal with options related to ACTON-549 proposal [on Scott Cantor - due 2010-08-03].
<fjh> ACTION-576?
<trackbot> ACTION-576 -- Pratik Datta to add "high performance profile" to c14n2 -- due 2010-06-22 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/576
<fjh> schema update, open action on tlr, ACTION-600
<fjh> ACTION-600?
<trackbot> ACTION-600 -- Thomas Roessler to draft proposal of how update to 1.0 schema will work practically for existing implementations -- due 2010-07-31 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/600
<fjh> Indicate number of bytes digested for each ds:Reference?
<fjh> "the ds:DigestMethod child element that identifies the digest algorithm is element extensible"
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0014.html
mjensen: idea is good, but where to put in the number of bytes? gave up, only option is to add a new transform
<fjh> the ds:DigestMethod could have child element with number of bytes
scantor: if we put in a child element under digest method there break existing implementations
fjh: could have a Signature property, but then you have to associate them with each reference
<fjh> could define a new manifest with reference/length pairs
<fjh> scott suggests simpler to extend DigestMethod with warning only for 2.0 capable implementations
<fjh> meiko suggests count transform for 1.1 implementations
mjensen: for older one we could have a transform that takes 1 parameter- the digested size, the signature validation fails if digest method fails
<fjh> pdatta suggests not changing DigestMethod
<fjh> pdatta suggests adding to selection transform
mjensen: should give a chance for post 2.0 to extend the selection mechanism
<fjh> mjenson notes verification transform for 2.0 following selection and canonicalization, check bytes or other possibilities
mjensen: put if after canonicaliztionMethod as some kind of verification
RESOLUTION: add a verification step to the new 2.0 transform
<scribe> ACTION: pdatta to add verification step for length verification in Signature 2.0 transform [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-613 - Add verification step for length verification in Signature 2.0 transform [on Pratik Datta - due 2010-08-03].
mjensen: should we add it to 1.1 as well as a new transform
<fjh> Note, although we could define 1.1 transform for digest count verification, suggest not to do so, since expect movement to 2.0
<fjh> and prefer to keep 1.1. simpler
<fjh> if needed could define such a transform
<fjh> pdatta - all new schema elements added in 2.0 should be extensible
<fjh> do we know whether we want any vs other vs nothing extensibility?
<fjh> action-590?
<trackbot> ACTION-590 -- Pratik Datta to create separate XPath profile document (from XML Signature 2.0) -- due 2010-06-08 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/590
mjensen: need 2 weeks to review this XPath profile
esimon2: I plan to review the XPath profile too
<fjh> would like to publish FPWD of XPath profile, and updates to C14N2 and XML Signature 2.0 during August, week of 23 August, thus would like WG agreement to publish on 17 August. Comments week of 10th August
<fjh> ACTION: mjensen to review XPath Profile [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-614 - Review XPath Profile [on Meiko Jensen - due 2010-08-03].
<fjh> action-614?
<trackbot> ACTION-614 -- Meiko Jensen to review XPath Profile -- due 2010-08-03 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/614
<fjh> ACTION-614?
<trackbot> ACTION-614 -- Meiko Jensen to review XPath Profile -- due 2010-08-10 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/614
<fjh> ACTION: pdatta to update URI for XPath in XML Signature 2.0 [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-615 - Update URI for XPath in XML Signature 2.0 [on Pratik Datta - due 2010-08-03].
<fjh> ACTION-589?
<trackbot> ACTION-589 -- Pratik Datta to create 2.0 schema with X509IssuerSerial change -- due 2010-06-08 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/589
<fjh> suggest creating new Drafts/xmlsec-schema2 directory and copy and edit schema there
<fjh> xmlsec-xsdschema2
<fjh> xmlsec-xsdschema
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0018.html
<fjh> ACTION-586?
<trackbot> ACTION-586 -- Meiko Jensen to draft text about XPath risks for BP document -- due 2010-06-08 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/586
<fjh> proposed RESOLUTION: accept change to Best Practices 2.2.3 http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/#incorrect-xpath-syntax
RESOLUTION: accept change to Best Practices 2.2.3 http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/#incorrect-xpath-syntax
scantor: for consistency we should use any for extensibility
<fjh> any allows this and other schemas, may lead to ambiguity if next to another schema element
<fjh> other only allows from other schemas
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Jul/0014.html
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Jun/0009.html
<fjh> scott suggests single set of keys would simplify interop for Signature
<Cynthia> the same keys could be used if we use different files (types and sizes), this is not really a key generation test
<Cynthia> I agree with the strategy to use the same keys (or set of keys)
<mjensen> me too
<Cynthia> We don't necessarily want vendor specific keys
<fjh> ACTION: pdatta to check that Oracle interop keys are available in the repository [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-616 - Check that Oracle interop keys are available in the repository [on Pratik Datta - due 2010-08-03].
mjensen: student of mine is doing prototoype 2.0 canonicalization in ruby
<fjh> mjenson: possibility for additional interop
<fjh> ConcatKDF question
<fjh> question from scott - Is anybody aware of a ConcatKDF
<fjh> implementation that's open source at this point?
<fjh> test vector needed
<fjh> ACTION: fjh to discuss interop with thomas, including ConcatKDF [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-617 - Discuss interop with thomas, including ConcatKDF [on Frederick Hirsch - due 2010-08-03].
<fjh> interop page http://www.w3.org/2008/xmlsec/wiki/Interop
<fjh> please update this wiki if you are aware of items missing that need testing
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0012.html
<fjh> Makoto Murata now a member of the wg
<fjh> ACTION: fjh to make sure Makoto listed as author of RNG schmea [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-618 - Make sure Makoto listed as author of RNG schmea [on Frederick Hirsch - due 2010-08-03].
<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-553?
<trackbot> ACTION-553 -- Thomas Roessler to contact implementers known from hmac affair -- due 2010-07-31 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/553
<fjh> Ed Simon plans to review Meiko proposal, for ACTION-538
<fjh> ACTION: esimon to review Meiko proposal for ACTION-538 [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action12]
<trackbot> Sorry, couldn't find user - esimon
<fjh> ACTION: esimon2 to review Meiko proposal for ACTION-538 [recorded in http://www.w3.org/2010/07/27-xmlsec-minutes.html#action13]
<trackbot> Created ACTION-619 - Review Meiko proposal for ACTION-538 [on Ed Simon - due 2010-08-03].
<fjh> ACTION-581?
<trackbot> ACTION-581 -- Scott Cantor to make proposal around IDness of attributes -- due 2010-06-15 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/581
<fjh> ISSUE-140?
<trackbot> ISSUE-140 -- Clarify how XPath is interpreted relative to entire document and ds:Reference -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/140
scantor: this would be useful for
enveloped signatures, where the thing that is being signed is a
parent or sibling of the signature
... this could be an attack in some contexts though, absolute
is better for those contexts
<fjh> concern is that a subset of a document can be moved into a new context, hence XPath from document root would be wrong and fragile
<fjh> general issue - will 2.0 work with document subsets that are moved into new document contexts
scantor: in web services use case we see this a lot where tokens are moved around
<fjh> ISSUE-140: general issue - will 2.0 work with document subsets that are moved into new document contexts
<trackbot> ISSUE-140 Clarify how XPath is interpreted relative to entire document and ds:Reference notes added
<fjh> meiko - tradeoff of threat vs feature of being able to move subset
<fjh> need clarity in text to be clear which XPaths are absolute and relative (for exclusion, inclusion etc)
<fjh> pdatta: all absolute now
<fjh> pdatta: if we allow relative would need to put some aspects of XPath navigation back in
<fjh> maybe we should not allow relative XPath but find other solution to subset concern
<fjh> scott - e.g. use ids
scantor: enveloped signatures are inherently not streamable , because the signature is after the data to be signed
<fjh> scantor: if signatures not enveloped then people ask why use XML Signature
<fjh> suggest not allowing relative XPath, but consider using IDs instead
<fjh> scantor - have action item for this ID issue
<fjh> ISSUE-183?
<trackbot> ISSUE-183 -- Constrain 2.0 SignedInfo canonicalization choice for 2.0 model? -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/183
<fjh> proposed RESOLUTION: not to constrain 2.0 SignedInfo canonicalization, due to need for 1.1 compatibility
<fjh> Ed suggests waiting until review of Magic Signatures
<fjh> I believe we thought this was easy until we considered backward compatibility with 1.1
esimon2: whether SignedInfo can be canonicalized with both c14n 1.0 and c14n 2.0 ?
<fjh> see http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/att-0095/19-xmlsec-minutes.html#item09
<fjh> "discussion of 2.0 signatures can SIgnedInfo be canonicalized with either C14N11 or C14N2.0?"
<fjh> scott - is this conformance issue, or do we want to keep open for future
<fjh> scott: suggests should be consistent for references and SignedInfo. 2.0
<fjh> proposed RESOLUTION: for 2.0 mode, require c14n2 for SignedInfo and References
<fjh> proposed RESOLUTION: C14N algorithm must be same for SignedInfo and References
scantor: for futureproofing we must allow newer algorithms in canonicalization signedInfo and references
<fjh> esimon2: proposed RESOLUTION: in 2.0 mode, require C14N2 for SignedInfo
<fjh> scott suggests saying nothing, but C14N2 can only be used for References due to model
<fjh> we need to take this to the list
this is what we have in the doc now: "2.0 mode signatures, must use the 2.0 mode Canonicalization algorithms" section 6.5
<scantor> right, that's what I thought we had
<fjh> adjourn
<fjh> s/RESOLUTION: Accept Scotts proposal (as revised) http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0023.html/RESOLUTION: Accept Scotts proposal (as revised) http://lists.w3.org/Archives/Public/public-xmlsec/2010Jul/0023.html and add Curie reference/