XML Security Working Group Teleconference
10 Mar 2009


See also: IRC log


Frederick Hirsch, Sean Mullen, Scott Cantor, Rob Miller, Chris Solc, John Wray, Magnus Nyström, Hal Lockhart, Peter Saint-Adnre, Pratik Datta, Bruce Rich, Kelvin Yiu, Konrad Lanz, Gerald Edgar, Ken Graf
Thomas, Roessler
Frederick Hirsch
Rob Miller




<trackbot> Date: 10 March 2009

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0015.html



Next meeting 17 March, Magnus Nyström is scheduled to scribe.

magnus: I can scribe next week

fjh: Minutes will not go on the public page until Thomas is back

... new member of the work group from CISCO

fjh: Peter Saint-Andre at Cisco joined WG.

psaintan: My name is Peter-Saint Andre and I have been working on Jabber stuff and we are looking at XML Dsig for signing stuff

Frederick explained the WG deliverables to Peter.

Minutes Approval

fjh: made slight adjustments to the minutes


RESOLUTION: Minutes from 3 March approved.

Face to Face Planning

fjh: My goal is to enter a resolution today to agree on a place and time for the next Face-to-Face

magnus: We are willing to host.

proposed resolution: Next XML Security F2F to be held 12-13 May 2009 at RSA/EMC in Bedford MA

magnus: We willnot be able to offer breakfast and lunch, but there is a cafeteria available.

... Internet access will be available in the room as well as a phone for the VTC.

RESOLUTION: Next XML Security F2F to be held 12-13 May 2009 at RSA/EMC in Bedford MA

1.1 Interop Planning


mullan: I am not sure what Pratik meant about new stuff

pdatta: Are we testing the new features only?

mullan: Yes, plus any items that may need to be tested for compatibility.

fjh: I would like to see us focus our efforts on the new work.

pdatta: We need to plan our internal resources to figure out how much to plan for testing.

fjh: Does anyone else have any concerns regrading resourcing?

kelvin: We can provide some resources for testing around the July time frame.

fjh: Does this mean that the interop could actually happen in July?

kelvin: End of August would be a conservative estimate.

pdatta: We were expecting to be able to support interop testing sometine in the next 2 months.

brich: We have begun loking at it, but I do nota have an official answer.

... The resources are not lined up to do the work yet.

mullan: implementation supports all of the algs except ECDSA

mullan: We should be able to setup the tests quickly with the exception of ECC.

kelvin: We may be able to start teting earlier if we do the first set of testing without ECC and do ECC later.

fjh: +1

XML Encryption mandatory Key Agreement Algorithms for 1.1


XML Encryption Mandatory Key Agreement Algorithms for 1.1

fjh: We are waiting on action from Brian.

EC Point Type


awaiting for action

fjh: We are waiting on an action.

