On Wed, Sep 03, 2014, Andy Schmidt wrote: > Great, thank you! > > 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" >
There is a bug in 1.0.1h and earlier related to the NID_itu_t. It is defined as the single value '0'. The encoding rules require at least two components in an OID so there is actually no way to encode just '0'. In OpenSSL 1.0.1h NID_itu_t is incorrectly encoded as as 0.0. If you check the 1.0.1h output using earlier versions it incorrectly shows the result as "itu-t" if you try 1.0.1i it shows "0.0" which is correct. The fix to this bug made NID_itu_t an invalid object which cannot legally be put in an ASN1_OBJECT: which is why it shows as invalid. A better option would be for the encoder to choke attempting to use an invalid OID but that's more complex to implement and has some side effects. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
