W3C home > Mailing lists > Public > public-xmlsec@w3.org > September 2008

Minutes: XML Security WG weekly 2008-09-16

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 23 Sep 2008 18:32:46 +0200
Message-Id: <70458B8E-C448-431D-8A94-EDBECE8B7DFC@w3.org>
To: public-xmlsec@w3.org

Minutes from our meeting on 16 September were approved:

   http://www.w3.org/2008/09/16-xmlsec-minutes.html

Regards,
--  
Thomas Roessler, W3C   <tlr@w3.org>






W3C
XML Security Working Group Teleconference
16 Sep 2008

Agenda

See also: IRC log
Attendees

Present
     Frederick_Hirsch (fjh), bal, Thomas Roessler (tlr), Henry_Zongaro  
(XSL WG), Sharon Adler (sharon)(XSL WG), Michael Kay (Mike_Kay) (XSL  
WG), Michael Sperberg-McQueen (MSM)(XSL WG), csolc, Mohamed Zergaoui  
(MoZ)(XSL WG),bhill, gedgar, smullan, Anders Berglund (anders)(XSL  
WG), Howard Tsoi(HowardTsoi) (XSL WG), Ed_Simon, pdatta, scantor, jcc,  
Hal_Lockhart, kyiu, klanz2, jwray, subu, shivaram
Regrets
     Bruce Rich
Chair
     Frederick Hirsch
Scribe
     Juan Carlos Cruellas

Contents

     * Topics
          1. Joint Meeting with XSL to discuss XPath
          2. Joint XSL Meeting followup
          3. Liaisons and Coordination
          4. Minutes Approval
          5. Best practices
          6. Use Cases and Requirements
          7. Errata - KeyInfo
          8. v.next
          9. Issues List
         10. Open Action item review
     * Summary of Action Items





<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/
Summary of Action Items
[NEW] 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 
]

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/09/23 16:28:55 $
Received on Tuesday, 23 September 2008 16:33:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:55 GMT