Hi everybody!
        I'm doing interoperability tests between the IAIK toolkit and the Apache XMLDsig C++, but I've found an error that I'd like to comment with you cause I'm not really sure it was a bug...        
       
        My scenario is the following:
                I've got a XML file with its schema. What I'm doing with both toolkits is to generate a signature from a particular XML node with one toolkit and then I try to verify the signature with the other one. This was working fine until I introduced the base64Binary element into the XML schema.
       
                What I've realised is that if the XML contains a base64 text identified with "xs:string" in the squema, the signature can be validated. In other words, both toolkits generates the same hash, so it's possible to verify this either with AIAK or XMLDsig toolkit.

The problem appears when this element is a "xs:base64Binary" instead of "xs:string"; in that case, AIAK toolkits generates the same hash as it was a xs:string element ( which I think is correct..), but XMLDsig generates a different hash! Is this a bug? Why the hash depends on the schema file?

Ah! The hash is different if the base64 text contains carry returns, but is correct if the base64 is written in the same line!

Could anybody tell me something about this? I'm using the last realease (xml_sec_1.1) for C++.
       
        Thank you very much in advance!

Ivan


>-<
This email has been digitally signed. You can verify its authenticity  by installing Safelayer's Root Certificate:
http://ca.safelayer.com/install_root.html
>-<

IMPORTANT NOTICE: This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender. The opinions expressed within this communication are not necessarily those expressed by Safelayer Secure Communications.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to