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 turners(_at_)ieca(_dot_)com in this field and sign
with
> my jimsch(_at_)exmsft(_dot_)com 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 jimsch(_at_)exmsft(_dot_)com on behalf of
turners(_at_)ieca(_dot_)com 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 "ceo(_at_)corp(_dot_)com" which redirects
to a
personal mailbox.
Similar to a).
Graeme
> > -----Original Message-----
> > From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
> > [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] 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:
> >
> > complaints(_at_)bigbank(_dot_)co(_dot_)uk
> >
> > 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
> >
> >
>
>