XML Security Working Group Teleconference
16 Sep 2008

 

 

<trackbot> Date: 16 September 2008

<scribe> Scribe: Juan Carlos Cruellas

Joint Meeting with XSL to discuss XPath

<fjh> XSL membership list, w3c member only , http://www.w3.org/2000/09/dbwg/details?group=19552

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0037.html

fjh: kindly asks to write also at the chat after speaking.

2) Joint discussion with XSL WG members regarding XPath

fjh: focus of this meeting: how to select nodes from a nodeset to increase performance
... we want to figure out what we may do as a minimum as a profile of XPath for XML sign

<Zakim> MSM, you wanted to ask for a little clarification of your expected use of this possible XPath subset / deployment expectations

MSM: do you intend to use XPath for selecting what nodes to sign/encrypt?

<MoZ> XPointer is your friend

fjh: yes, it is for selecting a subset of what is referenced by an URI.
... we talked of XPointer but we thought that it was not enough.

pratik: Select a subset of XPath worth for streaming....but not exclude useful use cases

<MSM> Sharon: isn't that in the Namespaces Rec? i.e. not in the XML spec?

fjh: namespaces prefixes and XPath, it is not clear if it is an issue.

<tlr> michaelK, is "the data model" the XPath 1.0 data model or the XPath 2 and xquery data model?

<tlr> MichaelKay: XPath 1.0 data model can deal with namespace undeclarations, even though not expressed in terms of XML 1.1

<tlr> (or namespaces 1.1)

<tlr> MichaelKay: model is future-proof, as each element has its own set of in-scope namespaces

MichaelKay: in the basic data model in 1.0 allows each node its own namespaces, and there is not much to be done in XPath 2 to deal with namespaces

<tlr> sharon: no formal profiles

fjh: what kind of profiles for XPath 2.0....

? There are not official profiles, but some profiles made by some groups.

<Zakim> MSM, you wanted to suggest that ns undeclaration does not turn up visibly in XPath surface syntax, but only in the evaluation of expressions

scribe: in XPath, each node has its inscope namespace declartaion.

The impact is not at the XPath level.

<fjh> anders: noted distinction of data model versus XPath, affects what is visible at node

<fjh> msm: application aware of namespace prefix undeclaration, then can handle model

?: If you use tools that are aware of ns undeclaration you may end up...

<fjh> msm: xpath expression will then match or not...

...with a node that in one subtree has ns but does not have it in another one.

<klanz2> I sense the real problem with namespace undeclarations, lies in the namespace fix-up performed in c14n and that the absence of a namespace declaration actually should reflect that it has been removed

<klanz2> http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Mar/0002.html

scribe: you should be clear whether ns undeclaration has to be taken into account

<Zakim> MoZ, you wanted to ask on having the chance to have access to a requirement document

<tlr> nope, I was thinking about exotic subsets. Need to think about that more.

<klanz2> the namespace:: axis of XPath allows you to select all namespaces although they are not in an output nodeset

<klanz2> so there is an impedance mismatch between NodeSets and what it means for a namespace declaration to be out of scope

Pratik: we need to be able to select multiple subtrees, but also some exclusions ....
... we have a list of subtrees, and a list of exclusion subtrees and the result would be what is signed...

<klanz2> http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Mar/0021.html

Pratik: I would not say that we have the requirement of signing a single attribute or a single element ....
... not requirement for very complex subsets.

Mike_Kay: XPath does not select subtrees, but nodes...
... one common missperception of XPath is precisely the selection of subtrees...

<klanz2> XPath is no transformation, just a selector language

Mike_Kay: you could make a query for selecting subtrees but then you are into another territory (not in the node selection one).

<fjh> Mike_Kay: can select nodes and then select nodes to exclude then perform operation to combine

klanz2: XPath is not defined for XML 1.1 and also the absence of ns undeclaration...
... the real problem deals with the way that xmldsig perceives the node set, as something that is transformed, not only selected.

<tlr> note that there is an XPath filtering transform defined in xml signature (and another one in XPath filtering transform 2.0)

? XPath defines a data model. ....and it would be possible to define a mapping from XML 1.1 to that data model.

<MSM> MK: it would be possible to define a mapping from XML 1.1 into the XPath 1.0 data model -- it wouldn't be the one defined in the spec, but the XPath 1.0 data model would in fact not need any changes.

<klanz2> That would be an interesting reference for us ...

Henry: there was an doc published for making XML 1.1 mapping to XPath 1.0
... although there was never a second document.

