See also: IRC log
<trackbot> Date: 31 August 2010
<tlr> ScribeNick: tlr
fjh: |: tpac :|
... minutes approval, 24 August
<fjh> Approve 24 August 2010 minutes
<fjh> http://www.w3.org/2010/08/24-xmlsec-minutes.html (revised to highlight FPWD resolution)
RESOLUTION: 24 August minutes approved
<fjh> FPWD of Streamable XPath Profile
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Aug/0025.html
fjh: we got a comment to please clarify whether it's a profile of 1.0 or 2.0
<fjh> proposed RESOLUTION: Approve changes to FPWD of "XML Signature Streaming Profile of XPath 1.0" as outlined in http://lists.w3.org/Archives/Member/member-xmlsec/2010Aug/0025.html
fjh: I propose we make a change
to the title
... and to the abstract
RESOLUTION: Approve changes to FPWD of "XML Signature Streaming Profile of XPath 1.0" as outlined in http://lists.w3.org/Archives/Member/member-xmlsec/2010Aug/0025.html
<fjh> Updated WDs - XML Signature 2.0, Canonical XML 2.0, XML Security RELAX NG Schemas, XML Signature Best Practices
fjh: also updated WDs over week-end. transition request etc is done
tlr: all done
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010Aug/0021.html
<fjh> Please do not checkin files today until publication request appears on members list
tlr: if you want to make changes to schemas etc, please hold off until tomorrow morning
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0063.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0067.html
pdatta: new idea from scott
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0076.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0077.html
pdatta: but how do we deal with
several distinct ID type attributes on one element
... use of IDs in xpath
<fjh> from Scott's email - IMHO. I would probably use text like "if the selection URI
<fjh> or XPath expressions include the use of an ID attribute, the signer SHOULD
<fjh> identify all such attributes using the dsig2:IDAttributes element".
pdatta: idea was to make the
xpath subset less dependent on signature
... did not want to depend on any other type
... did not want ID function in xpath to depend on what we do
in ID attribute in signature
scantor: don't think it does
depend on it
... it's a separate piece of machinery
... there's no good answer in XML -- not clear whether xpath
IDness is the same as other IDness
... the way that hole was supposed to be plugged was
xml:id
... it hasn't really worked because people still argue that
it's DTD based
... unfortunately, xml:id wasn't adopted because specs that
needed it were done by the time
... nothing different between xpath IDness and any other
IDness
<fjh> scott had proposal, pasted above, in http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0067.html
<fjh> scott noted to allow for multiple ids in a single verification assertion
<fjh> scott notes since separate processing steps, no interdependency
scantor: the profile doesn't depend on signature, since identifying IDness is separate from evaluating xpath expressions
pdatta: xpath implementation
typically separate from signature
... from implementation point of view, ?? ID attributes
scantor: I don't think signature
can be layered into pipeline very effectively
... there are implementations that make use of those (?)
... if your application is not amenable to injecting ID
information
... then that's fine, and you don't have to use that
assertion
... many applications have interesting ways to inject ID
information into process
... many did it because of SAML and WSS
... would totally agree that there shouldn't be a required
processing step here
pdatta: if we're not closing the door to other app-specific ways to identify IDness, then I'm fine
scantor: no way we're closing the
door
... people already use IDness information in xpath
fjh: adopt scantor's language on this?
scantor: normative rules about which IDs referenced
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0067.html
scantor: think we could make it a
SHOULD that all known IDs be identified
... intent was not to make things more difficult
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0067.html
<scribe> ACTION: pdatta to implement Cantor's language from 0067.html [recorded in http://www.w3.org/2010/08/31-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-647 - Implement Cantor's language from 0067.html [on Pratik Datta - due 2010-09-07].
, as specified in last paragraph of message 67
<fjh> proposed RESOLUTION: add the language proposed in last paragraph of message 67 to xml signature 2.0, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0067.html
RESOLUTION: add the language proposed in last paragraph of message 67 to xml signature 2.0, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0067.html
<fjh> ISSUE-209?
<trackbot> ISSUE-209 -- Is Verification assertion mandatory to implement, is presence/verification optional -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/209
fjh: optional to implement, optional to use. Think we're done.
<fjh> ISSUE-209 closed
<trackbot> ISSUE-209 Is Verification assertion mandatory to implement, is presence/verification optional closed
pdatta: it's clearly optional.
<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> need to figure out where we are on this one?
issue-160?
<trackbot> ISSUE-160 -- Define URI for Canonical XML 2.0, add section to Signature 2.0 defining Canonical XML 2.0 -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/160
scantor: thought we had settled issue-183
fjh: issue-160 -- URI for c14n 2.0 -- do we need any?
scantor: section 6.5 -- need corresponding section on 2.0 c14n algorithms with single entry
<fjh> ISSUE-160: need to add section to signature 2.0 listing 2.0 c14n algorithms
<trackbot> ISSUE-160 Define URI for Canonical XML 2.0, add section to Signature 2.0 defining Canonical XML 2.0 notes added
scantor: it's done in 6.8
<scribe> ACTION: pratik to flesh out 6.8, shuffle order of sections [recorded in http://www.w3.org/2010/08/31-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-648 - Flesh out 6.8, shuffle order of sections [on Pratik Datta - due 2010-09-07].
issue-43?
<trackbot> ISSUE-43 -- Improvements to XML Signature schema -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/43
<fjh> ISSUE-43?
<trackbot> ISSUE-43 -- Improvements to XML Signature schema -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/43
scantor: mostly dealing with mixed content models (2.0); also SerialNumber issue
<fjh> Issue has details in the notes field
<fjh> keeping open for Scott's review
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0079.html
magnus: had taken action item to review impact on current ecosystem of 1.0 schema correction
<fjh> "Microsoft implementations should be able to handle such an update"
magnus: making a change to the
1.0 schema doesn't sound advisable
... there's a reason we have namespaces
fjh: so, if your implementations can handle it?
magnus: our implementations, but not everybody else's
hal: Recall there's a TAG finding
on this
... roughly, "when you make incompatible changes, use new
schema"
fjh: think we're talking about bugfix here
magnus: whether it matters
depends on the way the implementation works
... current schema specifies element as an integer
... can see how a change to string could affect
applications
... can see the problem we're having here
... current schema is clearly not correct
hal: think the argument is that,
as it stands, it doesn't work
... so current implementation has to do one of two things
... either not work, or invent way to handle it
... so we can assume that all current implementations are in
one of these cases
... either they fail, or they don't do this
scantor: or they have a parser that handles really large integers
hal: if there can't be
implementations based on the current text,
... then we can't affect them
... there is value to having everybody using a scheme with two
properties
... (a) it works, (b) it's standardized
... inclined to say that nobody can possibly in practice follow
the current spec, there's no way we can break a current
implementation
scantor: also note suggesting
that we start passing around strings in there
... it's still supposed to be a number
... would have to add some text to the spec
<fjh> ACTION-623?
<trackbot> ACTION-623 -- Magnus Nystrom to review schema update plan, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0017.html -- due 2010-08-25 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/623
scantor: "this is a string, but it holds an integer"
ACTION-623 closed
<trackbot> ACTION-623 Review schema update plan, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0017.html closed
<fjh> proposed RESOLUTION: WG agrees the 1.0 schema changes the type on X509SerialNumber from Integer to String. Make corresponding changes to version 1.1 of the specification; include the updated schema in the 1.1 publication.
<fjh> proposed RESOLUTION: WG accepts schema update plan per http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0017.html
scantor: break people generating APIs off it or people using validator?
bal: why can't you make the same argument that one end or the other just has to change their local integer max?
scantor: up to the parser
... also, normatively in the schema conformance rules what size
of integers you permit
... they tell you there are reasonable limits
... which are smaller than what you get in openssl generated
certs
bal: specific limits?
scantor: 15 digits or
something
... note the type is unbounded, but there are practical
limits
bal: bignum type in signature?
tlr: ds:CryptoBinary
http://www.w3.org/TR/xmldsig-core1/#sec-CryptoBinary
bal: the distinction between
base64 and cryptoBinary is chopping off leading zeros
... neither of that applies here
... issue here is that we have discrepancy between integer type
and conformance rules
... doesn't seem to me that there's a one-off fix here
... if there are real issues with bignum issues that should be
addressed in the core area
... short serial numbers lead to problem
... hence long random numbers or something like that
... there needs to be an error report
hal: what we have here is something with the format constraints of a number that we don't ever want to do arithmetic with
scantor: pattern facet on string?
<csolc> +1
<fjh> I don't think it will help xml security wg complete its deliverables if there is a dependency on changing xml schema
scantor: reason I didn't suggest it that I never saw them
<fjh> derive type from string that makes it a number
scantor: subtype of string with a pattern
<fjh> tlr notes can look at what xml schema wg is doing
http://www.w3.org/TR/xmlschema11-2/
<fjh> tlr questions can length constraint on decimal be changed, b) would any such change require change of existing implementations
<scantor> it is from decimal, it's in sec 3.2.3: http://www.w3.org/TR/xmlschema-2/#decimal
<scantor> 18 digits is the minimum to support, meaning more can be rejected
http://www.w3.org/TR/xmlschema11-2/#precisionDecimal
<scribe> ACTION: thomas to check in with Michael Sperberg-McQueen about decimal and bignums [recorded in http://www.w3.org/2010/08/31-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-649 - Check in with Michael Sperberg-McQueen about decimal and bignums [on Thomas Roessler - due 2010-09-07].
(confusion)
magnus: 1.1 backwards compatible
to 1.0, so can't make a change?
... one thing about asking schema folks
... what's a useful minimum to suggest to them?
... happy to work offline with Thomas
tlr: ok, so what's a reasonable order of magnitude?
bal: can't have a limit
scantor: we seem to be rehashing the same argument
<fjh> scott notes 1.1 and 2.0 are same namespace, want backward compatibility
<fjh> tlr notes that we agree that current schema has a problem, any doc valid under 1.0 schema should also be valid under revised 1.1 schema, any element valid under 1.0 schema namespace must be valid under schema for 1.1
<fjh> agree not changing schema by adding new features
<fjh> tlr suggests scope of changes is so small as to be reasonable
<fjh> tlr notes widens space that will validate
<fjh> scott notes not broadening lexical space
the change proposed by Scott would
1. not change the lexical space
2. it would change the set of documents that can get through a minimally conforming parser
3. it would change the value space to string
scantor: believe in a high
barrier to this sort of changes
... don't think it's something to do lightly'
... do think that schemas that are broken with most
implementations don't do anybody any good
... want something that works
... adding pattern is probably a good idea (though it's
possibly more likely to break code generators)
magnus: thought we had said we can't make changes to the schema for the 1.0 namespace
bal: some of us think we are making a breaking change
csolc: think integer with constraint is the right thing
brich: don't think I have
anything to add
... would agree wtih what Chris mentioned
... am concerned with what would seem to be a breaking change
to old schema
fjh: brian -- is there a specific concern here?
bal: we don't know code
generation is occurring off the schema
... don't like the notion that people should change local
copy
... think we're stuck with this, given charter
... we went to great lengths
hal: WSS -- certificate something
bal: there's a whole lot of history in x.509
<magnus> I am still in the queue...
<bal> basically, what I said was that I thought we were willing to break the schema for 2.0 but not for 1.1, that our charter was that 1.1 should be back-compat with 1.0
<fjh> http://www.w3.org/2008/02/xmlsec-charter.html
<bal> and that we had gone out of our way to not break the 1.1 schema and we had skipped features in 1.1 because they would have broken the schema
tlr: there's a fair point here
Hal: don't think agreement not to
change schema; agreement was not to make backward-incompatible
changes
... if there's something that can't be implemented as written,
then it's an erratum
... you might be breaking implementations that have invented
some addition to the spec
magnus: can't change 2.0 either? e.g., add a new type
scantor: could do that sort of thing for 1.1 by putting something into a new namespace
magnus: possibly do in 1.1 as well
scantor: that runs into practical
concerns since nobody is enamored with this
... issue we have is that if we offer validation, we may still
see documents that conform, but don't validate
... so if we don't change the spec, propose a schema with a
correction
<scantor> a key point: no proposed instances generated under the changed schema would fail to validate under the old schema unless they would already fail to validate now
<fjh> revisit on 14 sept with proposals and new information from tlr
<scribe> ACTION: thomas to propose choices for X509SerialNumber fix - due 2010-09-09 [recorded in http://www.w3.org/2010/08/31-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-650 - propose choices for X509SerialNumber fix [on Thomas Roessler - due 2010-09-09].
<fjh> proposed RESOLUTION: WG agrees the 1.0 schema changes the type on X509SerialNumber from Integer to String. Make corresponding changes to version 1.1 of the specification; include the updated schema in the 1.1 publication.
<fjh> [10:41am] fjh: proposed RESOLUTION: WG accepts schema update plan per http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0017.html
<fjh> proposed RESOLUTION A: WG agrees the 1.0 schema changes the type on X509SerialNumber from Integer to String pattern of positive integers without bound
<fjh> proposed RESOLUTION B: do nothing
<fjh> proposed RESOLUTION C: Have alternate corrected schema version that is not found via namespace
<fjh> update plan would follow on chosen choice
<fjh> note that RESOLUTION C would be an errata change
<fjh> new edition of specification makes errata normative
<fjh> choice C is effectively the same as proposal A
<fjh> ACTION: tlr to summarize errata process and RESOLUTION A versus C [recorded in http://www.w3.org/2010/08/31-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-651 - Summarize errata process and RESOLUTION A versus C [on Thomas Roessler - due 2010-09-07].
<fjh> pratik will undo issueSerial change for 2.0 before publication
<bal> magnus and i need to drop now
<fjh> ISSUE-132?
<trackbot> ISSUE-132 -- Keep 2.0 xenc transform feature in sync with signature 2.0 -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/132
bal: haven't looked at this
<fjh> tlr: More research required before considering a PAG. PAG would take time and effort from members.
<fjh> http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-03
<fjh> tlr: waiting with proposal on ECC until after gathering additional information, probably delayed for 3 weeks.
<fjh> ScribeNick:scantor
<fjh> included and excluded XPath
ISSUE: XML Signature 2.0 needs precise definitions of Included/ExcludedXPath elements
<trackbot> Created ISSUE-213 - XML Signature 2.0 needs precise definitions of Included/ExcludedXPath elements ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/213/edit .
ISSUE: XML Signature 2.0 needs precise definitions of Verification element and its children.
<trackbot> Created ISSUE-214 - XML Signature 2.0 needs precise definitions of Verification element and its children. ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/214/edit .
<Cynthia> I need to leave, ACTION-620, open, Review C14N2 references, ISSUE-200, Cynthia Martin- should be closed as of last week
<fjh> ISSUE-214: add section and possibly schema
<trackbot> ISSUE-214 XML Signature 2.0 needs precise definitions of Verification element and its children. notes added
I mean explicit sections with schema snippets and semantic information
<fjh> ACTION-280?
<trackbot> ACTION-280 -- Magnus Nyström to produce test cases for derived keys -- due 2009-05-19 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/280
<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> should be available next week
<fjh> ACTION-548?
<trackbot> ACTION-548 -- Ed Simon to ed to review XPath Profile -- due 2010-04-20 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/548
<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
Hal: vaguely remembers, will review
<fjh> ACTION-620?
<trackbot> ACTION-620 -- Cynthia Martin to review C14N2 references, ISSUE-200 -- due 2010-08-10 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/620
<fjh> ACTION-62?
<trackbot> ACTION-62 -- Sean Mullan to review best practices document from implementation standpoint -- due 2008-09-16 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/62
<fjh> ACTION-621?
<trackbot> ACTION-621 -- Thomas Roessler to propose ECC-related refactoring of spec -- due 2010-08-31 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/621
<fjh> deferred
<fjh> ACTION-623?
<trackbot> ACTION-623 -- Magnus Nystrom to review schema update plan, http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0017.html -- due 2010-08-25 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/623
<fjh> ACTION-625?
<trackbot> ACTION-625 -- Meiko Jensen to review c14n2 parameters with regards to conformance and optionality -- due 2010-08-31 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/625
<fjh> ACTION-638?
<trackbot> ACTION-638 -- Scott Cantor to make proposal for ISSUE-210, see also http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0043.html (uncomplicate section) -- due 2010-08-31 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/638
<fjh> ACTION-643?
<trackbot> ACTION-643 -- Meiko Jensen to propose text for best practices re ISSUE-212, attack noted in http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0020.html -- due 2010-08-31 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/643
<fjh> ACTION-644?
<trackbot> ACTION-644 -- Meiko Jensen to propose text for Streaming XPath Profile to note that 1-pass not always possible, giving examples where 1-pass is not possible -- due 2010-08-31 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/644
<fjh> ISSUE-200?
<trackbot> ISSUE-200 -- Which references are normative vs informative for C14N2 -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/200
<fjh> ISSUE-200 closed
<trackbot> ISSUE-200 Which references are normative vs informative for C14N2 closed
<fjh> tentatively Bruce will scribe next week
<fjh> adjourned