Re: Namespace Injection in DSig 2.0

Scott,

as far as I understood the QNameAware parameter is set "manually" by the
signature generator. Hence, he can choose this parameter to contain all
the prefixed elements and attributes he used in the selection XPaths.
Thus, there is no automated logic involved on how to determine the
QNames/prefixes from an XPath; this is up to the developer. What did I
get wrong here?

best regards

Meiko

Scott Cantor schrieb:
>> The good news: but only if the developer did not use the new QNameAware
>> parameter properly.
>>     
>
> I'm not sure that's true...
>
>   
>> The details:
>> The Namespace Injection technique worked by exploiting the fact that
>> namespace prefixes used in XPath expressions were not "visibly utilized"
>> in the sense of Exclusive Canonicalization, hence their namespace
>> declaration was not protected with the digest over "SignedInfo".
>>
>> In the new specs, the proper use of the QNameAware parameter leads to
>> explicit declaration of exactly those mappings.
>>     
>
> I don't think so. XPath expressions are not QNames. They contain prefixes,
> or perhaps even something that is basically a QName, but the QNameAware
> parameter is *not* currently used for describing content that can contain a
> QName, but only for describing content that is itself solely a QName.
>
> In other words, the burden was not meant to be on the c14n layer to go
> parsing into content to find them.
>
> Dealing with XPath expressions is a separate (and more complex) problem. If
> we were to try to extend the option to cover them, I think we would have to
> be able to describe how exactly the c14n layer was supposed to process the
> expression and find the prefixes.
>  
> -- Scott
>
>
>   

-- 
Dipl.-Inf. Meiko Jensen
Chair for Network and Data Security 
Horst Görtz Institute for IT-Security 
Ruhr University Bochum, Germany
_____________________________
Universitätsstr. 150, Geb. ID 2/411
D-44801 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de

Received on Thursday, 2 September 2010 14:34:14 UTC