Thanks Marco:
Sorry about the delay, but today all got very well cleared and I will
describe the solution (which is not very complex by the way, but rather
easy)
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 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
My mistake in not being able to match MICs in previous example "This is a
test for checksums or messagedigests" was due to having saved such text in a
file with Unix end of line instead of DOS end of line. After saving file
with \r\n the MIC produced by command sha1sum filename.txt matched exactly
the "messageDigest" reported by the ASN1PARSE one obtains from the
"application/x-pkcs7-signature;" multipart section of the signed message,
confirming the instructions given in RFC-4130, DO WORK!.
All previous steps are simple, but what complicates things are some packages
out there which produce signed documents where the edi object's MIC doesn't
match with the messageDigest in the signature. Why? Perhaps to make them
seem more interesting, because the truth is simple. Have any text with or
without Mime headers, save it with DOS <EOL>, sha1sum it and that's
the MIC. Then sign the file, read the asn1 structure from the signature
portion, find the messageDigest: voilá, MIC calculated and messageDigest are
the same. Try to do this with commercial "interesting" packages and this
just doesn't work.
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.
Thanks for the time, thanks for reading, and thanks for the hints.
Marco Roeland wrote:
>
> The way you should calculate the message digest (using SHA1) is
> complicated because RFC 4130 specifies that the message digest (the
> checksum) has to be calculated not just over your textfile but it should
> also include the MIME headers of the attachment.
>
> Have a look at appendix A: Message Examples in RFC 4130 to see examples.
> In your testcase we would get as inner MIME attachment something like
> this:
>
> --boundary-of-whole-multipart-message
> Content-Type: plain/text
>
> "This is a test for checksums or messagedigests"
> --boundary-of-whole-multipart-message
> Content-Type: application/pkcs7-signature
>
> [omitted binary pkcs7 signature data]
> --boundary-of-whole-multipart-message
>
> The message digest in the signature is calculated starting from and
> including the 'C' of "Content-Type: plain/text" and includes all
> bytes until the boundary of the next attachment (the "\r\n" before
> "--boundary-of-whole-multipart-message" is part of that boundary so is
> not included in the checksum. In this case the last quote character of
> your testmessage is the last byte. If you add these MIME headers to your
> text file you should get the same MIC. Note also that the exact form
> of the line endings is significant. With "\n" line endings you get a
> different MIC than with "\r\n" line endings. Officially (according to
> RFC 4130) you should always "normalize" the line endings of the MIME
> headers to "\r\n" but in practice everyone always uses the exact form
> in which it was sent; this corresponds to the "--binary" option of the
> smime(3) utility.
>
> So summarizing: the way you calculated the MDN is correct, you just
> calculated if over too few bytes.
> --
> Marco Roeland
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
>
>
--
View this message in context:
http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18841022.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
