From: "John Pettitt" <jpp(_at_)cybersource(_dot_)com>
The issue is we don't want addresses in certs because it shortens their
life, but we need some authenticated way of knowing how to reply to whoever
sent the mail and real names are not unique. The 822 headers are outside
the hash and get screwed with by all and sundry.
Perhaps what we need is reply to or originator info inside the hash but not
in the cert. That means you can be sure that the sender intended that
address to be in the mail and the sender can change address at will without
needing a new cert. (I'm having a strong urge to duck and run for cover
after saying that :-)
John
Why duck and run? Including the desired sender/recipient/cc-list names
within the envelope but not in any cert is exactly what was suggested
by Phill, Larry, and others.
From: "Anil R. Gangolli" <gangolli(_at_)StructuredArts(_dot_)com>
Binding
It is definitely important to bind the intended recipient or alleged
sender with the key. For example, consider the full binding picture when
sending encrypted mail to an intended recipient.
a. The user or application has to name the intended recipient.
b. The user and/or application must find or select the appropriate
certificate for that recipient based on the name supplied in (a).
c. The user and/or application must validate the certificate path
to a CA trusted for this purpose.
If there is any confusion in the binding at any of these three
points, then the security of the message is in doubt: you have
lost the desired strong guarantees that the resulting key
(in the recipient's certificate) is actually that of the intended
recipient.
Names in Certificates
If the name that is used in the application or user's setting does not
actually appear anywhere in the certificate, it is hard for the
application to ensure (b) above is done safely. Some other
information, either from the user or elsewhere, must be brought to
bear in order to guarantee (b).
The user always has to be involved in (a) - if I don't know whether
I want to send mail to "Anil" or to "Larry", there is nothing the
application can do to ensure safety.
So given the fact that the user has to choose a name, there is nothing
in step (b) that requires that name to be an SMTP delivery address.
The name in the cert can be "O=StructuredArts, CN=Anil R. Gangolli",
or it could be "Anil(_dot_)Gangolli(_at_)StructuredArts(_dot_)com", neither of
which
is the address to which mail should be sent in order to reach the
intended recipient. Those are just names which are meaningful to
the user, which allow both steps (a) and (b) to be performed in as
secure a manner as wetware is capable of. The missing step is:
(d) the user/application must slap a To: header containing
gangolli(_at_)StructuredArts(_dot_)com onto the already signed and sealed
S/MIME data.
Forcing the name used in step (d) to be contained in the cert is both
unnecessary and wrong.