Bo Sehlberg wrote:
>
>
> i2d_PKCS7_ENC_CONTENT seems to produce an invalid output.
I don't think it is. As I understand it that's the way the encoding
rules work. If you take a look at PKCS#7 you will see:
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm
ContentEncryptionAlgorithmIdentifier,
encryptedContent
[0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING
The crucial part here is the IMPLICIT tag. This changes the tag of the
unerlying value, so you don't actually see the OCTET STRING tag at all
for a primitive encoding.
Now why do your two examples apparently differ? This is because they
use different forms of encoding. Lets take the first case. The important
bit is this:
282 A0 NDEF: [0] {
284 04 2488: OCTET STRING
: 88 33 54 7D CA B9 8B 80 85 84 0D EB B9 90 D6
.....
What you have here is an indefinite length constructed encoding: however
the implicit tagging is hiding the tag for the surrounding indefinite
length OCTET STRING.
Now if you look at the OpenSSL version:
282 80 2488: [0]
: 62 A3 56 01 E1 FB B6 63 92 A3 62 A5 A7 E3 49 EA
Here definite length primitive encoding is used (which happens to be
DER) and you don't see any tag at all as a result.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
