[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-cryptoapi
Subject:    Hash mismatch on OL & OE multipart/signed messages - Part I
From:       Onsite Technologies <onsite () EROLS ! COM>
Date:       1999-08-23 14:07:23
[Download RAW message or body]


Hi CAPI Subscribers,

This message is primarily S/MIME related but I can use any help I can get.

I am writing a simple S/MIME client to decode signed/encrypt
messages.  I am using CDO 2.0 to decode the MIME parts and CAPI 2.0 to
decrypt and authenticate.

In a multipart/signed message, I found the "messageDigest" in the signature
block does not match the hash of the first part produced by OL/OE and
decoded by CDO.   However, the hash does match in the simple case where the
first bodypart is type text/plain. Other cases such as multipart/mixed
result in mismatch of hash and messageDigest.

Experiments shown that the hash produced by CAPI 2.0 is correct.
Experiments shown that CDO "massages" the MIME bodyparts returned
by "GetStream" call, thus resulting in messageDigest verification failure.
Experiments also shown that even after removing CDO 2.0 from the equation,
we can't seem to reproduce the hash from the first bodypart (as from OL,
OE) to match the messageDigest.  On the other hand, we have no problem
hashing messages from Netscape Messenger.

So the question is how does OL/OE produce the first MIME entity in a
Multipart/signed MIME entity that seems to conform to standard (assumming
other clients actually verifies the hash, are they?) but we don't seem to
be able to verify the hash?

Thanks in advance,

-JimmyT-

Due to size restriction, I will include the two test messages next.

----------------------------------------------------------------
Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

[prev in list] [next in list] [prev in thread] [next in thread]