I was hoping that this issue was going to disappear if I ignored it. I
feel that the problem listed, while potentially interesting, is not one
that can be solved via this type of mechanism.
The problem: I get a message, signed, and I forward it to you signed
and then possibly encrypted. You believe that since it was encrypted to
you that nobody else could have sent it but the signer.
Response: 1) A better answer is to put names in e-mail. 2) Am I
suppose to start doing this for all signed mail. 3) How do I convince a
large company like Microsoft that this is even an interesting problem
for them to "fix" in their mail. 4) This does not fix information leaks
in anyway. (A far more interesting problem in my estimation.)
Why this does not work: I don't know how to begin to tell Microsoft how
to write this code. The simple case is, if my mail box name is not on
the To/CC line then pop up a warning message. But this is not an easy
thing to say and program in.
1. When I was working at Microsoft, people sent me mail at the address
"jimsch(_at_)microsoft(_dot_)com", my mailbox name was
"jimsch(_at_)exhange(_dot_)microsoft(_dot_)com". There is no way to determine
are or are not the same address. While in this case they were they
could just have easily been different addresses.
2. Today, the email address that I give people is
but this is not the mail box address that I use. This address forwards
mail to a second address where I down-load my mail from. Now either the
message is always going to show up for me, or I have a configuration
issue to explain to users (and to write UI for).
3. If I receive e-mail because I am on a mailing list (such as this
mailing list), either I get the message for all mail to that list, or I
have a configureation issue to explain to users (and to write UI for).
This becomes even more fun if you look at nested mailing lists. This
mailing list address could be contained on one or more other ietf
mailling lists thus I get mail indirectly and infrequently from some
other entity mailing list that I do not know that I am on.
4. BCC addressing causes massive problems. Either the message always
comes up, I lose the concept of BCC because the address is included, or
a separate signature operation must be included for every BCC
recipeient. (Does the BCC signature still have the list of all non-BCC
recipients?). The process of generating addition signature operations
is not acceptable in my estimation, and would likely generate lots of
interesting problems with signed receipts.
5. What are the correct processing rules to deal with the following
- Nested signatures: Does this element in an outer signature remove the
requirement for it to be checked on an inner signature? Does it add or
change the behavior in some way?
- Parallel signature: What does this mean for two different
side-by-side signatures, possible with different recipient lists? If I
am on either list I don't need to display this warning?
- Nested Messages: What happens if I bodily encapsulate an RFC822
message and forward it to you. Do you check for the encapsulating but
not the embedded message? Do you check the embedded message for the
from address of the encapsulating message?
I think that this is an interesting accademic problem, until I see a
real world need for a solution I think it should be ignored.
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Housley,
Sent: Thursday, October 25, 2001 7:05 AM
Subject: sender-auth and ira
Two I-Ds were posted, and I have not seen a single comment on
them. I hope
this message starts a dialogue.
The two I-Ds are:
The first one describes a problem, and the second one defines
for this problem. I would expect the first one to be published an
Informational RFC and the second to be published as a
Standards Track RFC.