ietf-smime
[Top] [All Lists]

Re: Rethinking Receipt

1998-04-14 12:17:20
Dave:

Trevor Freeman at Microsoft expressed interest in the use of receipts to
manage work flow.  This seems synergistic with your proposal.

This idea needs some additional work.  I suggest that we proceed with the
receipt as defined and look at siged attributes that can be included in the
receipt SignerInfo to implement enhacements.  Rik Drummond's requirements
can be addressed in the same document.  An additioal document that exteds
reciept capabilities seems like a reasonable approach.

Russ


At 05:53 PM 4/13/98 -0400, David P. Kemp wrote:
Folks,

ESS Section 2 discusses the operation of ReceiptRequests and Receipts:

 2.1: "The request is indicated by adding a receiptRequest attribute
 to the signedAttributes field of the SignerInfo object for which the
 receipt is requested."

and

 2.8: "Receipts are represented using a new content type, Receipt."

 Receipt ::= SEQUENCE {
     version Version,
     contentType ContentType,
     signedContentIdentifier ContentIdentifier,
     originatorSignatureValue OCTET STRING }


A colleague has proposed that the receipt structure would be much more
useful if it were generalized and represented by an attribute instead
of by a unique content type.  The attribute could represent the
existing security receipt, or it could be used to securely link an
ordinary reply to the message it refers to.  This is such an insightful
and elegant idea that I wish I had thought of it first!  Thanks, C.A.!

I propose that ESS replace the Receipt structure and id-ct-receipt with
a new signatureBinding attribute:

 id-aa-signatureBinding OBJECT IDENTIFIER ::= { tbd }

 SignatureBinding ::= SEQUENCE {
     contentType ContentType,
     signedContentIdentifier ContentIdentifier,
     originatorSignatureValue OCTET STRING,
     bindingPurpose BindingPurpose }

 BindingPurpose ::= INTEGER {
     receipt          (0),
     contentReference (1) }


For Receipts, the bindingPurpose identifier would have the value
"receipt", and the encapContentInfo would be treated as in the
degenerate signed data case: eContentType is id-data, and eContent
is omitted.

For normal message replies, bindingPurpose would have the value
contentReference, and encapContentInfo would be the reply message.

In low-bandwidth or large-data applications, it may be useful to have
messages or attachments pre-signed and cached at both the sender's and
recipient's locations.  A small message could then use the
signatureBinding attribute to refer to one of the cached signed
contents.  Additional bindingPurpose codes, such as
signatureValidation, could be defined if needed.

Comments?

Dave Kemp



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