On Wed, Sep 03, 2014 at 04:34:05PM -0700, Andy Schmidt wrote:
> The problem is that the API call sequence generates different S/MIME
> and/or PKCS7 output between 1.0.1h and 1.0.1i. The attached files are
> generated from the same API call sequence, JohnHancock.smime.h with
> 1.0.1h and JohnHancock.smime.i with 1.0.1i. The h version S/MIME does
> not have the BAD OBJECTs (or <INVALID> with my openssl executable),
> parsed with "openssl smime -in JohnHancock.smime.h -pk7out | openssl
> asn1parse | grep INVALID"
The difference I see is:
d=0 hl=4 l=.... cons: SEQUENCE
d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
d=1 hl=4 l=.... cons: cont [ 0 ]
d=2 hl=4 l=.... cons: SEQUENCE
d=3 hl=2 l= 1 prim: INTEGER :01
d=3 hl=2 l= 11 cons: SET
d=4 hl=2 l= 9 cons: SEQUENCE
d=5 hl=2 l= 5 prim: OBJECT :sha1
d=5 hl=2 l= 0 prim: NULL
-d=3 hl=2 l= 3 cons: SEQUENCE
-d=4 hl=2 l= 1 prim: OBJECT :itu-t
-d=3 hl=4 l=.... cons: cont [ 0 ]
+d=3 hl=2 l= 2 cons: SEQUENCE
+d=4 hl=2 l= 0 prim: OBJECT :BAD OBJECT
+d=3 hl=4 l=.... cons: cont [ 0 ]
The "itu-t" OID is not correctly set in the PKCS7 encoding. The
same issue shows up again later. It is not clear what the origin
of the problem might be. One possibly relevant difference is in
crypto/objects/obj_dat.h:
commit d70c0be4c1e33985a79d691786db72661fdfd057
Author: Matt Caswell <m...@openssl.org>
Date: Wed Aug 6 22:18:45 2014 +0100
make update
...
-{"ITU-T","itu-t",NID_itu_t,1,&(lvalues[4439]),0},
+{"ITU-T","itu-t",NID_itu_t,0,NULL,0},
...
That's a wild guess, it may well be unrelated.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
