EldoS | Feel safer!

Software components for data protection, secure storage and transfer

cmsmessage/cmssignature interoperability question

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#12508
Posted: 02/20/2010 04:42:16
by Christoph Moar (Standard support level)
Joined: 08/28/2009
Posts: 46

Hi,
some weeks ago i finished migrating a project from a different vendor library to eldos. You helped me out a lot that time. Tests with other software (from the previous vendor) showed no problems in interoperability of signatures and timestamps.

Before releasing the application, I tried the signed messages with verifying software from a third and fourth vendor, and unfortunately I realized I must be doing something wrong. I bet I am simply missing a flag or a indicator somewhere, but I tried and tried with different flags in the cmsmessage or cmssignature class, but could not find the mistake.

Attached you'll find two messages:

1) c000019877.p7m
This is a message created with a third-party-software (which I will later use to verify my messages). It is a simple file with one simple signature.

2) T000003354.TXT.p7m
This is a message created with ELDOS and should contain just a simple file and one simple signature. (do not worry about the invalid certificate validity itself, this is just a simple soft token and it is not the real issue here).

When I verify the message (2) with my previous vendor toolkit, everything is fine, it shows a signed message with a valid verification. When I verify the same message with the toolkit of vendor (1), the toolkit seems to think that this is a timestamped message, and not a signed message. It clearly shows a "timestamped" message and tries to do a timestamp verification, which fails. So it marks the message as invalid !!!

--

Can you please help me to find out what is the difference between the two and what option I need to use to create a message the resembles (1) and thus can be verified by the other vendor?

--

This is how I created the signed message, shortly in pseudocode:

aMemoryCertStorage->Clear();
aMemoryCertStorage->Add(mCertificate, true);
TElSignedCMSMessage aMessage;
aMessage->CreateNew(aInDocumentStream.get(), 0, aInDocumentStream->Size);
int aNr = aMessage->AddSignature();
TElCMSSignature *aSignature = aMessage->Signatures[aNr];


aSignature->SigningTime = UTCNow();
aSignature->SigningOptions << csoInsertMessageDigests << csoInsertSigningTime << csoIncludeCertToMessage;
aSignature->DigestAlgorithm = mSignatureHashMethod;
aSignature->Sign(mCertificate, aMemoryCertStorage.get());


I tried changing the signingoptions in various ways, but that did not help. I tried to use code similar to the one in Samples\Delphi\PKIBlackbox\CMS (similar, I am using c++ builder):

aSignature->ClearTimestamps();
aSignature->ClearCountersignatures();
aSignature->ClearValidationTimestamps();
// setting up the necessary properties
aSignature->SigningTime = UTCNow();
aSignature->CommitmentTypeIndication->Included = true;
aSignature->CommitmentTypeIndication->ProofOfOrigin = true;
aSignature->CommitmentTypeIndication->ProofOfCreation = true;
aSignature->UsePSS = false;
...

but that did not help either. I must be missing something obvious here.
Can you please help me to find out the incompatibility and how to change it?


Thanks a lot!


[ Download ]
#12516
Posted: 02/22/2010 01:41:00
by Ken Ivanov (EldoS Corp.)

Thank you for contacting us.

There is one major difference between the signature created by the third-party product and the one created by SBB. The one created by the third-party vendor does not contain any additional attributes (such as message digest, content type or signing time). First of all, please try to turn off inclusion of those attributes and check if it changes something. Remove the csoInsertMessageDigests, csoInsertSigningTime and csoIncludeCertToMessage flags from the SigningOptions set to prevent the attributes from being written to the signature.

Besides, the third-party signature specifies version 1 for the signature content (SBB uses the value of 3 by default). If the above does not help, please try to set TElSignedCMSMessage.ContentVersion property to 1.
#12518
Posted: 02/22/2010 02:19:49
by Christoph Moar (Standard support level)
Joined: 08/28/2009
Posts: 46

Hi Innokentiy,
i had tried already removing all additional attributes (setting the value of SigningOptions to zero), but that did not help.

The option to change the ContentVersion property to 1 did work instead, now the third party product (DIKE, which is one of the mostly used in italy since the chambers of commerce provide it to all companies) correctly identifies the signatures created by ELDOS.

