RE: [GUMP] Build Failure - Security

Christian,

first of all, sorry for the delay in answering your question.
Please see for it inline below.

> -----Original Message-----
> From: Christian Geuer-Pollmann
> [mailto:geuer-pollmann@nue.et-inf.uni-siegen.de]
> Sent: Monday, November 26, 2001 5:26 PM
> To: xalan-dev@xml.apache.org
> Cc: Gregor Karlinger; Joseph_Kesselman@lotus.com
> Subject: Re: [GUMP] Build Failure - Security

[...]

> > So if your problem is that xml-security is sensitive to that difference,
> > we've got a more basic problem and we need to discuss  how to solve it
> > without doing undue damage to either project.
>
> The xml-security project is not affected by this bug because my
> implementation 'can live' with this bug and handles it appropriately. I
> think the problem is that some other "Canonical XML" implementations like
> the "IBM XML Security Suite" or "IAIKs IXSIL" depend on it.

Due to this bug we are currently computing the namespace axis for each ele-
ment that we detect in the node list to be canonicalized. So it is not a
MUST. But of course this is a workaround that is necessary because Xalan
does not comply to XPath regarding the namespace axis.

> Nevertheless, if this would be fixed, it could give more clean
> implementations of 'Canonical XML'.

I fully agree with this statement.

> For me, there is no need for a change.

With respect to c14n, I can live without a bugfix for Xalan for the moment.

Another issue is if there is a need to fix this bug, since the Reference
processing model of XMLDSIG is based on the XPath data model. If an
application programmer relies on this fact and uses an XMLDSIG
implementation
that uses Xalan for XPath processing, signature creation/validation could be
incorrect if XPath transforms are utilized that make use of the XPath
namespace
axis.

Think of the following (academic, I have to admit) example:

  1. Fetch the following XML document

     <AnElement xmlns:foo="bar">
       <AnotherElement/>
     </AnElement>

  2. Apply an XPath transform with an XPath
     "self::AnotherElement/namespace::foo". This should
     result in a node list containing a single node, namely the element
     "AnotherElement". But since the XPath implementation is buggy, an
     empty node list is the result of the transform.

  3. Final canonicalization: Although the c14n implementation is working
     correct (since it has implemented a work around for the Xalan bug),
     in this case the input for the hash computation will be nothing in-
     stead of "<AnotherElement>".

Liebe Gruesse/Regards,
---------------------------------------------------------------
DI Gregor Karlinger
mailto:gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------



>
> Gregor, does IAIKs implementation MUST get this bug fixed?
>
>
> Best regards,
> Christian
>
>
>

Received on Wednesday, 28 November 2001 14:48:08 UTC