Re: [dss] Namespace inheritance, other approach

[Trevor Perrin <trevp@trevp.net>]

Inline -

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

I understand now, thanks - you're saying subverted client software could 
produce a DSS request that wasn't what the user of the software wanted. 
   The user might not notice this misbehavior if he inspects the request.

I'm not too worried about that.  However, I agree we should require the 
server to disallow Input Documents that don't redeclare the namespaces 
they use.  That should take care of the problem.


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

I believe Exclusive canonicalization on the server-side would render the 
removed namespace nodes if they were declared and used in the Input 
Document, or if they were passed as inputs to the canonicalization 
algorithm (see the InclusiveNamespacesPrefixList):

http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/

So we'd have to arrange for the client to specify an 
InclusiveNamespacesPrefixList in the request (or maybe we could assume 
that any namespace prefixes that the client redeclares in Input 
Documents but doesn't use should be on that list?).


Trevor wrote:
>>  - 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.

 From the above, it sounds like the problem is that server-side XPath 
transforms could depend on the entire document, so any method we use to 
transmit a fragment of a document (regardless of whether we encode or 
canonicalize it) will have problems.

How does client-side exclusive canonicalization fix that?

(offhand, it seems to me the solution might to accept limitations on the 
transforms the server can apply.  But I'm not sure I understand the 
issue yet).


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

I'm still trying to understand the situations where the client would 
need to add an exclusive canonicalization transform.  If you could 
explain that some more, I'd really appreciate it.


Thanks,
Trevor