<magnus> ACTION: Magnus to work with Brian on how to express verifiable randomness of curves in XML schema [recorded in http://www.w3.org/2009/03/10-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-229 - Work with Brian on how to express verifiable randomness of curves in XML schema [on Magnus Nyström - due 2009-03-17].

Exclusive Canonicalization


fjh: Sean thinks that exclusive canonicalization should be mandatory and not optional.

csolc: I agree with Sean.

... C14N should be required for XML Signature 1.1

pdatta: +1

kelvin: I have to look at the proposal and do not have an opinion right now.

kelvin: I generally do not have a problem with it, but I am concerned with the small devices.

proposal to make Exclusive Canonicalization required algorithm - request wg members review

plan to decide on either next week or following week call

this is recorded as ISSUE-108

5.1 Algorithms with extra spaces


recorded as ISSUE-109, fixed in editors draft

Widget Editors Draft


fjh: I made a substantial revision the the draft.



Issue Review

note that ISSUE-56 should be closed

Timestamp References Add references related to timestamping

RESOLUTION: Issue-56 should be closed.

ISSUE-56 close


ISSUE-56 closed

<trackbot> ISSUE-56 Add references related to timestamping closed

RESOLUTION: Issue-57 should be closed.

ISSUE-57 closed

<trackbot> ISSUE-57 eliminate the need of the name of the element in end tag / make it optional closed

fjh: Issue-58 is about namespace declaration and should be closed.

RESOLUTION: Issue-58 should be closed.

ISSUE-58 closed

<trackbot> ISSUE-58 Clarify c14n11 handling of xml: namespace declarations closed

Requirements as issues


gedgar: There is a long list of requirements intended to go into XML Sig and Canonicalization V Next and if we have considered or disposed of them we should close the issues.

The issues in question are: 31,32,34,37,38, 45, and 51.

fjh: We will cover these on next week's call.

gedgar: If you know of a current sataus of these issues it would be helpful to send them to the list.

need to know disposition of issues, status

C14N vNext Ideas


section 3.4, http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html#c14n-reqs

pdatta: 3.4 has the requirements with all of the previous requirements in 3.4.1 and all of the new requirements are in 3.4.2

... is about prehashing

pdatta: I do not want to have agreement on this call, but just want to have a discussion.

pdatta: covers well defined and limited selection for SignedInfo

<pdatta> <?xml version="1.0" encoding="UTF-8"?>

<pdatta> <foo:Root xmlns:bar="http://example.org/bar" xmlns:baz="http://example.org/baz" xmlns:foo="http://example.org/foo" xmlns="http://example.org/" xml:lang="en-ie">

<pdatta> <bar:Something>

<pdatta> <foo:Nothing>

<pdatta> <foo:Something>

<pdatta> <bar:Something>

<pdatta> <foo:Something>

<pdatta> <foo:Nothing>

<pdatta> <foo:Something>

<pdatta> <baz:Something />

<pdatta> </foo:Something>

<pdatta> </foo:Nothing>

<pdatta> </foo:Something>

<pdatta> </bar:Something>

<pdatta> </foo:Something>

<pdatta> </foo:Nothing>

<pdatta> </bar:Something>

<pdatta> </foo:Root>

<pdatta> ~

fjh: it is the same as the editors draft, which is http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html#c14n-reqs

The above example pertains to

<pdatta> ancestor-or-self::bar:Something and

<pdatta> ((name() != "bar") or parent::bar:Something) and

<pdatta> ((name() != "foo") or parent::foo:Something) and

<pdatta> ((name() != "baz") or parent::baz:Something) and

<pdatta> ((name() != "") or self::text())

<pdatta> <bar:Something xmlns:bar="http://example.org/bar" xml:lang="en-ie">

<pdatta> <foo:Nothing>

<pdatta> <foo:Something xmlns:foo="http://example.org/foo">

<pdatta> <bar:Something xmlns:bar="http://example.org/bar">

<pdatta> <foo:Something xmlns:foo="http://example.org/foo">

<pdatta> <foo:Nothing>

<pdatta> <foo:Something xmlns:foo="http://example.org/foo">

<pdatta> <baz:Something xmlns:baz="http://example.org/baz"></baz:Something>

<pdatta> </foo:Something>

<pdatta> </foo:Nothing>

<pdatta> </foo:Something>

<pdatta> </bar:Something>

<pdatta> </foo:Something>

pratik notes this says that if parent is bar then only bar namespace allowed, if foo, then only foo , etc

<pdatta> </foo:Nothing>

<pdatta> </bar:Something>

pdatta: Expected output after applying XPath filter

konrad on namespace undeclarations http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0114.html

<klanz2> yes, namespace nodes get removed from the document subset selection

<pdatta> I want to not have to require this complexity in C14n

<pdatta> because this just adds to the complexity without adding any value,

<klanz2> Isn't is that unselecting namespace declarations has no use case ...

<psaintan> (sorry, I need to drop off the call now)

pratik notes input to canonicalization should not be XPath Nodeset, but define a different subtree

pratik notes that this is already in document

<klanz2> ... it does not add value to remove namespace declarations as they are pure meta information that qualify a QName and hence have to be always there if used .

scott notes that signing attributes is not supported

konrad notes this is not useful

scott notes this should be made clear

<csolc> Say I just want to sign the value of an attribute.

<csolc> you could define the attributes as 1 nodes subtrees of the parent element.

scott wanted to clarify that transform simplification document change includes not allowing attribute canonicalization

scantor: The new approach would not support the signing of attributes, but that does not seem problematic to me.

pratik notes attributes represented in different ways in DOM and elsewhere, hard to represent

klanz notes c14n should maintain most of what infoset has on input, do not want to lose significant infoset information

<pdatta> In StaX there are no events for Attributes, so it is not possible to represent an attribute that does not have a parent

csolc notes lose much functionality of signing attributes

<klanz2> Well if an attribute moves from being an attribute to being a text node at the output you break the InfoSet

scott notes can still sign attributes in conjunction with element, just not in isolation

scantor: You would still have the ability to sign the attributes as part of the element, but not just the attributes only.

<klanz2> so if something changes the Infoset it should be a transform which really is a InfoSet Transformation ... (cf. Selection vs. Transformation --> XPath vs. XSLT)

hal notes attributes only have meaning in association with element

hlockhar: Signing only attributes would be meaningless

klanz notes that signing attributes only is item for best practices

scott notes goal is to sign xml not variations derived from xml

<klanz2> so you said bizarre, does this include pdf ? ;-)

