On Aug 07, 2008; 02:18am, Marco Roeland wrote: Marco Roeland wrote: > > > [ RFC 4130 calculating MIC, mostly offtopic for OpenSSL ] > >
It is trivial that a checksum on same data produce the same result, that's by definition right with a very small probability to find two sets of data which give the same checksum. So that is not to discussion. Your answers on stating that RFC's are not followed or that not all is said on RFC's, confirm my first statement, that there are things done beyond the RFC. Tricks, Pre-Process, Procedure, Convention or anything done either due to Incompetence, Malice or "Tech Conventions", hey!, that *is* off topic, and it's not my point, but that just confirms the fact that there is a Pre-Process. Ok, not magic, not trick but something certainly *not* in RFC as you correctly acknowledge. This is graphically the signed document: Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="----=_Part_271718_798961567.1217934040548" ------=_Part_271718_798961567.1217934040548 original document ------=_Part_271718_798961567.1217934040548 signature ------=_Part_271718_798961567.1217934040548-- My point is that you (anyone interested in this RFC 4130) take the "original document" above and sign it. a) and if it is YOUR or MY document or any other document actually signed based on a -binary process, we get same signature and same messageDigest or MIC shown in "signature" above. 1.- Yes sign it with -binary flag. 2.- Using OpenSSL routines like shell openssl smime -sign -binary b) In case of an IBM solution I've worked with, you will have hard time kneading the "original document" to make it good to be signed and produce same MIC shown in the signature below. That kneading, -call it Tricks, professional secret, incompetence, malice- not found in the RFC is not just within the \r\n set of solutions. There are other pre-process procedures, so far not said, because they are in fact OFF TOPIC. Not important to be discused. But I have tested that signing -binary the "original document", doesn't produce the signature (in the example above). I just suggest within the OpenSSL topic, to use the asn1parse to find the messageDigest record and read that value. That's the MIC that all trading partners wish to receive in the MDN. I suggest to not get so much involved in the pre-process of the original data and if someone does it, just don't feel so bad if the MIC found doesn't match with the MIC in the signature. Just as Marco says and by definition of a checksum: "Calculating an MIC is basically just feeding a bunch of bytes to some OpenSSL routine, and always results in the exact same answer". By consequence if the answer is not the expected answer, then the original data is not the original data on which the MIC found in signature was calculated. What transformations are done from the original data seen on "original document" to the "thing actually signed", understood that's off topic. For that reason, and because they are not merely \r\n transformations, please just use OpenSSL asn1parse to find the messageDigest stored in signature. Greetings Javier -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p20060192.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]
