[Top] [All Lists]

RE: Rethinking Receipt

1998-04-13 18:36:08
I believe if you read the RFC for the MDN, which includes how to do 
receipts you will find that a signed receipt may contain information such 
as "deleted" and "processed". So your statement that "and are sent 
automatically to the originating agent to indicate ONLY that the message 
was received and the signature was verified" not correct. Please look 

        R. Fajman, "An Extensible Message Format
        for Message Disposition Notifications",
        RFC 2298, March 1998.

These type of status codes are important to many applications and convey a 
lot more than just " received and signature verified".

See excerpt of RFC 2298 below:

   The syntax for the Disposition field is:

     disposition-field = "Disposition" ":" disposition-mode ";"
                         [ '/' disposition-modifier
                           *( "," disposition-modifier ) ]

     disposition-mode = action-mode "/" sending-mode

     action-mode = "manual-action" / "automatic-action"

     sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"

     disposition-type = "displayed"
                      / "dispatched"
                      / "processed"
                      / "deleted"
                      / "denied"
                      / "failed"

     disposition-modifier = ( "error" / "warning" )
                          / ( "superseded" / "expired" /
                              "mailbox-terminated" )
                          / disposition-modifier-extension

     disposition-modifier-extension = atom

   The disposition-mode, disposition-type and disposition-modifier may
   be spelled in any combination of upper and lower case characters.

-----Original Message-----
From:   John Pawling [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent:   Monday, April 13, 1998 5:45 PM
To:     David P. Kemp; ietf-smime(_at_)imc(_dot_)org
Subject:        Re: Rethinking Receipt


I strongly disagree with your proposal because it combines two very
different concepts into a single ASN.1 syntax.  This will be extremely
confusing to the implementors, users and everyone else involved.

Returning a signed receipt provides to the originator proof of delivery of 
message, and allows the originator to demonstrate to a third party that the
recipient was able to verify the signature of the original message.  That 
the ONLY purpose of the signed receipt.  The concept is that signed 
are generated automatically by the receiving software and are sent
automatically to the originating agent to indicate ONLY that the message 
received and the signature was verified.  The concept is that there is no
human intervention in this process.  The app should indicate to the user
that a signed receipt was sent to the requesting party on the recipient's
behalf, but that should be the only human interaction.

The proposed contentReference implies significant human interaction that 
user makes one or more decisions regarding whether or not the response is
sent and what the response means, etc.  This is a very different concept
than signed receipts and should be separated into a different ASN.1 syntax.

Please re-formulate your proposal so that it does relate to the signed
receipt concept.

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

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

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."


 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.


Dave Kemp

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