RE: Action-565: Visible Utilization in XPath

> 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.

True, but I think the intent behind identifying the prefixes isn't to
replicate the flawed InclusivePrefix concept, but to simply ensure they get
output in specific cases in accordance with normal exclusive c14n
processing. My point being that getting them output in the scope of the
XPath expressions may not get them output in scope of the other uses of the
QName anyway. May as well fix what you can.

> 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.

I can't imagine how it could be correct to use QNames but not understand
namespaces.
 
> Additionally, we are making it *very* complex for a human developer to
> determine what actually has been signed with a given signature.

I would claim this is a generic problem with XPath and is why I'm still more
interested in ID-based signatures and doing what can be done to mitigate the
threats with them.

> 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.

If it's just using XPath features that already exist, that would imply XPath
itself was encumbered, wouldn't it?

> 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.

Well, part of evaluating what was signed has to be evaluating, in context,
what the XPath "means". That context includes the namespaces in scope, so
the point is to evaluate it based on what the result of c14n of the XPath
selection material says it is, not based on custom namespace processing.

> 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)

I think it would have to explicitly part of the algorithm/spec to do it in a
particular way.

-- Scott

Received on Tuesday, 11 May 2010 16:39:28 UTC