Hi jkoehring: Thanks a lot for the help, (ah just noticed another reply from you on this question placed in another way, thanks). I tried that part too but did not get the expected checksum. Not that I doubt what you say, but perhaps I'm mistaken at some point. When I do the verify, the openssl smime -verify outputs the original document and optionally the certificate. I was doing the checksum not after the verification, but instead, I was just processing the multipart/signed document, and extracting the first portion between the first and second boundary. I will do it again right now and be right back.
On the other hand, don't you think the 7.1.8 paragraph of RFC4130 misleads one, by saying " MIC MUST be calculated across the entire multi-part content, including the MIME headers." It seems to me a trick to give clients to "somebody". Later, Javier jkoehring wrote: > > If I understand your question correctly, you are asking how to calculate > the MIC (SHA1 checksum) to put in an AS2 MDN. > <p> > The MIC should be calculated over exactly that data that was signed in the > original AS2 message. The data used to calculate the MIC should not > include the actual signature. Thus, the MIC should be calculated over that > data that appears between the first two boundary markers in the > multipart/signed of the original AS2 message. Note that the first boundary > marker includes the trailing CRLF and the second boundary marker includes > the leading CRLF. Thus, those CRLF sequences should not be included in the > MIC calculation. > > > javierm wrote: >> >> Can anyone help me with the procedure to calculate the message integrity >> check in this RFC? >> >> it's about calculating the sha1 checksum over a multipart message. >> >> This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt), >> chapter 7.1, paragraph 8) >> >> <div style="color:#0000ff; background:#ffffcc; font-size:8pt; border:1px >> solid red; margin:20px"> The EC Interchange and the RFC 1767 MIME EDI >> content header can >> actually be part of a multi-part MIME content-type. 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. >> </div> >> >> My problem is that i think I understood, but another software gives me a >> different checksum for the same message. >> >> <ul> >> <li>I canonicalize headers, no problem</li> >> <li>I process signature of message with openssl which provides a >> multipart file</li> >> <li>I calculate sha1 over exactly that output file</li> >> </ul> >> >> Is there something done wrong in this procedure? Whant to try some >> examples? >> This file is a multipart output from openssl >> http://www.nabble.com/file/p18034577/mictest.txt mictest.txt >> >> Ok, not directly. Because openssl produces the base64 signature, which I >> detach to then transform to binary or "DER" and I attach it back, with >> the corresponding change in Content-enconding: binary. >> >> For this file I get IpWFspJ2hKwfja5CkOPnDW2ctT8= >> The other trading partner says: Uiaz1kOChhlSb/f3SJsmJ/O/8SI= >> >> Could this be a mere misunderstanding of the RFC?, I've seen way >> different "interpretations" on the net, which I have tried but don't work >> either. >> >> Well thanks for the help >> > > -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18039358.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
