ietf-smime
[Top] [All Lists]

RE: ESS-00 Multiple Signed Receipts Issue

1997-11-12 02:48:45
Hi Jon,
The point is that these other types of receipt also have to be
cryptographically bound to the receipt request, as such they form part of
the cryptographic security services. I therefore do not agree with you
interpretation that these other types of receipt are outside a cryptographic
security service or the ESS. There seem two way to progress this, 
        either the receipt type is enhanced to include the capability to
define other types of receipt 
        or, even at this early stage of the standard, we start defining the
addition of an extended receipt type request which would include the receipt
type attribute along with all the other attributes included in the current
definition.
I know which option looks the ugliest.
I also see no justification for making the receipt a new data type. It can
just as easy be carried as an authenticated attribute. All it is a piece of
signed data.
Trevor
-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent: Friday, November 07, 1997 4:07 PM
To:   Trevor Freeman
Cc:   ietf-smime(_at_)imc(_dot_)org
Subject:      RE: ESS-00 Multiple Signed Receipts Issue

Trevor,

Thank you very much for your feedback.  The CMS and ESS specifications
specify cryptographic security services, so the CMS/ESS signed receipt
should only provide cryptographic security services.  The purpose of the
CMS/ESS signed receipt is to prove to the originator that the recipient
was
able to verify the signature of the original message. This is the only
purpose for the ESS/CMS signed receipt that is within the scope of the CMS
and ESS specifications.  The other types of receipts that you list are
outside the scope of CMS and ESS, so they should be documented in separate
specifications that are not security-specific specifications.    

A CMS/ESS signed receipt is constructed by encapsulating an ESS Receipt
object within a CMS SignedData object.  The Receipt signature value is
included in the SignerInfo included in the SignedData object which
encapsulates the Receipt object.  The SignerInfo includes
autheticatedAttributes and unAuthenticatedAttributes.  Therefore, a
CMS/ESS
signed receipt can include any of the attributes listed in ESS (and some
from PKCS #9) or it could include privately defined attributes.  This
provides a lot of flexibility for the recipient to provide information
back
to the originator of the original message.

In my opinion, there is an open issue regarding whether or not all
receiptRequests included in a SignedData object MUST be identical.  I can
think of some bizarre scenarios in which different signers may wish to
require that signed receipts be sent to specific
entities, etc.  However, stating "All SignerInfos MUST contain the same
receiptRequest attribute." would simplify processing.  I could go either
way.

In summary, I believe that we should not change the signed receipt
syntaxes
and text included in ESS (other than adding clarifying text regarding
multiple receiptRequests included in a signedData object). 

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



At 07:25 AM 11/7/97 -0800, Trevor Freeman wrote:
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.           
================================