[openssl-users] How to produce a nested CMS / PKCS#7 structure?
I'm trying to produce nested structures, like signed-enveloped-signed data.
This is explicitly described in the various RFCs, but I can't figure out how to
get OpenSSL to produce valid output, and I can't find any code examples of
doing this.
What I'm doing (which doesn't quite work) is this: first I create the inner
content using (e.g.) CMS_encrypt(), getting a CMS_ContentInfo structure. This
works correctly and if I write it out I get what I expect. Then I want to
create another CMS_ContentInfo, e.g. using CMS_sign(), which envelops the first
one. How do I cause the ContentInfo of the SignedData structure to be the
ContentInfo I obtained from CMS_encrypt()? The closest I can come is code like
this:
CMS_ContentInfo *innerCms = ;// Create the inner CMS content.
BIO *inbetween = BIO_new(BIO_s_mem()); // Write it to a buffer.
i2d_CMS_bio(inbetween, innerCms);
CMS_ContentInfo *outerCms = CMS_sign(cert, key, NULL, inbetween,
CMS_BINARY|CMS_PARTIAL|CMS_NOSMIMECAP);
CMS_set1_eContentType(outerCms, OBJ_nid2obj(NID of innerCms)); // Set the
content-type
CMS_final(outerCms, inbetween, NULL, CMS_BINARY|CMS_NOSMIMECAP); //
Finalize the CMS structure
(My actual code checks all the return values, but I left those off for clarity.)
Unfortunately, this produces output like this:
ContentInfo {
contentType = :pkcs7-signedData;
content = SignedData {
... various ...
contentInfo = ContentInfo {
contentType = :pkcs7-envelopedData;
content = [0] EXPLICIT OctetString{...}
}
}
}
where the inner OCTET STRING contains *another* ContentInfo, which then
contains the nested object.
But from my understanding, the correct syntax for a nested CMS structure is
this:
ContentInfo {
contentType = :pkcs7-signedData;
content = SignedData {
... various ...
contentInfo = ContentInfo {
contentType = :pkcs7-envelopedData;
content = [0] EXPLICIT EnvelopedData {
...fields of the EnvelopedData structure...
}
}
}
}
In other words, I have two extra, incorrect levels of encapsulation: the OCTET
STRING and the extra ContentInfo.
In order to get the right output, I think I would need both a way to tell the
CMS structure to use the correct data type *and* the correct contentType OID,
and also a way to get to the EnvelopedData structure inside of the innerCms
structure. But neither of those things seems to be accessible using the OpenSSL
API.
Any hints? Surely someone has used OpenSSL to create nested structures in the
past?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SMIME signing with SHA1
Hello, > Am 22.11.2016 um 23:25 schrieb Dr. Stephen Henson : > > On Tue, Nov 22, 2016, Harald Koch wrote: > >> Hello, >> >> I???m facing a critical situation in my application when creating a signed >> SMIME message using SHA1 as message digest algorithm. In openSSL 1.0.2 (i.e. >> 1.0.2h), the following command worked as expected: >> >> /opt/openssl-1.0.2h/bin/openssl smime -sign -in original_message -signer >> cert_key.pem -md sha1 >> >> The message output contains a header using sha1: >> >> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; >> micalg="sha1"; boundary="??7E9FFA1842442B7192D83A53D8D35C89" >> >> >> With openSSL 1.1.0c, I get a segmentation fault with the same command. Using >> md5 or sha256 (or even not providing the parameter ???-md???, resultig in >> sha256) the command works as expected. Trying to determine where the >> segmentation fault happen, I used my C program to step through every >> function call, it turns out that ???SMIME_write_PKCS7??? seems to be the >> critical point. >> >> I???m sure I???m using the correct LD_LIBRARY_PATH environment variable >> value for every test in Linux. The platforms I tested are Linux 32bit & >> 64bit, Mac OS 10.12.1. >> > > It's a bug in OpenSSL 1.1.0. Fix is: > > https://github.com/openssl/openssl/pull/1985 Thank you very much for your fast response, we will wait for the next release to have this issue fixed. Thank you for your work making the world a better place! Harald -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SMIME signing with SHA1
On Tue, Nov 22, 2016, Harald Koch wrote: > Hello, > > I???m facing a critical situation in my application when creating a signed > SMIME message using SHA1 as message digest algorithm. In openSSL 1.0.2 (i.e. > 1.0.2h), the following command worked as expected: > > /opt/openssl-1.0.2h/bin/openssl smime -sign -in original_message -signer > cert_key.pem -md sha1 > > The message output contains a header using sha1: > > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg="sha1"; boundary="??7E9FFA1842442B7192D83A53D8D35C89" > > > With openSSL 1.1.0c, I get a segmentation fault with the same command. Using > md5 or sha256 (or even not providing the parameter ???-md???, resultig in > sha256) the command works as expected. Trying to determine where the > segmentation fault happen, I used my C program to step through every function > call, it turns out that ???SMIME_write_PKCS7??? seems to be the critical > point. > > I???m sure I???m using the correct LD_LIBRARY_PATH environment variable value > for every test in Linux. The platforms I tested are Linux 32bit & 64bit, Mac > OS 10.12.1. > It's a bug in OpenSSL 1.1.0. Fix is: https://github.com/openssl/openssl/pull/1985 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k
Yes. The build methods were kept constant at first as I tried to upgrade. Currently I am using STANDARDSDK_500 to build for CE50_ARMV4I, or at least that is the build target that was tested. We also build for many other target platforms as well, I haven't tested any of them yet. Details could probably be provided if that is of any use. We use Ant/Ivy and Jenkins in our build system. But most of the builds I performed locally without much of those details involved. Batch files get launched that set up the details of the build. Slight modifications have been made to the Perl scripts to enhance the product. For example, the standard scripts avoid the use of resource files for /CE/ builds. I not only use resource files, but improve the content of those files to indicate our build version together with the OpenSSL version tag that it is based upon. We also support FIPS so the resource file can indicate which builds are FIPS compatible and which ones are not. Ultimately I built all of the following versions: * 1.0.1g -- legacy version that has been working for years * 1.0.1t -- built without error, failed to authenticate any 802.1x protocol such as PEAP with our WPA supplicant. * 1.0.2h -- built without error even easier than 1.0.1t, failed to authenticate any 802.1x protocol such as PEAP with our WPA supplicant. * 1.0.1n -- failed the same as the others that failed * 1.0.1i -- works the same as 1.0.1g * 1.0.1l -- failed the same as the others that failed * 1.0.1k -- failed to compile until I ported a one-line fix from a later version, then built okay but failed to function correctly * 1.0.1j -- works * I tediously sliced up the differences between 1.0.1j and 1.0.1k to discover first the file and then the minimum set of changes required to reproduce failures. * Have since then ported that conditional to our 1.0.2j build. It works and that gets us to where we need to be right now. I realize that the conditional I used may be overkill. But working is good enough for the company. Even it if it not good enough for the open source community. I further pursued the differences between working and not working, but haven't been able to reproduce failure apart from a full OpenSSL build. In other words, in a small test program both methods for computing constant_time_msb worked fine. The assembly language is slightly different from one another since the new method uses a logical shift operation whereas the previous method uses an arithmetic shift operation, but never the less I was unable to reproduce a compiler error using the same version of Microsoft compiler. I've seen issues like this before where compiler errors depend upon more than just the lines in question. Unfortunately I haven't the time to dedicate to determining anything more about this issue since I have a working version that meets our needs. As indicated in the original email, the change to compiler switches neither fixed nor broke anything. I only made that change after all of the tests above, as an attempt to see if I could forgo changing source code altogether. I prefer using the same optimization switches used for Win32 builds so I left that change in even though it did not fix the compiler bug. So ultimately this email is about reporting an issue that perhaps deserves nothing more than a comment in source code, I don't know. I can keep an eye on this issue and report any further developments as they are discovered. But it will likely be a long time before we need to revisit work on OpenSSL. -Ike- John Eichenberger Intermec by Honeywell Principal Engineer: Sustaining Engineering 425.921.4507 -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jakob Bohm Sent: Monday, November 21, 2016 11:49 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k On 21/11/2016 19:52, Eichenberger, John wrote: > > I am building both OpenSSL and WPA Supplicant for use on a Windows > Mobile 6.5 platform. > > The WPA Supplicant version in use is based upon the hostap_2_0 tag > from http://w1.fi/hostap.git. > > The version of OpenSSL that we have been using until now is based upon > the OpenSSL_1_0_1g from https://github.com/openssl/openssl > > I can upgrade to OpenSSL_1_0_1j and still succeed. But when I merge > changes from OpenSSL_1_0_1k, all 802.1x authentication fails. > > I narrowed this problem down to a single line in > crypto/constant_time_locl.h. Attached is the patch set that I applied > to resolve this issue for me. > > It is a confusing issue because I can compile that same bit of code in > Visual Studio within a different trivial application and see that > although the two methods for that bit of code produce slightly > different assembly language, both should produce the same result. And > for that trivial application they do! So why this differen
[openssl-users] Code-Architecture questions while compiling OpenSSL for STM32-processors
Hi All. I wish to compile openssl libraries for a STM32-processor (which would then be linked statically with our application-framework code). Now. I believe that OpenSSL uses tonnes of "malloc"s and "free"s. But for bare-metal-systems (without any formal OSes), we generally don't have any heap-memory. So, what is the protocol for compiling OpenSSL for such systems? I am sorry, but this is the first time I would be compiling for a non-OS entity. Will be thankful for inputs. Thanks and Regards, Ajay -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SMIME signing with SHA1
Hello, I’m facing a critical situation in my application when creating a signed SMIME message using SHA1 as message digest algorithm. In openSSL 1.0.2 (i.e. 1.0.2h), the following command worked as expected: /opt/openssl-1.0.2h/bin/openssl smime -sign -in original_message -signer cert_key.pem -md sha1 The message output contains a header using sha1: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="——7E9FFA1842442B7192D83A53D8D35C89" With openSSL 1.1.0c, I get a segmentation fault with the same command. Using md5 or sha256 (or even not providing the parameter „-md“, resultig in sha256) the command works as expected. Trying to determine where the segmentation fault happen, I used my C program to step through every function call, it turns out that „SMIME_write_PKCS7“ seems to be the critical point. I’m sure I’m using the correct LD_LIBRARY_PATH environment variable value for every test in Linux. The platforms I tested are Linux 32bit & 64bit, Mac OS 10.12.1. Thank you for any help. Harald Koch -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
