On 05-08-2010 01:10, Dr. Stephen Henson wrote:
On Wed, Aug 04, 2010, Harakiri wrote:
--- On Wed, 8/4/10, Dr. Stephen Henson<st...@openssl.org> wrote:
From: Dr. Stephen Henson<st...@openssl.org>
Solution: Disable the recipient check, when i manually
assign the private
key - just use it to decrypt the message.
If you don't supply the certificate to the cms or smime
command it doesn't
attempt to check and it should try the private key against
any possible
recipients. Ah I notice that this is undocumented...
ahh... i never knew =) this is great i will try it out later, final question
for these kind of messages - does the cms command handle all the messages that
could be handled by the smime command? What i dont want is try openssl smime
--decrypt first only to see that the recip error is thrown because the
SUbjectKeyIdentifier is used and retry again with openssl cms --decrypt
Basically is the smime command obsolete because cms does everything now?
Yes, the smime command and the PKCS7 code is retained for compatibility.
There is only one exception which is the case where a PKCS#7 structure has an
innner content type that is not data: this is an incompatibility between the
two specifications. They are rarely encountered in practice though.
Note that signatures on downloads and programs for Microsoft products
(used to be called "Authenticode") consist exactly of PKCS#7 signatures
on ASN.1 structures other than "Data". The exact ASN.1 structure
depends on the file format of the signed file and includes an identifier
for that format.
This is mainly due to the age of the Authenticode specification, but
also protects against tricking someone into creating an Authenticode
signature when they think they are signing something completely
different (such as an e-mail).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
