XML Security Working Group Teleconference
25 May 2010

<trackbot> Date: 25 May 2010

<scribe> ScribeNick: bal

Administrivia

<tlr> previous minutes: http://www.w3.org/2010/05/11-xmlsec-minutes.html

<tlr> RESOLUTION: minutes approved

RESOLUTION: Minutes from 11 May 2010 approved

Elliptic Curve

tlr reported on the latest progress on elliptic curve. Discussions are ongoing; see member-visible version of these minutes for details.

Last Calls

tlr: LCs are up for Signature 1.1, Encryption 1.1 and GHC 1.1

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

tlr: We also received a comment from the EXI working group. Any comments on the EXI comment? (None).
... WS-RA has removed their XPath dialect from XPath fragment, so the coordination issue with them is now moot

RESOLUTION: We agree with WS-RA's decision.

XPath Profile and WS-RA

tlr: Should we keep the XPath profile in Signature 2.0 or should we split it out into a separate document?

pdatta: I think it makes more sense to split it out into a separate document
... it would be more reuasable that way

tlr: I have no particular thoughts on the issue.

<Cynthia> I agree, are there any Interop testing issues separating them?

<csolc> +1

scantor: I prefer more modular

Gerald-E: More modular is better

RESOLUTION: XPath profile to be broken out of XML Signature 2.0 and placed into a separate specification

C14N 2.0

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

scantor:One of the canonicalization specs appears to suggest that attribute normalization is part of validation
... but my reading of the XML core docs is that it is part of XML core.
... all XML parsers are supposed to normalize attributes
... not talking about schema datatype normalization, that's different
... the question is relevant because if you present it as an option that can be turned off and it's supposed to be done in every case by an XML parser, that would conflict with a mandatory part of the XML core
... in the original C14N spec there's a section that implies that attribute normalization was done as part of validation
... and that seems incorrect

<tlr> I see: "However, the attribute value normalization and entity reference resolution MUST be performed in accordance with the behaviors of a validating XML processor"

pdatta: When you define an attribute in a DTD, you can define it to be an nmtoken or CDATA

scantor: So there's some DTD information that gets imposed on the document that influences how the validation works

tlr: So the DTD influences?

scantor: Yes.
... In theory, you don't have the freedom to ignore internal or external subsets because of the possible obligations imposed by the DTD

tlr: What is the behavior of current implementations?

scantor: My impression is that current implementations, when they parse internally, follow these rules. but C14N 1.X talks about the various inputs and the options apply when the octet stream is parsed into a node set
... if you're given the node set up front you don't know how the node set was created
... we need to carry over this distinction to the new C14N document
... because the distinction is important.

<csolc> Section 3.5 referes to how entity references work

tlr: There is a clear distinction between the way the two types of inputs

scantor: Yes

tlr: Do we know implementations make that distinction?

scantor: Yes, they have to parse. But we don't know how everyone configures their parser.

tlr: Xan someone here come up with a test case that would allow implementors to test their implementations?
... sounds like it could be a hidden interop problem

<Cynthia> +1

scantor: It was my impression that this might have been an option in implementations that folks implemented because of the security issues around entity parsing

<csolc> From Section 2.1

<csolc> Software switches

<csolc> The input octet stream MUST contain a well-formed XML document, but the input need not be validated. However, the attribute value normalization and entity reference resolution MUST be performed in accordance with the behaviors of a validating XML processor. As well, nodes for default attributes (declared in the ATTLIST with an AttValue but not specified) are created in each element. Thus, the declarations in the document type declaration are used to help creat

csolc: We do resolve the external and internal entity references from the DTD if the DTD exists

tlr: So you precisely follow the spec

csolc: It's a MUST in the spec

tlr: I wasn't recalling test cases from earlier discussions

<Cynthia> Yes, please check on it

bal: I think there should be a test case on it for 2.0

csolc: External entity reference processing can violate security sandboxing rules in some cases
... so we may have to do something about it.

bal: I guess we're stuck with DTDs in 2.0?

csolc: To what extent can we create options that go beyond what a technically-compliant XML processor is required to support
... that is, options (that maybe every parser implements) that are beyond the minimum requirements of XML parsers

