After congitating over all the recent negative message on this topic, I
think you guys are missing some of the point here based on interpretation of
"signer". (Tim, please feel free to slap me about if I'm misrepresenting you
ideas, but this is what I see signature purpose as being good for.)
I don't see the signature purpose as necessarily something for human
consumption, but rather an aid in automated processing by recipient
implementations. For instance, a trusted third party time stamp is clearly
something that would be processed automatically by the recipient system, and
possibly handled differently (i.e., the time stamp used to mark objects derived
from that message.) Now consider that the signingTime attribute is a somewhat
likely attribute to be included in any signature. Isn't it a bit haphazard
then to expect a receiving implementation to locate a trusted third party time
stamp signature based on the presence of signingTime? This is not an issue of
helping the receiving user know which signature is which. It is an issue of
enabling products to perform automatic actions based on commonly understood
signature semantics.
Similar examples could, no doubt, be constructed for authorizing
signatures, sensitivity labeling, and other things from Rich's list.
It seems to me that expecting the receiving implementation to GUESS the
sematics meaning of each signature based on the set of attributes used is at
its BEST a bad design that unduly restricts the usability of digital
signatures. I think Tim's idea is a useful improvement that can potentially
stimulate a many uses of S/MIME that are not commonplace today.
Chris Bonatti
IECA, Inc.
____________________
Michael Warner wrote:
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 ?just hope that a recipient can guess that a signed
?thing? was intended for him/her from the content? 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 ?To? 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