Re: [dss] Namespace inheritance, other approach

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

Trevor Perrin wrote:

> Konrad Lanz wrote:
>
>> Essentially someone can use a malicious modified client to request a
>> signature over a dss:KeySelector in a not redeclared namespace, thus 
>> essentially retrieving a signature over a dss:KeySelector in the
>> namespace xmlns:dss="...oasis...." if the client by mistake losses 
>> original namespace context of the data.
>
> It's unclear to me who's the attacker and who's the victim - the last 
> paragraph says "maliciously modified client", but it also says "if the 
> client by mistake loses original namespace context".

Sorry, I admit that was a bit confusing.
What I am trying to say is that it is quite likely that the client will 
by mistake not redeclare namespaces for XMLData etc. in a correct fashion
or that some attacker changes the client in a way to make this mistake. 
Either way it's hard to spot for the requester of the signature.
Hence this data would produce signatures where the data is shifted to 
another namespace, from the surrounding protocol if using the same prefix.
(in the case of no prefix the default namespace in scope would be used.)
However this only happens if the server allows to inherit ancestry context.

So the fact that these unwanted signatures are produced and exist, can 
be exploited if the condition holds that the signed data
make sense in the namespace the data was shifted to.

> If the client is only tricking himself, I don't see a problem :-)

True, but the client might not know that it tricks itself, as the 
embedding of the data into the sign request technically fixes the defect
of a missing namespace declaration, but changes the semantics.

> However, I believe (and I'm hoping) that this mistake only affects the 
> client who makes it, and doesn't create an opportunity for attacking 
> the server or anyone else.

I hope so too.

>> Valid redeclaration of namespaces (II,IV) could be achieved by 
>> exclusive canonicalization on the clientside which would have to be 
>> added at the end of the ds:Transforms already applied by the client 
>> to ensure that
>> xmlns:dss="..." is always there.
>> This however would impose a considerable burden on the client.
>
> I'd like to understand your last paragraph:
>  - Does valid redeclaration of namespaces require exclusive 
> canonicalization on the clientside?

Assuming that also other client side transforms have been applied 
previously on the input document which
removed namespace nodes from the output node set, I would say something 
has to be done.

I suppose but I'm not entirely sure that exclusive canonicalization 
would render the removed namespace nodes
if they are still needed even though they might not be in the output 
node set.

The namespace nodes are still available at the client side and exclusive 
canonicalization would access them by using
the node in the output node set and the complete document.

>   Isn't it enough for the client to just redeclare the namespaces, and 
> leave the rest of canonicalization to the server?

I'm not entirely sure about all this, but I think this is only true if 
no client side transforms have been applied
and the document declares the empty defaultnamespace xmlns="" explicitly 
if applicable (i.e. dss uses the default namespace).

It will be also true for client side transforms which did not remove 
nodes from the output node set the server still would
access if it had the complete document..

However I think this is probably true for a typical case, but not for 
the general one and it is very hard to formulate a constraint
for the last condition.

> That seems less of a burden than full canonicalization, and 
> potentially less of a burden than opaque encoding.

I think it is only possible under certain constraints. However it would 
definitely allow thinner clients.

>  - Are you thinking the client would need to add exclusive 
> canonicalization to the list of ds:Transforms, and this would appear 
> in the output signature?

To cover the general case, yes.

Because if I'm not wrong XPath transformations do operate on the 
complete document and
while they reduce the output node set more and more, later XPath 
expressions can still depend
on all nodes of the document.

However as soon as one embedded the output node set into dss protocol 
and then transmits (canonicalizes/serializes) it
and then parses it at the server side the whole document is not 
available any more.

>> Summarizing all this is guaranteed by ancestry context free XMLData 
>> and the tools will throw an exception if a prefix appears that has 
>> not been declared inside the payload or at least inside XMLData.
>> I think it is also a lot clearer. Please see (II-V) for valid requests.
>
>
> Do you mean redeclaring namespace (like II-V) is a lot clearer, or 
> opaque encoding?

What I was trying to say is that ancestry context free XMLData has to be 
achieved and either realization is fine for a typical case.

However in the case of client side transforms and if the server applies 
further transforms that would need the complete document underneath,
even this might not be sufficient and require the client to do some 
exclusive canonicalization and add it at the end to the ds:Transforms.
If not then this Signature would probably not verify in non dss XML-DSIG 
applications.

best regards

Konrad