Re: Receipts vs. SignedData

Rich,

I agree with you that the ESS Receipt strategy should remain as is and that
the CMS spec should be clarified to state that the message-digesting process
that it describes only applies to the SignedData content type.

- John Pawling


At 03:29 PM 11/12/97 -0500, Rich Ankney wrote:

I do think that, if the Receipt mechanism remains as is, we need to fix
the relevant portions of CMS to indicate that the message-digesting
process is dependent upon the type of content being signed.  The
current text works for all types except receipts, which the text in ESS
handles.  This may not be such a bad thing, as we may come up with similar
kinds of constructs that include data in the signature which is not present
in the contentInfo.

Regards,
Rich

----------

From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: Trevor Freeman <trevorf(_at_)microsoft(_dot_)com>; 'Rich Ankney'

<rankney(_at_)erols(_dot_)com>; Blake Ramsdell <BlakeR(_at_)deming(_dot_)com>; 
'Larry Layten'
<larry(_at_)ljl(_dot_)com>; 'ietf-smime(_at_)imc(_dot_)org'

Subject: RE: Receipts vs. SignedData
Date: Wednesday, November 12, 1997 2:55 PM

Trevor,

I respectfully disagree with your proposal to change the ESS

specification

to move Receipt to an authenticated attribute of the signed data type.

If

your proposal was adopted, then the content would be completely absent

from

the SignedData object including the Receipt attribute.  The ContentInfo
field of SignedData is not optional, so your proposal implies that a new

OID

would need to be defined for use in the ContentInfo ContentType

indicating

that the Content ANY field is absent. In fact, your proposal is less
efficient than the current ESS strategy, because in the attribute case

you

would have to include two OIDs (one which identifies the Receipt

attribute

and another in the contentInfo indicating that the contnet is absent)
whereas the current ESS strategy requires only one OID (in the

contentInfo

indicating that a Receipt is encpasulated in the ContentInfo).

To reply to the other comments in the message trail.  Yes, the

ESS-specified

processing for a SignedData/Receipt is different than for a regular
SignedData object because different security services are provided.  The
SignedData ContentInfo OID will indicate that the SignedData encapsulates

Receipt content, so it will be straightforward for an Application to
determine when a SignedData includes a Receipt content and to take the
appropriate actions.

In summary, I believe that the ESS Receipt strategy should not be changed
(except to add clarifying text stating that multiple, identical
ReceiptRequest attributes can be present in a SignedData object as

discussed

in previous e-mail messages).

================================
John Pawling   
jsp(_at_)jgvandyke(_dot_)com                             
J.G. Van Dyke & Associates, Inc.           
================================


At 07:20 AM 11/12/97 -0800, Trevor Freeman wrote:

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