Rich,
Several points:
1. The actual message may have been encrypted, and putting
the digest "in the clear" provides information on the content of
the message.
2. Verification of the receipt still requires that the recipient of
the message retain (or re-create) the message digest to verify
the signature of the receipt is valid, hence, having it in the
message isn't of any value.
I guess that item 1 could be taken care of by requiring encryption
of the return receipt if the original message was encrypted.
Larry
----------
From: Rich Ankney[SMTP:rankney(_at_)erols(_dot_)com]
Sent: Tuesday, November 11, 1997 11:36 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Receipts vs. SignedData
It appears that, when creating/verifying SignedData, one processes the
content being signed differently, depending on if it is a Receipt or not.
I.e., non-receipts are processed per the CMS spec, while receipts digest
the received message followed by the Receipt structure (the Receipt is all
that actually appears in the inner content). So the messageDigest
attribute in the Receipt case is not just a digest of the content.
Is there some other way to do this so SignedData is always processed the
same? E.g. include a digest of the original message in the Receipt
structure or as an additional authenticated attribute? (Of course these
mechanisms just prove the recipient has the message digest, not the actual
message :-)
Regards,
Rich