scantor: Section is unclear

<klanz2> cf. xsl:fo

this is a conversation we've had before regarding XProc etc, so lets not dive into that conversation right now

<klanz2> hal: EXI is a valid serialization of XML ...

<klanz2> hal: what if you sign non xml ... how do you secure the meaning

<klanz2> +1 to hal

<klanz2> scott aren't you trading of security here?

semantic meaning is separate from canonicalization of xml, application dependent

<csolc> what we are defining a filter and canonicalization.

<klanz2> -1 to fjh that there is no generally accepted consensus on what XML is

<klanz2> +1 to hal

hal: What signature actually protects is a series of bytes

<klanz2> and is that mapping reproducible

hal notes that well formed xml and semantics for that defined by application. If is what is protected is not well formed then what is mapping.

<klanz2> mapping of XML -> non-XML: how is this defined

pratik notes that a different serialization still maps 1-1 to xml

what Hal might be suggesting is that we need to be clear on constraints to serialization

<klanz2> well, EXI can be subject to an XML Schema (XS1) does there exist an XML Schema (XS2) that allows you to forge the backward mapping ? I don't know

linkage of and

if we lose information in process then lose security

pdatta: If the input is not a nodeset how do we define the input?

... by the use of trees and subtrees

pratik suggests not allowing removal of xml:attributes since it would introduce complicity due to xml:base

pratik also notes xml:lang

pdatta: If we assume that attributes cannot be removed we can reduce complexity.

scott notes xml:lang should be treated like any other attribute

discussion of appropriateness of inheritance of attributes in xml namespace

pdatta: Input to canonicalization should be able to be represented as a stream.

question to all can this input be represented in streaming input model,

unmute kelvin

<pdatta> the input to the canonicalization is done in such a way that is be represented as a StaX event stream

<pdatta> I want to make sure that this can be represented by some other streaming parser, e.g. .NET's XMLWriter/XMLReader


pratik, current input in proposal is subset of nodeset

csolc: Can the result of the canonicalization be a nodeset?

pdatta: No.

csolc asks could have nodeset input to c14n but redefine c14n not to do inheritance etc and just have a single serialization

csolc suggests having earlier step which is filter

pratik need to know input is subtree, complexities of removing namespaces that are not used

<klanz2> Maybe a guiding answer to deciding what can be done in a document selection is every thing that does not change a Node in it's type or it's Information set wrt. to it's structure , ... Nodes seem to be useful granule to define what the parts of an XML document are, changes that go beyond selecting and unselecting them should not be performed in a document subset selection as this is then not a proper subset of the input document any more ...

<klanz2> cf. an attribute rendered as text node in the output was not in the original document

<klanz2> cf. an attribute without it's namespace defined was not part of the original document

<klanz2> cf. an element rendered without it's content however was part of the original document as it is a logical entity that existed in the original document

<klanz2> does this make sense?

does proposal address qnames? Relax certain guarantees

scott notes that QNames are a practical consideration, used in content is common practice


<klanz2> do you have a link for me

Avoiding default XML Schema values



Agreement not to modify best practices for this.

<klanz2> The net result being that what is verified will not be what was

<klanz2> signed and cause the signature to break.

RESOLUTION: To adopt Konrad's editorial "The net result being that what is verified will not be what was signed and cause the signature to break."

konrad notes Schema Centric Canonicalization might be useful for QNames in content

ACTION-226 closed

<trackbot> ACTION-226 Send an announcement to ws federation tc about published security drafts closed


fjh: Please review the open action list and close them. Mark them as pending when you are done.

<klanz2> What ScC14 does beyond ExcC14n: http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=62 from Subsection Headline "ScC14n extends Exc-C14n"

Summary of Action Items

[NEW] ACTION: Magnus to work with Brian on how to express verifiable randomness of curves in XML schema [recorded in http://www.w3.org/2009/03/10-xmlsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/03/17 16:11:17 $