Dave,
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 a
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 is
the ONLY purpose of the signed receipt. The concept is that signed receipts
are generated automatically by the receiving software and are sent
automatically to the originating agent to indicate ONLY that the message was
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 the
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.
www.jgvandyke.com
================================
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