A second Tool I used to check the signature, a online verifier by the Italian Post Authority (https://postecert.poste.it/verificatore/servletverificatorep7m?tipoOp=10) did behave the same:

If I pass the ContentVersion to 3, it shows "failed" on the inner message body (not on the signature itself). If I pass ContentVersion to 1 it works correctly.

Our previous toolkit (Actalis) works fine with ContentVersion 1 and 3.

Question:
What does this ContentVersion state? Is this the S/MIME Version level? I could not find the property nor method in the HTML documentation (that's probably why I never tried to change it).

Are there any bad implications in setting this value to 1? Are there any other values I should try (how about the value of 2? does that exist?).

I will obviously notify the other vendors that they have a compatibility issue here, but for the time being its probably better that I try to go down just to avoid any issues...

thanks for your help!
christoph
#12519
Posted: 02/22/2010 02:46:17
by Ken Ivanov (EldoS Corp.)

Most of the products understand versions 1 and 3 correctly (there is no version 2 declared). RFC 5652 declares the following algorithm for choosing message version:
Quote

IF ((certificates is present) AND
(any certificates with a type of other are present)) OR
((crls is present) AND
(any crls with a type of other are present))
THEN version MUST be 5
ELSE
IF (certificates is present) AND
(any version 2 attribute certificates are present)
THEN version MUST be 4
ELSE
IF ((certificates is present) AND
(any version 1 attribute certificates are present)) OR
(any SignerInfo structures are version 3) OR
(encapContentInfo eContentType is other than id-data)
THEN version MUST be 3
ELSE version MUST be 1

According to the above algorithm, the appropriate version number for your case would be 1. Due to historical reasons SBB defaults to the version number of 3. I assume we would have to add some heuristic algorithm for automatic version setting in future.
#12520
Posted: 02/22/2010 03:00:52
by Christoph Moar (Standard support level)
Joined: 08/28/2009
Posts: 46

Wow. Thanks for explanation. Unfortunately I have only partial knowledge of the details the algorithm is talking about, so please accept this (hopefully last) question:

-- IF ((certificates is present) AND
---- (any version 1 attribute certificates are present)) OR
---- (any SignerInfo structures are version 3) OR
---- (encapContentInfo eContentType is other than id-data)
-- THEN version MUST be 3
-- ELSE version MUST be 1


So you state that "for my case" Version should be 1. Do you intend that I should keep the SigningOptions == 0? Or should I include any of these SigningOptions and still keep Version 1? As I understand your first reply, the other tool did not include messageDigests, SigningTime or ContentType. Fine for me.

What about csoIncludeCertToMessage or csoIncludeCertToAttributes?
Should I (is it better to? do i have to?) include one or both of them?


1 csoInsertMessageDigests if this flag is enabled, message digests will be included to the signature.
2 csoInsertSigningTime if this flag is enabled, signing time will be inserted to the signature.
4 csoInsertContentType if this flag is enabled, ContentType will be included to the signature.
8 csoUseGeneralizedTimeFormat if this flag is enabled, the generalized time format will be used.
16 csoIncludeCertToMessage if this option is enabled, the signing certificate will be included to the signature.
32 csoIncludeCertToAttributes if this option is enabled, the signing certificate will be included to attributes.



Thanks again for your help,
regards

Christoph
#12521
Posted: 02/22/2010 03:23:32
by Ken Ivanov (EldoS Corp.)

Quote
Do you intend that I should keep the SigningOptions == 0? Or should I include any of these SigningOptions and still keep Version 1? As I understand your first reply, the other tool did not include messageDigests, SigningTime or ContentType.

SigningOptions is not related to signed message version. The other tool really does not include any of the attributes, but some processing applications require at least message digest attribute to be present. So if the third-party tools you need to be compatible to do understand your signatures with message digest attribute included, it would be a good idea to keep it.

Quote
What about csoIncludeCertToMessage or csoIncludeCertToAttributes?
Should I (is it better to? do i have to?) include one or both of them?

It depends on whether the receiving party does have the signing certificate locally (to be able to perform validation). The most compatible way would be to enable the csoIncludeCertToMessage flag but to disable the csoIncludeCertToAttributes one.
Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.

Reply

Statistics

Topic viewed 1450 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!