I think we're in broad agreement here, though out choice of specifics
might differ.
From: Steve Kent <kent(_at_)BBN(_dot_)COM>
To: Stephen D Crocker <crocker(_at_)tis(_dot_)com>
cc: pem-dev(_at_)tis(_dot_)com
Date: Mon, 03 Jan 94 10:15:24 -0500
Subject: Re: Display of PCA policy
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.
Yes, I agree it's absolutely critical that the DN of the signer
appear, and that this be quite distinct from the (putative) sender as
determined from the unauthenticated 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.
I don't recall the discussion in any detail, but it's important for
the specs to leave plenty of room in this area.
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.
We're in complete agreement on the above.
Personally, I am wary of the automated processing approach,
especially in systems relying on software protection of key
material.
This is part of the larger question of how trustworthy is a
particular computing system. One might make the following argument:
Strong protection of keys is not much help if the rest of the
system is weak. If the rest of the system is strong enough,
then it should be good enough to protect keys too.
However, both your statement and mine are inherently subjective. I'd
be a lot more comfortable with something more specific and concrete.
I symphatize with the problems the TIS implementation faces in
supporting a line-oriented (vs. windowing) user interface for PEM.
Although there are various implementation issues with TIS/PEM, I'm not
sure the lack of a windowing environment is overly important.
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.
Cursor control sequences are the tip of a much bigger iceberg
involving active mail. This is partly related to PEM, and partly
related to the more general problem of "safe" mail.
Steve