Blake,
With all due respect, your understanding is wrong. Rich is correct that the
process to calculate the hash required to validate the signature of a
regular SignedData object (content and attributes) is different than the
process to calculate the hash required to validate the signature of a
SignedData/Receipt (content from original message and Receipt content). But
that is OK, because the SignedData/Receipt provides different security
services than a normal SignedData object, so the processing rules are
different. CMS provides the rules for validating a regular SignedData
object and ESS provide the rules for validating a SignedData/Receipt.
- John Pawling
At 02:11 PM 11/12/97 -0800, Blake Ramsdell wrote:
On Wednesday, November 12, 1997 1:32 PM, Rich Ankney
[SMTP:rankney(_at_)erols(_dot_)com] wrote:
Is the following correct?
A normal message (of type 'data') is signed, giving a SignedData
whose inner content is type 'data'.
This is correct -- the inner content is identified by the PKCS #7 data
OID, and the content is MIME data.
A receipt is signed, giving another SignedData whose inner conten
is type 'receipt'.
The inner content is identified by the ESS receipt OID, and the content
is a Receipt structure.
The thing I was objecting to is having to peel open the inner contentInfo
and determine it's type, in order to know what kind of digesting to do.
This means the digesting part of CMS applies to all contents being
signed except for receipts; the processing for receipts is described in
ESS. So handling of SignedData is now spread across two documents,
which isn't exactly optimal from a developer's point of view.
There is no change in the digesting -- you follow the steps in CMS (hash
the content part of the inner ContentInfo, then either use that to
verify the signature or verify the signature on the SignerInfo's
authenticatedAttributes, etc.)
The resulting Receipt structure may need to be handled in a special way,
but the signature provided by the enclosing SignedData should be
computed identically to any other SignedData entity.
I think we're still missing, and I don't know how to explain it better,
or if my understanding is wrong.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060