At 06:57 AM 7/20/98 -0400, dontspam-tzeruch(_at_)ceddec(_dot_)com wrote:
And doesn't the new way of computing KeyIDs hash the algorithm ID number
in with the key material? Then the same ElGamal key with two different
AlgIDs would have two different KeyIDs.
So if you mix and match, you will create the same problem with V3 v.s. V4
RSA keys, or that same keys with different dates will have different IDs.
A possible solution is to use the same Elgamal key material in two separate
keys -- an encrypt-only key and an encrypt+sign key. While this adds a bit
of bloat, it will work correctly. As Tom noted above, the two keys will
have different fingerprints.
One of the issues to consider in an implementation is what to permit a key
to do. It is a good idea, in general, to use a given key for encryption or
signing, but not both. I can think of instances where the general case can
be noted, and then we go on to do both, but these are for special-purpose,
embedded systems. A general-purpose system should separate usages, to my mind.
An encrypt+sign Elgamal key *can* be used for both, but that doesn't mean
that it *should* be used for both. Similarly, an RSA key can be used for
both, but it makes sense for an OpenPGP system that wants to use RSA keys
to have a top-level RSA key used only for signing, and an RSA subkey used
only for encryption. I'll even go so far as to opine that an OpenPGP system
ought to use the "key flags" subpacket on all RSA or Elgmal E+S keys to
explicitly state the owner's policy.
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 3965 Freedom Circle
Network Associates, Inc. Santa Clara, CA 95054
(408) 346-5860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)