RE: Receipts vs. SignedData

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 a
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