EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TElXMLSigner canonicalisation inc-exc

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#4859
Posted: 02/06/2008 10:38:56
by Cees Lieshout (Standard support level)
Joined: 02/06/2008
Posts: 10

I want to use the TElXMLSigner to sign a part of a XML message on a client machine ( with a smartcard reader). The communications server will later on send a soap request with this part XML included.
My problem is with the use of canonicalisation set to xcmCanon the namespaces from the parent XML are included ( I don't have them when I sign the (part)message on the client). When I use the xcmExclCanon the transform methode writen in de signedinfo block is TR/2002/REC-xml-exc-c14n-20020718 where I exptected 2001/10/xml-exc-c14n. If I check the output message with xcmExclCanon set, for example with XML editor oXygen, it raises an error Unknown canonicalizer.

Can anybody help, for instance can the methode be set manualy or is the methode TR/2002.... correct and the editor wrong....
#4863
Posted: 02/06/2008 13:41:53
by Dmytro Bogatskyy (EldoS Corp.)

Default uri for exclusive canonicalization is "http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/"
You can modify the default value using:
SBXMLDefs.xmlCanonicalizationExcl.DefaultVersion := 'http://www.w3.org/2001/10/xml-exc-c14n';
#4884
Posted: 02/07/2008 07:39:27
by Cees Lieshout (Standard support level)
Joined: 02/06/2008
Posts: 10

Thanks for the quick response.

I'am now able to generate the (correct?) message. Unfortunately the result gives a signature not valid when I try to check it with oXygen. What I also discovered (and that is perhaps the reason) is that the digestvalue is different when I sign the submessage standalone against the value it returns when I sign it as part of a message. I exptected the digest (the sha1 hash) to be the same, when using exclusive canonicalisation.
I've modified the sample app simplesigner to return the canonical form ( signode.GetOuterXMLCanonical( xcmExclCanon )) and the digest I calculate manualy corresponds with the one the component returns when I encode the submessage (on its own). Apparently this is not the correct string in case of the submessage being a child in a larger message.

Is this perhaps the difference between the TR/2002.. and 2001/10 methode?
Or is my assumption that the hash of the submessage standalone and as part of a larger message should be the same, not correct.

Thanks for your help
#4891
Posted: 02/07/2008 08:59:32
by Cees Lieshout (Standard support level)
Joined: 02/06/2008
Posts: 10

Since I wasn't sure if I hadn't broken something in the original sample I reloaded it and tried again. I've added the line ( in mainform.pas/simplesigner.exe):
Signer.CanonicalizationMethod := xcmExclCanon;
just after
Signer.CanonicalizationMethod := frmSign.CanonicalizationMethod;

The resulting digest value is the same. The resulting digest generated from oXygen is also the same when using inclusive canonicalisation. The property CanonicalizationMethod doesn't seem to affect the result.

The CanonicalizationMethod is set to TR/2002/REC-xml-exc-c14n in the resulting XML, but the digest is the same as with inclusive.

Is this the right way to force excluded Canonicalization?


#4908
Posted: 02/07/2008 13:43:23
by Dmytro Bogatskyy (EldoS Corp.)

Quote
Is this the right way to force excluded Canonicalization?

I think, you need to set exclusive canonicalization for transform and not globally (for SignedInfo element).
To set it for a transform, please modify a sample in following way:
remove line:
Ref.TransformChain.Add(TElXMLC14NTransform.Create);
add
C14NTransform: TElXMLC14NTransform;
C14NTransform := TElXMLC14NTransform.Create();
C14NTransform.CanonicalizationMethod := xcmExclCanon;
C14NTransform.InclusiveNamespacesPrefixList := 'name_space_prefix'; // for example: 'ds enc'
Ref.TransformChain.Add(C14NTransform);

Quote
I've modified the sample app simplesigner to return the canonical form ( signode.GetOuterXMLCanonical( xcmExclCanon )) and the digest I calculate manualy corresponds with the one the component returns when I encode the submessage (on its own). Apparently this is not the correct string in case of the submessage being a child in a larger message.

Possible, you need to pass a second parameter with inclusive namespace prefix list.

P.S. If you still have a problem, then please post a xml document sample which exposes a problem to helpdesk.
#4924
Posted: 02/08/2008 10:29:58
by Cees Lieshout (Standard support level)
Joined: 02/06/2008
Posts: 10

Thanks again, I've created the message as I exptected it (with the correct hash). I've removed the
Ref.TransformChain.Add(TElXMLEnvelopedSignatureTransform.Create);
and replaced it with your code. Seems to work, the message is exl and the id's look alright. However the message (file outa) doesn't verify ( with the same sample app simplesigner ).
The reference(form) report's a different hash.

If I also include the transform EnvelopedSignatureTransform the message (file outc) verifies in simplesigner but not in my testeditor oXygen. The message signed with the "normal" sign stil verifies in simplesigner and in oXygen.
I've included the three messages, I made them simpler but with the inclusive and excl still different.

outa: with the changes you suggested.
outb: signed without changes inclusive
outc: with the changes but with the envelope transform

Any suggestions will be appreciated, thanks.


[ Download ]
#4934
Posted: 02/08/2008 18:17:26
by Dmytro Bogatskyy (EldoS Corp.)

For "a" case the enveloped signature transform is necessary, because when you sign the xml document without it the canonicalized data will be follows:

<data>...

on verification:

<data>...
<Signature>..

So, the digest will be different.

P.S. Checking "c" sample
#4945
Posted: 02/10/2008 08:47:05
by Dmytro Bogatskyy (EldoS Corp.)

The case "c" is fixed. The problem was in default namespace, exclusive canonicalization had processed elements in the same way as "#default" set in inclusive namespace prefix list, this was incorrect. Fixed.

P.S. oXygen software incorrectly process normal canonicalization, it is omit default namespace when canonicalize, so if you sign your xml document with oXygen it wouldn't be possible to verify with SecureBlackbox.XML.
#4950
Posted: 02/11/2008 03:06:37
by Cees Lieshout (Standard support level)
Joined: 02/06/2008
Posts: 10

It's getting clearer.

When you say "is fixed", you mean in the component? So I need to download a fix? I'm currently using the (still) trial component's. Or is it possible to configure the transfoms so that it wil give the correct output.
I will try to order the source code today, I'm sure we will get the job done with de blackbox.xml, certainly with such feedback on the forum.

Thanks.
#4966
Posted: 02/11/2008 18:00:37
by Dmytro Bogatskyy (EldoS Corp.)

Quote
When you say "is fixed", you mean in the component? So I need to download a fix?

It should be available in the next build. The RC1 is expected in a few days.
Quote
Or is it possible to configure the transfoms so that it wil give the correct output.

Unfortunately no. It possible to set inclusive namespace prefix list, then hash value will be generatad correctly, but it seems oXygen software doesn't understand them.
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.

Reply

Statistics

Topic viewed 5682 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!