Subject: Signed Receipts and Mail Lists

From: Graeme Lunt <[email-masked]>
Date: Tue, 24 Jun 2003 14:39:46 +0100

Hi,

We have recently encountered an issue when trying to correlate signed
receipts when using mail lists.

Issue:

When a MLA supports multiple lists using a single public/private key
pair, it appears that there is insufficient information within a signed
receipt generated by the MLA to determine to which recipient the signed
receipt relates. 

Take the case where a message is sent to two recipients, R1 and R2, and
the user makes an "all" signed receipt request.

R1 is actually a Mail List supported by an MLA using a single
public/private key pair, MLA1.

MLA1 receives the message for R1, expands the list, and sends a signed
receipt "on behalf of" R1 back to the originator.

The originator can identify the message to which the signed receipt
relates (from the signedContentIdentifier) but not the recipient as the
signature on the receipt is from MLA1. There is no way to relate this
receipt to either R1 or R2.

Possible resolution:

One way to resolve this problem would be to add an extension to the
Receipt syntax to include

   ....
   receiptFrom GeneralNames OPTIONAL
}

This field would allow the indication of whom the signed receipt was
sent from and consequently correlation with the original recipient list.
This also allows other scenarios where a third party may acknowledge
receipt for a given recipient for example an assistant reading a
managers mail. 

This functionality is comparable to that of the "IPM Intended Recipient"
field of an X.400 IPN.

Also, if considering changing the Receipt structure it may be worthwhile
adding an extension bucket at the same time (or even to support
receiptFrom).

Am I missing something?

Graeme

---

From: "Sean P. Turner" <[email-masked]>
Date: Tue, 24 Jun 2003 14:35:55 -0400

Graeme,

I'm not sure that the MLA returns a receipt on behalf of the ML members. 
 I looked through ESS again and I couldn't find anything that said if a 
message enters an MLA with a signed receipt request that it shouldn't or 
should return a receipt.    Typically (I think), originators want to 
know that the final recipient got the message not whether the MLA got it.

Then again maybe I didn't understand your scenario.

spt

---

From: Graeme Lunt <[email-masked]>
Date: Wed, 25 Jun 2003 08:40:05 +0100

Sean,
 
> I'm not sure that the MLA returns a receipt on behalf of the

OK - if an MLA should not return signed receipts then there is not a
problem with my scenario. 

> I looked through ESS again and I couldn't find anything that
> said if a  message enters an MLA with a signed receipt request that it

> shouldn't or should return a receipt.    

Is an MLA considered a "receiving agent"/"receiving
software"/"processing software" in section 2.3 of ESS? I had assumed
that it was but agree it is unclear.

> Typically (I think), originators want to know that the final recipient
got 
> the message not whether the MLA got it.

I think there are arguments for both. If an originator sends a message
to:

[email-masked]

the originator probably only wants to know that it got to the complaints
department at bigbank. The originator doesn't want to know (and bigbank
doesn't want to let the originator know) which individuals within
bigbank read the message.

> Then again maybe I didn't understand your scenario.

I don't think the originator needs to understand if the addresses they
are requesting signed receipts from are address lists or not. If an
originator sends a message to two recipients - one a mail list, one an
individual - and requests first tier signed receipts, they will never
receive a signed receipt from the mail list recipient. The user may find
this unexpected. Correlation software *may* be able to detect a mail
list recipient and handle it appropriately.

Graeme

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 27 Jun 2003 12:38:16 -0700

Sean,

I have had many discussions with people on this issue.  It is very
likely that an MLA would return a receipt to the originator of the
message either on initial receipt (I got it and distributed it) or after
a specific percentage of people on the list have returned receipts.
This is the only way to handle receipts in the case of a mailing list
whose memebership is hidden from senders.  

This being said the problem here is that you are using a single
certificate for two distinct individuals (i.e. the two different mailing
lists) and asking somebody (the sender of the message) to try and guess
which indiviual was being refered to.  In this case each MLA should have
it's own certificate (and hopefully different key pairs) in order to
allow for distinctness of identity to be known.

Graeme,

If we adopted the solution you gave, what limits me from making
arbitrary statements about who I am in this field that then need to be
independently verified by the receipt processing code?  (I.e. what if I
put the fact that I am [email-masked] in this field and sign with my
[email-masked] certificate).

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Graeme Lunt
> Sent: Wednesday, June 25, 2003 12:40 AM
> To: 'Sean P. Turner'
> Cc: 'ietf-smime'
> Subject: RE: Signed Receipts and Mail Lists
> 
> 
> 
> Sean,
>  
> OK - if an MLA should not return signed receipts then there 
> is not a problem with my scenario. 
> 
> > message enters an MLA with a signed receipt request that it
> 
> software"/"processing software" in section 2.3 of ESS? I had 
> assumed that it was but agree it is unclear.
> 
> the originator probably only wants to know that it got to the 
> complaints department at bigbank. The originator doesn't want 
> to know (and bigbank doesn't want to let the originator know) 
> which individuals within bigbank read the message.
> 
> I don't think the originator needs to understand if the 
> addresses they are requesting signed receipts from are 
> address lists or not. If an originator sends a message to two 
> recipients - one a mail list, one an individual - and 
> requests first tier signed receipts, they will never receive 
> a signed receipt from the mail list recipient. The user may 
> find this unexpected. Correlation software *may* be able to 
> detect a mail list recipient and handle it appropriately.
> 
> 
> Graeme
> 
>