See also: IRC log
<trackbot> Date: 10 March 2009
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0015.html
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.
fjh: made slight adjustments to the minutes
http://lists.w3.org/Archives/Member/member-xmlsec/2009Mar/0006.html
RESOLUTION: Minutes from 3 March approved.
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
http://lists.w3.org/Archives/Member/member-xmlsec/2009Mar/0007.html
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
http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0113.html
fjh: We are waiting on action from Brian.
http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0102.html
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].
http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0008.html
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
http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0007.html
recorded as ISSUE-109, fixed in editors draft
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0645.html
fjh: I made a substantial revision the the draft.
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0662.html
http://dev.w3.org/2006/waf/widgets-digsig/
note that ISSUE-56 should be closed
Timestamp References Add references related to timestamping
RESOLUTION: Issue-56 should be closed.
ISSUE-56 close
http://www.w3.org/2008/xmlsec/track/issues/56
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
http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0016.html
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
http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html
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
... 3.4.2.1 is about prehashing
pdatta: I do not want to have agreement on this call, but just want to have a discussion.
pdatta: 3.4.2.3 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 3.4.2.4
<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 3.4.2.2 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 3.4.2.2 and 3.4.2.4
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, 3.4.2.4
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
http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html#id83690
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?
3.4.2.5 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
http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0119.html
http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0121.html
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
http://www.w3.org/2008/xmlsec/track/actions/open
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"