Re: [dss] Namespace inheritance, other approach

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Trevor Perrin wrote:

I'm wondering if the <XMLData> namespace-inheritance issue is less of a problem than we thought, and can be handled more elegantly than with opaque encodings.

There exists a solution in namespaces for xml 1.1 section namespace scoping, but this hardly helps,
if we want to support xml 1.0. (see this email)
However as indicated in a previous email the default namespace can be scoped in xml 1.0 as well
(i.e. set xmlns="" inside <XMLData>, <KeySelector>, <SignatureObject> or the like respectively).

But now it's getting complicated.

Further I can imagine that at the time of inserting a XML structures which might be ripped out of their
original context, this context can be retrieved efficiently at the client side and placed inside <XMLData>,
<KeySelector>, <SignatureObject> or the like respectively.
(e.g. set xmlns:ds="http://www.w3.org/2000/09/xmldsig#" etc .... inside <KeySelector>)

Nevertheless this would require the server to make sure that no prefixes are used inside those XML structures
which have not been redeclared previously inside <XMLData>, <KeySelector>, <SignatureObject> etc.
Thus the XML structures would be having namespace declarations in scope but could not wrongly use them.
However these namespaces are still in scope and could cause troubles as they would be still visible
via an XPath or XPointer and coud cause trouble there.

Hence I doubt that we'd win a lot against a simple ancestry context free opaqueness requirement, which can be
explained far more easily.

The problem is that dss namespace prefixes could confuse the interpretation of documents, keys, or signatures (<XMLData>, <KeySelector>, or <SignatureObject> respectively), since these things are all XML structures that might be ripped out of their original context and plopped in DSS messages.

I agree, and I'd clearly state in the standard that an ancestry context free opaqueness requirement exists for the extraction
of these XML structures.

Problems can occur due to:
 1) XML structure uses namespace prefixes not defined by DSS

I'd say that a server should be very wary when signing data that uses prefixes defined by DSS and
not having redeclared them inside the payload which is to be signed. I can imagine that this is very
susceptible to attacks.

For <KeySelector> this might not be too serious however, I haven't thought this through.

However in very special cases where ds:Transforms of DocumentBaseType are used in combination
with XPath transforms in a way that  would produce elements having prefixes not being declared
in a canonicalized (transmitted) form any more, this might cause a problem.

Hence I'd clearly restrict that client side transforms should be restricted to transforms that produce an
output as indicated in this email (see DssXmlPayload).

 2) XML structure uses namespace prefixes defined differently by DSS

Here redeclaration of those namespaces could be used to solve the problem, but those declarations themselves might
cause troubles as they are not part of the original data.

 3) processing of XML structure depends on namespace prefixes "in context" (e.g. XML canonicalization of an input document)

1) is resolved by canonicalizing the XML structure, so it defines the prefixes it uses.

Those declarations themselves might cause troubles as they are not part of the original data.
(i.e. There is a difference between a <KeyInfo> having the xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
declaration or not). However it should not be a problem if it is always there.

2) is resolved by choosing prefixes for dss that don't collide (i.e., if your document uses xmnls:dss, then use something else for DSS itself).

XPath transforms might cause troubles (see above).

3) is resolved by specifying slightly different processing rules to exclude DSS-inherited context.  For example, in Signature Basic Processing, the Server should use Exclusive Canonicalization instead of Normal Canonicalization.

As currently only canonicalization can be done on data that has already been parsed you'd have to parse the data then exclusively canonicalize it and then parse it again, to get rid of all context. This would be an implicit ds:Transform done by the server that would have to go into the chain of ds:Transforms.

If exclusive canonicalization is to be done at the end only however one could write XPath transformations depending on the DSS or other namespaces in scope and mount attacks in this way.

An alternative might be to prohibit such XPath transformations, but I think it would be quite hard to enforce this.


best regards

Konrad