I have a couple of related issues with signed receipts.
The signed receipt process as outlined only considers a single type of
receipt. If fact there are more that one type of receipt. Examples of these
types would be
A message has been delved to a mail box (but not opened).
A message has been opened
The recipient acknowledges they have read (and hopefully understood)
the message
The recipient has actioned the message
Some of these receipts may mandate recipient intervention, such as
acknowledgement and actioned. You may require different receipt types from
different people, therefore I would envisage the requirement for multiple
receipt requests to be contained within the authenticated attributes of a
single message, with different users being asked for different types of
receipt.
Another requirement of the originator is that they may require some
additional information from the recipient to be returned as part of the
receipt. This additional content may be considered mandatory by the
originator. A drawback of defining the receipt as a new data type is that it
does not allow a place for this recipient originated information to be
returned with the receipt. I would therefore submit that the receipt should
therefore be an authenticated attribute of the signed data structure in the
receipt not a new content. This would allow any new content to be returned
as part of the receipt message in the content info of the signed data type
in the normal way.
To show my thoughts on these requirements may be reflected in the message,
here is my suggestion at what the receipt request should look like.
ReceiptRequest ::= SEQUENCE {
reciptType ::= BIT STRING {
delivery (0),
read (1),
acknowledgement (2),
actioned (3), }
recipientAdditionalInformation BOOLEAN DEFAULT FALSE,
encapsulatedContentType EncapsulatedContentType
OPTIONAL,
signedContentIdentifier OCTET STRING,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE (SIZE
(1..ub-receiptsTo))
OF GeneralNames OPTIONAL }
ub-receiptsTo INTEGER ::= 16
Receipt := SEQUENCE {
reciptType ::= BIT STRING {
delivery (0),
read (1),
acknowledgement (2),
actioned (3), }
encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier OCTET STRING,
originatorSignatureValue OCTET STRING }
Trevor
-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, November 05, 1997 11:48 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: ESS-00 Multiple Signed Receipts Issue
All,
The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of an originator requesting signed receipts and a
recipient returning signed receipts. There can be multiple SignerInfos
present within a SignedData object. Each SignerInfo can include
authenticatedAttributes. Therefore, a single SignedData object may
include
multiple SignerInfos each of which include a receiptRequest attribute. I
believe that this should be allowed and should be documented in the ESS.
For example, if an originator desires to send a signed message requesting
signed receipts to a set of users composed of RSA-only and DSA-only users.
The originator's software can include one SignerInfo that includes an RSA
signature value and a receiptRequest attribute. The same SignedData
object
could include another SignerInfo that includes a DSA signature value and a
receiptRequest attribute. In this example, the RSA-capable recipients
would
return an RSA signed receipt to the originator and the DSA-capable
recipients would return a DSA signed receipt to the originator.
I believe that the general processing rules in ESS should state that a
receiving agent should build a signed receipt for each SignerInfo in the
SignedData object for which it verifies the signature and which requests a
signed receipt. This may result in multiple signed receipts being
constructed and returned for a single SignedData object.
I also believe that we should add a restriction that only one
receiptRequest
attribute can be included in the authenticatedAttributes of a SignerInfo.
I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I beleive that it deserves
special attention.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================