RE: Signed Receipts and Mail Lists

[Russ Housley <[e-mail]>]

Graeme:

When we designed the MLA mechanism, we assumed that each mail list would 
have a separate key pair and certificate.  I do not think that this is an 
unreasonable assumption.  Today, Web servers that support more than one 
site have a certificate for each of the sites.

Russ

>Jim,
>
> > 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 [e-mail] in this field and sign with
> > my [e-mail] certificate).
>
>First off, having looked in more detail at 2634 it implicitly requires
>each mail list to have its own certificate. In particular, the
>EntityIdentifier, used in MLExpansionHistory, refers only to a
>certificate. So having a single certificate for an MLA supporting
>multiple lists would cause the loop detection algorithm to fail.
>
>So what I was looking at (a single certificate for a mail list agent
>supporting multiple lists) is a more fundamental change than I first
>thought.
>
>But back to your question.
>
>The basic answer is that nothing would limit you. Do you see this as a
>major issue?
>
>x400wrap has a similar case where the content being signed contains an
>"originator" field.
>
>"Receiving agents SHOULD check that the originator address in the X.400
>content matches an X.400 address in the signer's certificate, if X.400
>addresses are present in the certificate and an originator address is
>available in the content. A receiving agent SHOULD provide some explicit
>alternate processing of the message if this comparison fails, which may
>be to display a message that shows the recipient the addresses in the
>certificate or other certificate details."
>
>I think that similar wording to section 4.3 of this draft may be
>acceptable?
>
>This wording allows us to take our own action to correlate the x400
>originator to the signer in the case that they don't match (we use
>attribute certificates to do the signer to originator validation).
>
>So for your example, I may see something like:
>
>"signed receipt from [e-mail] on behalf of [e-mail] at
><time>"
>
>The receiptFrom field I proposed is primarily aimed at supporting the
>correlation of the signed receipt to the original recipient by providing
>original address the signed receipt was requested from.
>
>There are a number of reasons why I may not be able to match the
>address[es] (subjectAltName) from the certificate to one of the
>addresses I to:
>
>a) Valid aliases not in the subjectAltNames of the certificate
>
>b) Signed receipt from a recipient who received the message as a result
>of ML expansion.
>
>c) Mail redirections - e.g. sent to "[e-mail]" which redirects to a
>personal mailbox.
>Similar to a).
>
>
>Graeme
>
>
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] 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,
> > >
> > > > I'm not sure that the MLA returns a receipt on behalf of the ML
> > > > members.
> > >
> > > 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:
> > >
> > > [e-mail]
> > >
> > > 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
> > >
> > >
> >
> >