W3C home > Mailing lists > Public > public-xmlsec@w3.org > December 2009

Re: [ACTION-412][Fwd: Re: namespace wrapping attacks against XML Signature?]

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Tue, 29 Dec 2009 16:16:47 -0500
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>, "'Pratik Datta'" <PRATIK.DATTA@oracle.com>, "'Ed Simon'" <edsimon@xmlsec.com>
Message-Id: <563A7791-DB2F-44A0-8B90-42C213BAF17B@nokia.com>
To: ext Scott Cantor <cantor.2@osu.edu>
We probably should add more information on the issues related to  
prefix-rewriting to the requirements, with some examples like this. We  
need to be clear that it is not a complete explanation, but provide  
some information on the issues around the topic.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 29, 2009, at 3:30 PM, ext Scott Cantor wrote:

> Frederick Hirsch wrote on 2009-12-29:
>> We should add the following explanation, with some editing, to the  
>> 2.0
>> requirements on prefix rewriting , agreed?
>
> That material is an oversimplification though.
>
>> [[
>> After all, having the namespace prefixes covered by the signature
>> actually is some kind of violation of the idea of prefixes. As far as
>> I understood that concept, the prefixes don't have to be unique, and
>> may even be substituted within any processing instant if two prefixes
>> happen to cause a collision. The only requiredly unique setting is  
>> the
>> namespace uri and local name. Thus, if the (unlikely, agreed) case
>> happens that two XML documents are to be merged that both have the
>> same namespace prefix for different namespace uris, whereas XML
>> Signatures protect the chosen prefixes in both documents, you either
>> have to invalidate one of the signatures (by changing its prefixes)  
>> or
>> risk a processing collision (by keeping the same namespace prefix for
>> different uris).
>> ]]
>
> This assumes that you don't just ensure each piece is well formed to  
> begin
> with, with appropriate namespace declarations in each document.  
> Having done
> that, c14n takes care of signature integrity (modulo all the usual  
> issues
> with QName content that make that very hard to achieve in practice  
> and are
> NOT fixed by prefix rewriting).
>
> -- Scott
>
>
Received on Tuesday, 29 December 2009 21:17:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 December 2009 21:17:29 GMT