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. Yes. > 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) Yes. > 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 Yes. > ... > > 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 > tricks. 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! ;-) -- Marco Roeland ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
