ietf-smime
[Top] [All Lists]

RE: ESS-00 Multiple Signed Receipts Issue

1997-11-13 05:43:35
John,
It is clear we have a difference of opinion here, so let me try a different
tack.

I think I am correct in summarising your position by saying that in your
opinion the cryptographic service can only tie two messages together, the
request and a single response with a fixed meaning from a recipient, all
other receipt types are in fact application messages, which have to be
correlated by non-cryptographic means. 
My position on the other hand it that there are instances where there is a
requirement to have more than a single response from a recipient, that
response can be used to convey other meaning than simply the recipient was
able to verify the originators signature. All of these other responses need
to be bound to the original request and the receipt responses correlated for
the originator so they have some idea what is going on. If the cryptographic
service has a means of binding and correlating these messages together, why
invent another mechanism? The existing technique used to bind the receipt
request to a receipt, can equally be used to bind other messages. Why cannot
the intrinsic ability of the cryptographic service to bind messages together
be used for a wider set of messages that the ones currently defined in the
draft?
I see no benefit to continue this on the list, and I suggest we continue the
discussion off-line.
Trevor

-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, November 12, 1997 1:49 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 additional feedback.  I respectfully disagree
with your points as follows:

You stated: 
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).

The delivery of a message to a mail box does not involve any cryptographic
services, so a signed receipt is inappropriate.  This requirement should
be
met by an element of the commnication protocol, not the security protocol.
For example, in the X.400 environment, the X.400 receipt (not a signed
receipt) provides this service.  The real solution is to enhance SMTP to
include a SMTP receipt (not a CMS/ESS signed receipt).


A message has been opened

Depending on your definition of "opened", the "opening" of a message does
not necessarily mean that the message signature was verified, so a signed
receipt is inappropriate.  The signed receipt must only be sent if the
recipient can verify the signature of the message.


The recipient acknowledges they have read (and hopefully understood)
the message

This is way beyond the scope of crytographic services, so a signed receipt
is inappropriate.  This requirement would be met by the recipient sending
a
message back to the originator stating "I read you message and understood
it".


 The recipient has actioned the message

Again, this is way beyond the scope of crytographic services, so a signed
receipt is inappropriate.  This requirement would be met by the recipient
sending a message back to the originator stating "I have acted upon your
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.

I disagree with your proposal that ESS should allow for multiple,
different
receipt requests  in a SignedData object, because I disagree with your
basic
philosophy to try to solve problems in the communications protocol using
security protocol elements.


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 disagree with this point because I disagree with your basic philosophy
to
try to solve problems in the communications protocol using security
protocol
elements.

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



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




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