Steve,
If you look at the section of 1422 that deals with display of
certificate validation data, you'll note that it requires display of
the user DN (or local alias) whenever a person (e.g. vs. a exploder)
is receiving the message (looking at the delivery side of processing).
This is absolutely critical, to avoid having the user spoofed by
unauthneticated data from the message header. This requirement
appeared in the previuous RFC (1114) and was toned down in 1422 to
allow for local aliases and to note the use of exploders. Once we
added PCAs to the system it became a natural requirement to extend the
display to include the PCA DN or local alias as well. I have no
recollection of any disagreement on this matter.
Automatically processing PEM-proytected mail, without user
intervention, and passing along the necessary ID info is not
inconsistent with the above-stated requirement. How the display is
provided is a local matter, as you observe, but the need to provide a
validated sender ID independent from the unauthenticated email header
is a central feature of the system. Personally, I am wary of the
automated processing approach, especially in systems relying on
software protection of key material. I symphatize with the problems
the TIS implementation faces in supporting a line-oriented
(vs. windowing) user interface for PEM. I', sure you worry, as do I,
about the possibility that a clever attacker could include the
necessary cursor control sequences in a non-PEM message to cause it to
be displayed in the fashion you would otherwise reserve for a
processed, PEM message.
Steve