Here are some points to consider.
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.
The picture is only slightly different when verifying received signed
e-mail, but again what is important is that the name
understood in the application/user's setting actually corresponds
to the same entity as that in the certificate.
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).
In the SMTP/electronic mail context, RFC822 addresses are
very natural names for intended recipients, so at least
in this context it seems reasonable to include them in
certificates and have the application easily be able to
do (b) properly without any external information.
It is true that a user or some other information can
sometimes be brought in to guarantee that step (b) is
done safely. It would be nice not to have to rely on this.
It is also true that S-MIME will be useful over other transports and
with other naming schemes. I think the same principles will
come to bear there but concede that different names may be needed.
--a.
--
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:gangolli(_at_)StructuredArts(_dot_)com