From: Tim Dean <t(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk>
Having no way to determine that one is the intended recipient of an
S/MIME signed message is just one of a number of obvious limitations
which have been discussed on the list, but not fully resolved in my
view.
Surely the objective for S/MIME is to provide data origin authentication,
data integrity and data confidentiality. Anything more than that - such
as who a particular message is intended for and what it means - is
application specific. S/MIME cannot understand all the semantics of all
applications. The applications themselves must ensure that their messages
are meaningful and unambiguous.
Simply saying \x91just hope that a recipient can guess that a signed
\x93thing\x94 was intended for him/her from the content\x92 is not a
satisfactory
answer, particularly when the protocol fix is so simple. To reinforce
this point, the message to which I am responding contained no indication
it was for me. The SMTP \x91To\x92 field gave a clue, but it is interesting
that if we were using S/MIME, relying on these unauthenticated fields is
(rightly) discouraged. Some implementations may not even display them.
And so a mail application which implements S/MIME can duplicate some of the
SMTP header fields within the body of the message, or the user of the mail
package can insert such fields if he/she thinks its important. But S/MIME
which is more generic than just E-mail shouldn't have to understand certain
fields which are specific to a particular application.
Cheers,
Michael Warner
Telstra Research Labs