<MoZ> http://www.w3.org/1999/11/REC-xpath-19991116-errata/

<henryz> That's an erratum to XPath 1.0

<klanz2> Eventually, what we would need is namespace undeclarations in XML 1.0, sort of so that it would be defined for XPath 1.0 ...

<MSM> In particular, I believe Henry Zongaro is mentioning the set of changes given under the heading "Known errors as of 2 November 2005"

<fjh> mapped xml 1.1 model and namespaces to infoset and xpath model

Henry_Zongaro: specify mapping of XML 1.1 and XML 1.1 namespaces to Xpath 1.0.

<fjh> klanz notes nodesets that can remove namespaces are only serializable in xml 1.1

klanz2: the future of XML 1.1 is uncertain.. in addition the output of a XPath selection allows you to throw out the namespaces nodes....
... this might be interpreted as a namespace may be thrown from the node set...

<fjh> msm notes that linkages of xml and namespace versions

Mike_Kay: would an errata be worth to be produced for bringing the ns undeclaration in 1.0?

as I understand it ns 1.1 only affect xml 1.1

<klanz2> http://lists.w3.org/Archives/Public/public-xml-core-wg/2008Aug/0034.html

<klanz2> Point 7.

<fjh> MSM notes ns 1.1 and xml 1.1 have not been withdrawn

scribe: at the moment, the right behaviour is to account that at present there are two sets ....

Hal: three separate concerns:

1. we use xpath for two things: transforms that may modify (select, fi)...

separately we have canonicalization that is also impacted by xpath

scribe: in the selection, we would like to make undeclaration ns to work properly.

<klanz2> @hal: not to forget qname in content problems ... ,-)

scribe: and in canonicalization, we also deal with inclusive and exclusive canonicalization... in this last one, ns undeclaration could be a tool for dealing with these undesired ns
... the third concern is that we have some performances measures that say that if we keep the ns in the nodes, the time is double....
... I would not mix them up...

Pratik: a bit more on requirements. The main one is to sign a part of a document...

<Mike_Kay> Namespace nodes impose a performance overhead if you implement them naively. But the model can be implemented efficiently.

Pratik: if we go step back and realize that we want to sign a subtree and make some exclusions, it might be no so complicated...
... but if have a xpath followed by a canonicalization it is difficult to deal with it without having ns nodes in memory....

fjh: three questions. Perhaps XPath is not the right tool for what we are trying to do?
... Frederick, could you please add the other two questions?

<bhill> DOS concerns w/Xpath 2.0, loops, variables and remote doc dereferencing

<bhill> related to profiling

Streaming and profiling are the other questions.

?: Profiling: we are undertaking this work.

Mike_Kau: streaming. several attempts of implementing parts of XPath in streaming...
... but this required pretty sophisticated implementations...

fi. identity constraints in XML schema... which is a small part of XPath.
....problem: finding the balance between functionality on one side and usability on the other....
... another attempt in xml schema 1.1 for doing assertions...

<klanz2> Would you have links for those, please?
....problem: think that in xslt we will end up with some profile related to parts that might be streamed.
... concerned if each WG has its own view on trade-off between efficiency and usability: ....

<esimon2> +1 to Michael Kay re "each wg has its own view on trade-off between efficiency and usability"
....problem: if each group specifies its own subset, it would not be in the benefit of users community

<klanz2> Users of XMLDSig often forget to select namespace nodes to be in the output node-set, and there it's also second guessing if it was intended to remove namespace nodes ...

<klanz2> so c14n sometimes tries to fix this, but isn't really good at it ;-)

fjh: is xpath the right alternative for what we are looking for?

<csolc> maybe the XPath data model is what we don't want, may be just want XPath for the selection

?: Michael mentioned that it seems from what yo said that you need a transformation technology more than a selection technology

<klanz2> http://www.w3.org/TR/xmldsig-filter2/

thomas: there are two specs related to XPath: the XPath rec and the XPath filter rec...

<tlr> http://www.w3.org/TR/xmldsig-filter2/

<klanz2> http://www.w3.org/TR/xmldsig-core/#sec-XPath#

<klanz2> http://www.w3.org/TR/xmldsig-core/#sec-XPath

<klanz2> the latter is actually like the filterstep in XPath

<klanz2> fragmented subtrees

Mohamed: you do not want to select nodes, you want to select subtrees...
... and in these last ones, you want to exclude some parts...
... and this is not managed by Xpath...
... if the use case is simple, it is doable, but if you want to do something more complicated (information on the selection nodes, fi) then streaming would be complicated...

