Re: [dss] Namespace inheritance, other approach

[Trevor Perrin <trevp@trevp.net>]

Hi Konrad,

Comments below -


Konrad Lanz wrote:
> [...] 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.

I agree there's a potential for problems.  I think we need more analysis 
of the scope of these problems and the options for dealing with them. 
Maybe opaquely-encoding some things is best, but we don't want to 
opaquely-encode every external structure.


[...]
> 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.

Could you describe the attack?

I understand that a client that doesn't redeclare prefixes inside the 
payload might receive a signature on something he didn't intend.

However, since the server canonicalizes before signing, the server will 
always know what it is signing.  So this is simply a broken client 
getting broken results, which doesn't seem like a big deal.


> 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 
> <http://lists.oasis-open.org/archives/dss/200504/msg00047.html> (see 
> DssXmlPayload 
> <http://lists.oasis-open.org/archives/dss/200504/msg00047.html>).

I'd rather steer clear of defining our own subset of XML.

Could we simply say that clients MUST NOT send Input Documents that 
don't declare (or redeclare) all the namespaces they use?  And if 
clients violate that rule, the resulting server behavior is undefined? 
(i.e., servers may return an error, or a weird signature?)


[...]
>> 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.

In the case of <ds:KeyInfo>, I don't think how the namespace prefix is 
defined affects processing.  So I think we can take this case off our 
"problem list".


[...]
>> 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.

I don't understand the above.  In XML-DSIG, XML content is 
Normal-Canonicalized before signing.  All I'm saying is that to 
implement Normal-Canonicalization on the Input Document, the server does 
what is actually an Exclusive-Canonicalization.

This way, the Input Document is divorced from irrelevant DSS namespace 
context, and instead placed in whatever namespace context was specified 
by the client.  So the signature will cover the document as it exists in 
its original context, instead of in the artificial context of the DSS 
message.  (this may require the client to specify an 
InclusiveNamespacePrefixesList, for input to exclusive canonicalization).

Does this make sense?  Could you re-explain the XPath attacks and 
re-parsing issues you mention?


Trevor