At 10:07 AM 4/3/98 -0500, nospam-seesignature(_at_)ceddec(_dot_)com wrote:
In the V4 section it says "With RSA keys, the MPI bit count prefix... is
not encrypted...". So you are using old V3 style encryption. But you
will probably be using 3DES to encrypt the secret key itself, so it would
be incompatible.
Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs?
We should. All public keys should be handled the same in V4 formats. I've
changed that. Thanks for pointing it out. There are a number of places
where the original text uses "RSA" to mean "V3." It is my intent for
OpenPGP to extend V4 to all key types, even the ones that Team PGP never
implemented (such as V4 RSA keys, Elgamal signing keys, etc). I've changed
the text in that paragraph and the one after to reflect this.
An historical note about this is that in the early days of PGP, they were
very concerned about known plaintext. Consequently, a number of attempts
were made to hide the structure of PGP data and encrypted data. That is the
reason for the "hand-huffman-coding" and other facets like not encrypting
the bit count (because that was known). By the time the V4 structures were
made, there was less fear of known plaintext.
I also have a problem with Key v.s. Subkey packets. I use DH keys for El
Gamal signing. Do they belong in a key or subkey packet? What about an
RSA key used for both?
When Viacrypt wanted to make sign-only and encrypt-only keys, they added
the new PKC types for those uses. There are a (small) number of those keys
still hanging around. Personally, I think Lutz's new subpacket for marking
key usage is a better solution for the long term, and I wouldn't mind
deprecating the RSA usage types (comments?). I didn't even know they
existed until some code I had written (based upon RFC1991 and other
documents) blew up.
I believe that the "extended key structure" consists of a top-level key
which MUST be able to sign, but MAY also be able to encrypt, and a
collection of subkeys which may be of any type. The top leve key is the key
that certifications (a.k.a. key signatures) are made over, and the
top-level key also makes its own certifications which state its ownership
of the subkeys.
Now then, it is my considered opinion that it is a bad idea to use a
top-level key for encryption. My ideal world would also have the top-level
key only used for certifying other keys, and you'd have subkeys for
document signing. But that's my opinion. I don't think it's erroneous for
an implementation to let you do that, but if I were writing an
implementation, that's what I'd implement. This is why I like Lutz's key
use subpacket. It is, though, an subject on which gentlebeings may
disagree, so I don't want to mandate things in the spec.
How about something like:
A Key packet MUST be able to be used for signing and MUST be used to sign
all subkey information.
A Subkey packet MAY be used for siging.
Either MAY be used for encryption if an algorithm is defined for the type.
In effect, a two level hierarchy. I can use a very secure signing key for
the Key Packet, but use a faster, shorter, (disposable?) signing subkey.
The high security key would be used for all the UserID stuff, etc. and
define the particular online persona, with the subkeys being used as
desired.
I don't know if this was the full intent, but if it is not signing v.s.
encryption (so an RSA key would have to appear as both) this is the most
obvious next choice - primary and secondary.
It sounds like we're pretty much in agreement.
Another note: A Subkey MAY??? MAY_NOT??? appear under more than one Key.
I think that it is a Bad Idea to use a subkey in more than one extended
key. But I can think of situations where you'd want to migrate a subkey
from one extended key to another. For example, I get a new job, so I torch
all my signing keys (top-level included), and make a new extended key,
copying over all the old encryption keys. Want me to say things like this
in the security considerations section?
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 4200 Bohannon Drive
Network Associates, Inc. Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)