Steve,
In your long missive you said that was fair to argue that PEM
would be more general if it were modified to include the
capability of having separate keys for encryption and signature,
but that you were more bothered by the justifications given
than by the principle.
I'd like to address this point, and gently try to change your mind.
I believe that if PEM is to succeed, it must support, and not
constrain, common business practices. One of those practices,
which is increasingly common with higher levels of management,
is that a manager or executive's secretary is often given the
DUTY of reading incoming mail and deciding what is important
and who should respond. In some cases he or she may respond
in their own name, or perhaps in the name of the executive's
organization, but NOT with the signature of the executive
himself/herself (at least not normally). It must be expected that
this practice will continue, even if the incoming mail
is encrypted because it is company proprietary.
In addition to the executive/secretary problem, several correspondents
have pointed out that they are resonsible for the operation of a
help desk for software releases. When the software is in
beta test, the company may wish to keep all of the questions/
complaints and responses encrypted. In this case, a group of
people may need to have the ability to read the message, and
perhaps some can sign the reply, but committments such as
"This will be fixed in the next release" may require a manager's
signature.
In this environment it will either be necessary to share certain
cryptographic keys, or else have the incoming mail decrypted
by the UA automatically, and rely on computer security measures
to control who has access.
Because this is a PEM forum and not a computer security forum,
I would like to be able to solve this problems cryptographically.
I've tried to solve these problems with computer security for
the last 10 years, and have about given up.
You said, "This still strikes me as a terrible idea, since it presumes
person X giving up privacy, potentially to the dismay of someone
sending purportedly private mail to X."
That was certainly NOT my intent, and we wouldn't want that to
happen. That's why we need some kind of an indication as to
the intended purpose of a given certificate. Because we are not
yet assuming the availability of X.500, I would prefer some
way of indicating within the certificate itself, "Use this certificate
if you wish to communicate in private with me or any of my trusted
staff, but NOT if you want to communicate with me and me alone
about a personal and confidential matter."
If we don't have have the ability to separate encryption keys
from signature keys, then it will be necessary to add additional
caveats along the lines of "Use this certificate to communicate
with me or my staff, but be aware that anyone within that group
might have signed it -- not necessarily me."
We can certainly devise work-around methods of dealing with
this problem, especially once we have a real X.500 database
and can encode additional attributes along these lines. This
is therefore not the most pressing problem facing us.
On the other hand, if we decide to make some significant
changes to PEM for any other reason, this would be the appropriate
time to fix this problem as well.
Bob