EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Decrypt Smime with xmlfile attached, no data in xml file

Posted: 11/05/2009 07:06:18
by  Flemming Hansen

Im trying to use your SecureBlackBox v. 6.0.144 (have also tried the latest 7.1.163) to decrypt a SMime message with attachments.

When i try to extract an xml file the content of the xml file is empty.
Other types of files (txt, gif) seems to work fine.

I have tried to use your sample application SecureMail_VS2005, from the samples directory as well as the 2008 version from the 7.1.163 download.
Using the decrypt Smime message, choosing the attached 1xmlfile.txt file, and using the attached encryptercertificate.pfx (empty password).

My code and the sample application will extract and report all well, but the content of the xmlfile in the email is empty.
I have attached the dkalafsendermetadata.xml file, which is the xmlfile that should be in the email.

I can extract the name, ContentType and all info about the xmlfile from the message, but not the data itself.

Any idea what im doing wrong?

My setup is:

Outlook 2007 with a client OCES certificate, (signer)

The Outlook user sends an email with a xml file as attachment,
and chooses to encrypt message (using the certificate in encryptercertificate.pfx)

I can read all data and the content of the xmlfile in the receiver mailbox (Outlook Web Access)

When i try to use SecureBlackBox to get the data i miss the content of the xmlfile, but all else seems to be there.

Kind Regard


[ Download ]
Posted: 11/05/2009 08:18:00
by Alexander Ionov (Team)

Thank you for your message.
As far as I understand you use .NET version of SBB?
You decrypt the message from the file 1xmlfile.txt to the file 1xmlfile.eml using SecureMail sample application and got no xml file attached?
I'll try to decrypt the file manually to make sure it actually contains an xml attachment body. Will let you know on result.

Best regards,
Alexander Ionov
Posted: 11/05/2009 09:26:01
by Alexander Ionov (Team)

The issue confirmed. Trying to find the reason... Will let you know on result.

Best regards,
Alexander Ionov
Posted: 11/06/2009 10:16:41
by Alexander Ionov (Team)

The reason is found.

Some facts in the attached message:
1. There is an xml file attached and this part has 'text/xml' as its content type
2. The attached xml file uses utf-8 charset encoding but the Content-Type field doesn't have a charset parameter specified.

The behavior: when SBB finds a text/* part it tries to convert it from the specified charset to unicode. In this case there is no charset specified and SBB acts accoding to MIME standard and tries to convert from 'us-ascii' charset to unicode (but the file is in UTF-8!). This try fails and the part is left empty.

To avoid such collisions at the moment you can either specify another content type (for example, application/octet-stream, not text/xml) or specify the correct charset in the field:
Content-Type: text/xml; charset="utf-8"; name="dkalafsendermetadata.xml"

Tomorrow I'm gonna change ElMessage class not to convert text parts if they are attachments (and no original charset is specified?). The changes will be available in the next official SecureBlackbox build.

Best regards,
Alexander Ionov
Posted: 11/06/2009 10:22:00
by  Flemming Hansen
Hi ionov

Thanks for the reason.

My problem is that the mail is sent from an Outlook user so i cant change the format before i receive it, and i cant expect the outlook user to send it correct.

Do you mean that i should be able to change the content-type during the decrypting process?
Posted: 11/07/2009 05:53:38
by Alexander Ionov (Team)

I'm not sure you're able to change the content-type during the decrypting process because I did not see your code. The message is signed and encrypted. So to get the xml data from the message the following should be done:
1. The message has to be parsed and decrypted.
2. The signature should be verified and the signed data has to be extraced.
3. The data extracted on step 2 has to be parsed and at last the xml data can be stored into an external buffer/file.
If you cannot change the constructing process you have to change content-type of the attachment (and only of the attachment) in the extracted signed data after step 2 but before step 3.

Also you can wait several days until new SBB build is available - the problem will be fixed in it.

Best regards,
Alexander Ionov
Posted: 11/09/2009 07:57:39
by Alexander Ionov (Team)

The issue seems to be fixed and the changes will be available in new SBB release later this week.

Best regards,
Alexander Ionov
Posted: 11/16/2009 10:01:21
by  Flemming Hansen
Hi ionov

Any date on the next SBB release, we are starting testing and would like to get the latest version with the new changes included.

I expect it will be available in Beta edtion first...
Posted: 11/16/2009 13:45:18
by Eugene Mayevski (Team)

No, it will be release tomorrow or on Wednesday (depends on how fast it will be built and whether everything goes smoothly).

Sincerely yours
Eugene Mayevski



Topic viewed 2305 times

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


Back to top

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

Got it!