Rethinking Receipt

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