ietf-smime
[Top] [All Lists]

RE: Receipts vs. SignedData

1997-11-12 10:53:26
I think this is a good reason to change the ESS specification to move
receipts to an authenticated attribute of the signed data type. Why do we
need a new data type to convey this receipt information in the first  place?
There is a signed data layer with the receipt with authenticated attributes
so lets use it. 
Trevor

-----Original Message-----
From: Rich Ankney [SMTP:rankney(_at_)erols(_dot_)com]
Sent: Tuesday, November 11, 1997 11:01 PM
To:   Blake Ramsdell; 'Larry Layten'; 'ietf-smime(_at_)imc(_dot_)org'
Subject:      Re: Receipts vs. SignedData

----------
From: Blake Ramsdell <BlakeR(_at_)deming(_dot_)com>
To: 'Rich Ankney' <rankney(_at_)erols(_dot_)com>; 'Larry Layten' 
<larry(_at_)ljl(_dot_)com>;
'ietf-smime(_at_)imc(_dot_)org'
Subject: RE: Receipts vs. SignedData
Date: Tuesday, November 11, 1997 4:46 PM

On Tuesday, November 11, 1997 12:18 PM, Rich Ankney
[SMTP:rankney(_at_)erols(_dot_)com] wrote:
Agreed; I'm just looking for a way to have common processing of
SignedData, regardless of the inner content.  If there's no secure,
clean way to do it, I can live with what's there now.  Perhaps the
OUTER content should be Receipt, instead of SignedData, where
a Receipt is then the combination of SignedData and (inner)
Receipt, processed as defined in ESS?

I may be confused here, so someone please correct me if I am wrong.

Rich, my understanding of your comments is that the signature
verification of S/MIME messages of outer content type SignedData are
handled inconsistently, depending on whether or not it encloses MIME
data (identified by the PKCS #7-defined OID "data") or a Receipt
structure (identified by the newly created "receipt" OID under the SMIME
arc).  Is this the case?  My understanding is that the SignedData
signature computation for both is exactly the same, and that the only
processing difference occurs when the inner content (either the MIME
data or the Receipt structure) is removed and processed.  That is, the
MIME data is processed through the MIME engine, and the Receipt
structure is processed through "other means" that are
receiver-dependent.

Maybe it's me that's confused, but it seems to me that Section 5.3 of
the CMS spec describes how to compute the message digest: on the
DER encoding of the content being signed (the ContentInfo).  This is
then used, if necessary, as the messageDigest attribute (if
authenticatedAttributes are used), else it is signed directly.

ESS describes a different method of computing the message digest:
it is, instead of H(inner content), computed as:
H(original-message || Receipt), where original-message is the one
we are generating the receipt for, and Receipt is the data structure
of the same name.  Only Receipt is in the actual inner ContentInfo
of the SignedData being returned to the originator.  This new method
of computing the message digest (which we use only if the inner
content is a Receipt) is what I was talking about.  

Or am I reading ESS wrong?
 
If this is not the case, then I may need some information as to why
there is a difference, since I agree -- the signature processing should
be the same.

The actual signature process is the same: sign the digest or the
authenticatedAttributes.  It's the digest computation that's different.
At a minimum, CMS needs to address this, I think. Or make the
content type of the outer message (currently SignedData), something
different (but still with SignedData syntax).  I'd prefer to always
process
the digest and signature computation the same for SignedData, regardless
of the inner content type, but that's just my personal opinion...

Blake
--

Regards,
Rich

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