Re: Action-565: Visible Utilization in XPath

Scott Cantor wrote:
>> *Approach #3: prohibit QNames in XPath*
>>
>> Instead of using QNames in XPath, we force the XPath expressions not to
>> contain any QNames. For namespace-free documents this means no change,
>> for namespace-aware documents this requires sth. like putting
>> "/*[local-name()='Body' and
>> namespace-uri()='http://www.w3.org/2003/05/soap-envelope']" instead of
>> "/soap:Body".
>>
>> Drawbacks:
>> High threat of developers to screw it up.
>>     
>
> This is the one that I think should be recommended but not required. QNames
> in content are simply bad things. We know that now, and the remanining uses
> of them are from specs that predate that knowledge. Which is life. But where
> there are alternatives that allow the same functionality without using them,
> we would be crazy IMHO not to bless those approaches as being better for use
> with signatures.
>
> Developers will screw up anything and everything, and that's also just life.
> That shouldn't prevent us from documenting workarounds that actually *solve*
> this problem. It's quite rare in these cases for such solutions to actually
> exist at all.
>   
Yes, to some extent we can cope with the QName issue with this one. The
only issue I have is that it does not fix the prefix itself. Hence, a
namespace injection technique might still be possible if the referenced
elements are referred to by QName anywhere else in the document. That
QName then relies on the prefix, which may point to a different
namespace uri than given in the XPath.

I recommend this one as well, for most cases it does its job. However, I
think we can't force its usage to all signers, as it depends on a
namespace-aware XML/XPath processor. Legacy systems may fail in
evaluating that properly.

Additionally, we are making it *very* complex for a human developer to
determine what actually has been signed with a given signature. The same
for the signer: if automation works properly, everything's fine. But if
a developer has to hand-craft this XPath, there's a large set of
possible mistakes, and XPath does not throw exceptions in such cases! It
simply sticks to "nothing has been referenced, so nothing has to be
signed". Which reminds me of something....I'll write a separate mail on
this....

I have to admit this approach is not my own mind's result, hence I'm not
sure regarding any patents/intellectual properties on this.
>   
>> *Approach #4: listing used QNames explicitly*
>>
>> On signature generation, when defining the XPath expressions for the
>> signature reference, this approach requires an explicit statement
>> listing all QNames used in the XPath as part of its definition.
>>
>> Example:
>>
>> <IncludedXPath QNames="soap:Body
>> my:Node">//soap:Body/my:Node</IncludedXPath>
>>
>> Drawbacks:
>> Requires changes to XML Signature 2.0 syntax, threat of forgetting
>> used/adding unused QNames.
>> Puts additional tasks to the signature generator.
>> Somewhat redundant information.
>>     
>
> I think this one is also worth considering, because changing the syntax is
> not a drawback at this point (we're in draft) and because it's likely that
> the creator of the XPath expression is in a good position to know what
> QNames are actually being used, seems to me.
>   
Maybe we could take this as a fallback option? Its risk is that the
verifier would be forced to check whether the given list of qnames
actually is correct, i.e. does not miss any QNames given in the XPath
nor adds unused ones. Otherwise we end up with failing interoperability
if the signer uses a different approach than the validator (e.g. one
using the given QNames for exclusive mode C14N, the other one parsing
the XPath for detecting the prefixes for exclusive C14N => failure)

We proposed some variants of this in our paper, I'll send around tomorrow...

best regards

Meiko

-- 
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. IC 4/150
D-44780 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de