I have to admit, I am not very familiar with the openssl commands. The one question I have is exactly what are the contents of original.txt after running the commands you list? Does it contain exactly the contents of the first part of the multipart/signed?
javierm wrote: > > Thanks for the wait: > > Well, these are the steps followed > > > Encrypted body with Mime headers.- body decrypted and multipart/signed message obtained > Signature in binary, so processed with openssl pkcs7 to convert the binary signature to b64 (script in perl to extract the binary signature, process it with pkcs7 it and put it back in between the 2nd an 3rd boundary, Content-transfer-encoding changed from : binary to base64---> file produced: signed.txt > openssl smime -verify -in signed.txt -nosigs -noverify -signer who.pem -out original.txt (successful, cert found inside used in signature written to who.pem-yes the signer is right) > openssl sha1 -binary original.txt|openssl enc -a , > and... I don't get the signature that the signer claims I should get!! :confused: > > > What do you think? > Thanks > > > javierm wrote: >> >> 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". >> >> Thanks >> 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. >>> >>> 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) >>>> >>>> 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. >>>> >>>> >>>> My problem is that i think I understood, but another software gives me >>>> a different checksum for the same message. >>>> >>>> >>>> I canonicalize headers, no problem >>>> I process signature of message with openssl which provides a multipart file >>>> I calculate sha1 over exactly that output file >>>> >>>> >>>> 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-tp18034577p18062910.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