bruce, the sound is bad... I do not follow what you say...could you please type it in?

?: Only xsl wg will meet in Prague.

<bhill> additional requirement for xmlsec: handling untrusted and untrustworthy messages

<bhill> processing model currently requires handling XPath before message is authenticated

<klanz2> Should an C14n Vnext render namespace undeclaration on the removal of a namespace node from an element, and is it forced to use XML 1.1? Does the situation change when this namespace is actually used by the element in question?

<bhill> so a profile that addressed denial of service and other security concerns is important to u

Sharon: after that meeting in Prague, it could be possible to join by telco with the xmlsec wg.

<bhill> especially with XPath 2.0 being turing complete and allowing network operations (fn:doc)

<Mike_Kay> XPath 2.0 is not Turing complete. It is relationally complete.

<Mike_Kay> And you can disallow network operations: the set of accessible documents is defined by the processing context

klanz2: what is your view regarding serialization when ns have been removed?

<tlr> Mike_Kay, part of the concern is that implementations have been known to get these kinds of limitations wrong. E.g., proprietary XSLT extensionamespaces that permitted local file access not being turned off when processing untrusted content. Sucks, but there is a serious question how to prevent that from happening.

<Mike_Kay> Sure, there are issues with configuring products correctly for security. Not really a spec issue?

<tlr> klanz, I propose that you write up that question by e-mail, we're running out of time.

what shall be the implication in the serialization of an absence of a ns in a nodeset?

<tlr> Mike_Kay, the spec issue is how to make it harder to run into that kind of trouble.

fjh: thank you very much to xsl wg for joining this call.

<klanz2> thank you very much

<tlr> anil, is that you?

Joint XSL Meeting followup

<tlr> pratik: would like to see XSL's work on streaming

<shivaram> msg tlr aagg is shivaram

Pratik: analyze the two subsets that they mentioned (two streaming subsets)

<fjh> subset in schema 1.1 for identity constraints, no predicates uses

<fjh> also xml schema 1.1 for assertions, but now moving toward whole

fjh: we should look at those subsets...

Subu joins. Not able to join before because the call was full.

subu: followed the notes on the irc.

<fjh> xsl wg planning to work on streaming

fjh: konrad, what did you get on ns...

<fjh> q/

kl: know that you can remove ns from the nodes, and the semantics of a ns not being in a node set is completely undefined
... and xml canon still has teh problem of what to do with these ns nodes...

<klanz2> +1 to investigation the XPath serialization specs ....

tlr: a. we need figure out what subset we need , we need to look undeclaration scenario ...

to understand what we need and where things are broken now

<fjh> tlr notes a - need to write more precise requirements for subsets b, XPath 2.0 ad 1.0 serialization, possible alternative to c14n

<fjh> tlr notes, c, examples of undeclaration scenarios

<fjh> tlr notes, d, look at what XSL is doing with streaming

<tlr> yes

scribe: looking examples of undeclaration and check what happens now...

<klanz2> This ? http://www.w3.org/TR/xslt-xquery-serialization/

<klanz2> 23 January 2007

<klanz2> Quite new?

<tlr> pratik, yes, that is what Michael Kay seemed to mean

<fjh> heard that XPath 2.0 model can support namespace prefix undeclaration, if "features" are used properly

<tlr> fjh, I think you meant 1.0

<fjh> michael kay pointed to streamable specs

kl: we did deal with streaming...

Hal: streaming and performance are not exactly the same...

fjh: we need the two links to that stuff.

3) Liaisons and Coordination

Liaisons and Coordination

<fjh> TPAC EXI 2-2:30 Monday 20 October

XML Core: some more discussion on namespaces prefix undeclaration...

<klanz2> http://www.w3.org/TR/xmlschema-0/#ref29

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Sep/0016.html

<tlr> Paul and Norm are co-chairing XML Core.

<esimon2> For those who are not familiar with Michael Kay's Saxon XSLT processor, see http://www.saxonica.com/

<fjh> Xproc, next

fjh: scheduling a joint meeting with xproc

23 september.

Minutes Approval

<tlr> http://www.w3.org/2008/09/09-xmlsec-minutes.html

RESOLUTION: minutes of 9 Sept 2008 were approved

Best practices

Draft updated

fjh: concerns from Scott...
... are you planning to implement the changes in the new draft?
... another change thomas to update the status of the document...

Draft publication plan: brad implements the changes, publish it and we approve at the next call the draft

