This is a discussion on Re: RFC 4130 checksum in SHA1 - Openssl ; On Tuesday August 5th 2008 at 15:52 javierm wrote: [calculation of MIC (Message Integrity Checksum RFC4130) with OpenSSL] > ... > > The canonicalization (what you call normalization) has to be performed also > on the message, not only the ...
On Tuesday August 5th 2008 at 15:52 javierm wrote:
[calculation of MIC (Message Integrity Checksum RFC4130) with OpenSSL]
> The canonicalization (what you call normalization) has to be performed also
> on the message, not only the headers. I tested this with a message with Unix
> (\n) <EOL> and with DOS (\r\n) <EOL> (end of line).
The MIC calculation is over the MIME headers and the _exact_ bytes of
the contents. The line endings shouldn't be changed but simply be
exactly preserved. You can also send and receive binary attachments.
So yes a message with DOS line endings and the same with Unix line
endings will have different MIC's. That is how it is meant to be. You
use the MIME headers and the MIME body of the message exactly as they
were received (or are going to be sent) to calculate the message digest.
First saving the contents separately is almost never going to work.
> The RFC 4130 section 7.3.1
> For any signed messages, the MIC to be returned is calculated
> on the RFC1767/RFC3023 MIME header and content.
> The RFC1767 is about the EDI objects so IT IS NOT REFERING to the headers of
> the multipart/signed, but those headers in the mime object (the original
> data being signed itself)
> Further up in section 7.1:
> When the EDI Interchange is part of a multi-part MIME content-type, the
> MIC MUST
> be calculated across the entire multi-part content, including the
> MIME headers.
> So "entire multipart" here is refering to the multipart forming the specific
> EDI object, not the multipart/signed
> So never feel tempted to go and pay 50,000 dlls to get certified and then
> learn which trick they use to make MIC (calculated with sha1sum) and
> messageDigest (out of the signeture's asn1 structure) to match. But
> whatever it is, it is just a trick (a trick which transforms the EDI object
> you see in the multipart/signed pair into the original EDI object which was
> actually signed). Instead get the true MIC from the asn1 structure in the
> signature (labeled messageDigest) and fool the business partner with
> "purchased certified package" just giving it **THAT** messageDigest. Try to
> sha1sum the -supposed, kneaded, tampered!!- original data, and you will
> waste your time. You will be able to do this ONLY with YOUR OWN DATA, THE
> DATA YOU YOURSELF SIGN, or the data your friends sign honestly without
I wholeheartedly agree with your sentiments in general here but really
the calculation of the MIC is not a trick (just complicated) and can be
done, with a little work, with OpenSSL. That is what counts on this
mailing list! ;-)
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org