tlr: Sounds like a question to ask the XML Core WG since it is their processing model

scantor: There are usually a suite of options but I'm ot sure to what extent they're standardized.

<pdatta> Java DOM parser's normalization: http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Attr.html

pdatta: Looking at the Java parser, there is no option (the APIs say it will be normalized)

scantor: I think the attribute value normalization got confusing because there are some normalization options that always happen (e.g. linefeeds) and some that are datatype-dependent
... the spec reads as though all attribute value normalization is related to validation, but that's not really the case

tlr: So what changes should be made to the spec?

scantor: we should answer the broader question first, because we need to know whether we can rely on browser behavior outside of XML Core
... the issue related to DTD behavior are really related to how you parse an octet stream. if you get a node set as input you don't have control, since it's already been parsed
... that distinction needs to be better elucidated
... and noted that how you parse an octet stream needs to be clearly communicated to both ends
... could be a Best Practice or go into the new canonicalization
... I'm inclined toward fewer options, not more, so I'd say "either you do DTD processing or not"

tlr: so the question at hand is whether C14N 2.0 should allow more fine-grained control/options than just "do DTD processing or not"

scantor: well, and are we going to bring over the language from 1.X about DTD processing
... even non-validating parsers do some DTD-related processing

pdatta: I don't think we should even have this option in canonicalization.

scantor: do we still have the option of an octet stream as input?
... but maybe we don't in the new model
... needed in the original document because of the transform chain model
... transforms can take either an octet stream or a node set
... if the new material really says you always get a stream of SAX or a DOM tree/subtree then what you do with DTD-ness is then entirely moot

pdatta: Are you sure that the 1.0 C14N would take an octet stream?

scantor: Yes, see section 2.1

pdatta: We wouldn't have octet stream inputs

scantor: OK, we have a simpler issue then
... and the options would go away (or be reintroduced in terms of signature options)

tlr: Or re-introduce octet-streams as an input to c14n 2.0

pdatta: I'll take a stab at removing those options

