Steve
Many thanks for this; I should have persevered with delving into the relevant RFC’s and checking the ASN.1 was valid and well formed. So I’m assuming Outlook is “tolerant” (to some extent) of ‘badly formed’ ASN.1 whereas openssl adheres to the standards (which is how it should be). One other observation (I’m much more familiar with BER than DER, having had the pleasure and honour of working alongside Professors Chadwick [Mr X500] and Larmouth [Mr ASN1] in the 1980’s); openssl uses ‘unspecified length strings’ in the encoding, whereas the (errant) ASN.1 I posted uses ‘absolute length strings’, the question is (having not read the ISO standard for DER .. too expensive to buy) is this the only variable thing in the DER encoding? … because I thought DER, unlike BER, did a 1:1 encoding so you could use the diff command (et al) to compare two independent encodings of the same thing. Just wondering, enquiring minds etc ;-)
Once again many thanks.
Peter
"Dr. Stephen Henson" <[EMAIL PROTECTED]> wrote:
On Sun, Mar 06, 2005, Peter Cope wrote:
>
> I'm using openssl 0.9.7e on Unix (The example output below is from Windows
> version of openssl [a 0.9.7X derived binary version from stunnel.org], but
> is consistent with AIX version as regards the failure. I will repeat this
> tomorrow when I have access to the Unix box if that helps).
>
> openssl pkcs7 -inform DER -in file.der
>
> This outputs a PEM file (topped and tailed with the '------ xxxx PKCS7
> -----' line)
>
> *But*
>
> openssl smime -decrypt -in file.der -inform DER -recip cert.pem -inkey
> private.pem
>
> gives
>
> Error decrypting PKCS#7 structure
> 172:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too
> long:crypto/asn1/asn1_lib.c:140:
> 172:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object
> header:crypto/asn1/tasn_dec.c:935:
> 172:error:0D06C03A:asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE:nested asn1
> error:crypto/asn1/tasn_dec.c:628:
> 172:error:0D08606D:asn1 encoding routines:ASN1_TYPE_get_int_octetstring:data
> is wrong:crypto/asn1/evp_asn1.c:179:
> 172:error:21072077:PKCS7 routines:PKCS7_decrypt:decrypt
> error:crypto/pkcs7/pk7_smime.c:414:
>
> (If the file.der originated from one of our own computers, using the same
> public key to encrypt then the above decrypt line works).
>
> [If I redirect the output from the pkcs7 line into say fred.pem, and try
> decrypting this (using -in fred.pem -inform PEM ) naturally get the same
> error.]
>
> It may be our client is doing something wrong, but as with any
> interoperability testing I always assume the fault is my end until I have
> proof it isn't.
>
Ah, that explains it. Going back to your output from asn1parse:
355:d=5 hl=2 l= 8 prim: OBJECT :rc2-cbc
365:d=5 hl=2 l= 3 cons: SEQUENCE
367:d=6 hl=2 l= 1 prim: INTEGER :3A
what this should be is an AlgorithmIdentifier structure. The parameter field
(second and third lines) should be:
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
as you can see the 'iv' parameter is missing.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
