Peter, et al.,
Well, perhaps it's time to deal with the encrypting vs signing problem
more directly. I've come to believe that it's probably better to have
separate keys and certificates for these two functions. The happy
accident that an RSA key-pair can be used for both functions now feels
like a distraction instead of an important feature.
I'd like to propose that we shift our abstraction towards separating
these two functions. As a first cut at defining the concept, let me
describe this as meaning that an ordinary user who currently has a
single certificate would need two certificates, one which conveys his
public key corresponding to the key he uses for signing, and one
conveying the public key one should use if you want to encrypt mail
for him.
Continuing the discussion of the concept, this can be implemented by
extending the certificate hierarchy in a simple way. The currently
defined certificate hierarchy applies to signature keys. We then
postulate that each user issues himself an encryption certificate,
which he signs with his signature key. Whether the two keys are the
same or not is the user's private business.
How far is this from the way things are set up now? First, we should
separate the two forms of certificates somehow. Perhaps it's as
simple as choosing algorithm identifiers for RSA-signature and
RSA-encryption. If this is agreeable, then we can further agree that
the current certificates can be viewed as abbreviations for a pair of
certificates, one of each kind. It's relatively simple to adjust the
existing PEM implementations (and other certificate-handling systems)
to conform with this view.
With respect to the secretary vs boss issue of access to decryption vs
access to signature, this can be handled as a local matter. If the
access to the private key is distinguished as to the purpose, then
separate access controls could be implemented. For example, if the
user is required to give a password before gaining access to the
decryption or signing functions, perhaps there could be two passwords,
one for each function.
Steve
(Disclaimer: These comments reflect my own thinking. They've been
discussed to a limited extent with the TIS/PEM group, but they do not
necessarily reflect either our policy or a commitment. At present,
TIS/PEM does not incorporate this concept.)