It appears that PKCS7_sign() calls SMIME_crlf_copy() without condition.
This changes 0x0a into 0x0d, 0x0a ("\n" into "\r\n"), respecting S/MIME
rules.
Since PKCS#7 has nothing to do with S/MIME (the reverse is not true),
could this SMIME_crlf_copy() be called only when an S/MIME semantic is
needed?
--
Erwann ABALEA
-----
transrhinoscopie: capacité de voir plus loin que son nez
Le 14/06/2012 16:56, Yusheng Yang via RT a écrit :
[...]
This test attempts to sign, encode, decode, and verify messages using
the PKCS7 API. The messages are single integers. Every integer works
as expected, except for 10. When I sign 10 and verify the signature,
the output of the verify is 2573. This is because the result of the
encoding is 2573 encoded. If you run the test, you'll see that the
asn1 for 10 shows this:
54:d=5 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:0D0A000000
0D0A in little endian is 2573. Note that l = 5 instead of 4. If it
were 4, then the HEX DUMP would be 0A000000, which would be correct.
It appears that there's an extra byte of 0D that's part of the encoded
string.