<tlr> ACTION: pdatta to review c14n 2.0 for parsing-related options; propose removal (or add octet-stream processing to 2.0) [recorded in http://www.w3.org/2010/05/25-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-580 - Review c14n 2.0 for parsing-related options; propose removal (or add octet-stream processing to 2.0) [on Pratik Datta - due 2010-06-01].

<tlr> ACTION-580: relates to ISSUE-201

<trackbot> ACTION-580 Review c14n 2.0 for parsing-related options; propose removal (or add octet-stream processing to 2.0) notes added

<tlr> ACTION: scantor to make proposal around IDness of attributes - due 2010-06-15 [recorded in http://www.w3.org/2010/05/25-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-581 - make proposal around IDness of attributes [on Scott Cantor - due 2010-06-15].

<tlr> scantor: of the schema pieces reviewed, IDness the one that's an open issue for us that isn't tracked

tlr: Of the scheme portions you reviewed, IDNess is the open issue

<tlr> ISSUE: How to tag id-ness of attributes when schema isn't parsed

<trackbot> Created ISSUE-203 - How to tag id-ness of attributes when schema isn't parsed ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/203/edit .

scantor: Yes

<tlr> 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

tlr: We should keep Issue 201 open for a while

<tlr> ISSUE-201: blocks on ISSUE-203, ACTION-580

<trackbot> ISSUE-201 C14N 2.0 handling of DTD-related and Schema-related behaviors notes added

Null reference

tlr: Suggest we defer since Meiko isn't on the call

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

Visible utilization in XPath

tlr: We'll also defer this topic until Meiko is on the call

Signature 2.0

<Cynthia> What is the status of implementations for v2.0 and plans for testing?

tlr: Hearing silence I fear there is no news on this front
... but a useful question to keep in mind

<Cynthia> Agreed, unfortunate.

External unparsed entities in Best Practices

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

tlr: Scott, have you had a chance to review the text I suggested?

scantor: It seemed fine to me

tlr: Just want to make sure I'm not causing further confusing
... any objections to including this text?

scantor: Might be the type of text we'd want to put into the signatuere document itself

RESOLUTION: tlr's changes to best practices accepted (http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0033.html)

<tlr> ACTION: tlr to update best practices with ACTION-578 text [recorded in http://www.w3.org/2010/05/25-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-582 - Update best practices with ACTION-578 text [on Thomas Roessler - due 2010-06-01].

<tlr> ACTION-578 closed

<trackbot> ACTION-578 Provide signature best practice proposal related to external references closed

Actions and Issues

<tlr> action-572 closed

<trackbot> ACTION-572 Get encryption 1.1 and GHC pubrules-ready closed

tlr: There are a few that are done so we'll close them

<tlr> action-575 closed

<trackbot> ACTION-575 Update algorithm cross-reference for GHC namespace change closed

tlr: Let's have a quick look at the open action items

<tlr> http://www.w3.org/2008/xmlsec/track/actions/open

tlr: Open action items...

<tlr> action-348 closed

<trackbot> ACTION-348 Review 2.0 sig docs closed

<tlr> action-426?

<trackbot> ACTION-426 -- Pratik Datta to run performance tests on non-optimized Signature implementation -- due 2009-11-12 -- OPEN

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

<tlr> action-426 due 2010-06-30

<trackbot> ACTION-426 Run performance tests on non-optimized Signature implementation due date now 2010-06-30

<tlr> action-456?

<trackbot> ACTION-456 -- Scott Cantor to review workshop papers regarding strengthening id based references with respect to wrapping attacks -- due 2009-11-24 -- OPEN

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

<tlr> action-456: related to action-581

<trackbot> ACTION-456 Review workshop papers regarding strengthening id based references with respect to wrapping attacks notes added

<tlr> action-456 due 2010-06-15

<trackbot> ACTION-456 Review workshop papers regarding strengthening id based references with respect to wrapping attacks due date now 2010-06-15

<tlr> action-507 closed

<trackbot> ACTION-507 Review XML Encryption 1.1, including proposed processing model changes closed

<tlr> action-543 due next week

<trackbot> ACTION-543 Make proposals for the last two points noted in ISSUE-43 comments due date now next week

<tlr> action-544 due 2010-06-15

<trackbot> ACTION-544 Review ISSUE-162, regarding Object/Manifests language and transforms due date now 2010-06-15

<tlr> action-547?

<trackbot> ACTION-547 -- Pratik Datta to confirm that RetrievalMethod warning remains in 2.0 draft of signature -- due 2010-04-06 -- OPEN

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

<tlr> action-547 due 2010-06-15

<trackbot> ACTION-547 Confirm that RetrievalMethod warning remains in 2.0 draft of signature due date now 2010-06-15

<tlr> action-549?

<trackbot> ACTION-549 -- Scott Cantor to provide proposal related to generic parameter relatedto xsiTypeAware -- due 2010-04-20 -- OPEN

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

<tlr> ACTION: scantor to create qnames issue, link to ACTION-549 [recorded in http://www.w3.org/2010/05/25-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-583 - Create qnames issue, link to ACTION-549 [on Scott Cantor - due 2010-06-01].

<tlr> action-556?

<trackbot> ACTION-556 -- Pratik Datta to review text related to Object tag for consistency with 2.0 model -- due 2010-04-27 -- OPEN

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

<tlr> action-556 due 2010-06-15

<trackbot> ACTION-556 Review text related to Object tag for consistency with 2.0 model due date now 2010-06-15

<tlr> action-411 due 2010-06-30

<trackbot> ACTION-411 Perform measurement related to transform octet conversion due date now 2010-06-30

<tlr> action-568 due next week

<trackbot> ACTION-568 And bal to review relationship between ghc and material in encryption due date now next week

<tlr> action-576 due 2010-06-22

<trackbot> ACTION-576 Add "high performance profile" to c14n2 due date now 2010-06-22

<tlr> action-579 due 2010-06-22

<trackbot> ACTION-579 Update c14n2 with proposal from ACTION-574 due date now 2010-06-22

<tlr> action-577: duplicate action-549

<trackbot> ACTION-577 Propose more general mechanism for QNames in content notes added

<tlr> action-577 closed

<trackbot> ACTION-577 Propose more general mechanism for QNames in content closed