ietf-smime
[Top] [All Lists]

Re: Receipts vs. SignedData

1997-11-12 16:49:10
----------
From: Blake Ramsdell <BlakeR(_at_)deming(_dot_)com>
To: 'Rich Ankney' <rankney(_at_)erols(_dot_)com>; 'Trevor Freeman'
<trevorf(_at_)microsoft(_dot_)com>; 'Larry Layten' <larry(_at_)ljl(_dot_)com>;
'ietf-smime(_at_)imc(_dot_)org'; 'John Pawling' <jsp(_at_)jgvandyke(_dot_)com>
Subject: RE: Receipts vs. SignedData
Date: Wednesday, November 12, 1997 5:11 PM

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.)

But there is!  (from my reading of ESS, anyway).  If the inner ContentInfo
is a receipt, I hash the concatenation of the original message (not present
in this content) and the receipt, rather than just the inner content (which
is 
just the receipt).  Or am I incredibly confused??
 
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.


Regards,
Rich

<Prev in Thread] Current Thread [Next in Thread>