scribe: is that agreeable?
... propose to make a Resolution at the next call, assuming that the changes are OK.

Use Cases and Requirements

fjh: there are some req on web services and security....hal?

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0036.html

<fjh> hal noted concern over edge cases, which could cause differing validation results

Errata - KeyInfo

fjh: thread of discussions...

do we need clarification for decrypt? and other questions...

?: main issue there is not a rule mentioning the encoding of X509 cert apart from bse64...

scribe: I assume that it might be something missing in the spec that could be added....

<fjh> s/\?/scantor/

.brian: first, looking PKIX brings X509 cert in IETF...
... I do not know why do not reference the RFC from IETF

<fjh> brian suggests we reference RFC 2459 going forward...

.brian: as for encoding, I do not know anyone encoding X509 cert in not DER...

<fjh> brian notes that ASN.1 gives choice of encoding, could have various, but could profile to DER

<fjh> also noted that could have XML encoding, why not used?

.brian: one could ask why the xml sec does not support the widespread encoding for X509 certs.

<fjh> profiling could raise implementation issue

.brian: and we could add some attribute signaling that not the by default base64 of DER encoding is used, but other....

<fjh> brian notes x509 element could be DER by default, attribute to define if other encoding used

<klanz2> BEST PRACTICES?

<tlr> I think this part is beyond the scope of the best practice document. ;-)

<fjh> brian notes potential issue of DER encoded cert with extension that is not DER encoded

<fjh> http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-X509Data

<klanz2> SHOULD be DER encoded?

scantor: clarity is crucial...

<klanz2> is RECOMMENDED to be DER encoded?

scantor: if the spec wants to be open and allow different things, readers must be clearly informed in the spec.

<fjh> brian notes we can elect to specify encoding of top level of x509 but not internals

<klanz2> I agree as it is not specified it's open isn't it ...

<fjh> jwray notes no advantage to restrictive

jwray: decoding should not be a problem...

<fjh> since any ASN.1 library should be able to decode

scantor: looking for guidance in the spec...

<fjh> konrad noted that this can be noted as a best common practice

fjh: maybe as konrad mentioned this could be more a best practice?

sorry: I have quite a lot of delay...

kl: a recommendation would be worth...

<tlr> mhhh... I think what I heard was that there is no real interop problem there.

kl: but we should not rule out anything else...

<klanz2> I would suggest a similar processing strategy as with c14n 1.1...

<klanz2> http://www.w3.org/TR/xmldsig-core/#sec-ReferenceGeneration

hal: there are also elements that are not certs,....

konrad: similar strategy for canonicalization...when you generate signatures, we recommend somethihng...

fjh: ...and we also not e that when verifying use libraries that deal with them...

<klanz2> Do we have concensus, on what?

tlr: what is the gain of having this done?

<klanz2> Let's be specific ...

tlr: from what I have heard there is not an interoperability issue here?.

fjh: it seems that there are other groups that need some help after reading the spec.

tlr: then maybe is an issue of best practices...

<tlr> right

<tlr> XER? (http://en.wikipedia.org/wiki/XML_Encoding_Rules)

<fjh> bal notes for binary representation, then this is clear

<fjh> general agreement that more text to explain would be helpful

scantor: scanned for syntactical issues that should be fixed.

<klanz2> Let's minute this

conclusion: scot had what he required, but some more material could be added in the best practices (cryptobinary vs base64, fi).

scantor: keep the issue open....

v.next

kl: two items from previous discussion: there is a serialization nodeset defined in xpath.

<klanz2> http://www.w3.org/TR/xslt-xquery-serialization/

kl: xsl wg mentioned that serialization algorithm in XPath could be useful for us.

<tlr> http://www.w3.org/TR/xslt-xquery-serialization/

<fjh> konrad notes this may not be correct

<fjh> link

<tlr> I'm pretty sure the document above is the one that was mentioned

<fjh> ACTION: fjh follow up with XSL to get documents related to serialization [recorded in http://www.w3.org/2008/09/16-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-66 - Follow up with XSL to get documents related to serialization [on Frederick Hirsch - due 2008-09-23].

Issues List

No discussion

Open Action item review

fjh: please take a look to the list of open actions...

<klanz2> Just, FYI ...

<klanz2> ... then the additional serialization parameters MAY affect the output of the serializer to the extent (but only to the extent) that this specification leaves the output implementation-defined or implementation-dependent. ...

<klanz2> from http://www.w3.org/TR/xslt-xquery-serialization/