On Fri, 3 Apr 1998, Jon Callas wrote:
At 10:07 AM 4/3/98 -0500, nospam-seesignature(_at_)ceddec(_dot_)com wrote:
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.
And nuke the checksum on unencrypted keys (i.e. make the routines
identical).
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.
It would be much cleaner to have type == 1 instead of type == 1 || type ==
2 all over the place.
The only counter I would have is DH keys with generators of 2 which aren't
appropriate for El Gamal signatures. I generate DH keys not subceptible
to the known attacks against El Gamal signatures (assuming I understood
the paper right - and I think a few people are reviewing what I did to see
if it is sufficient). If you have an old DH key, it can simply not be
used if the signature would be weak (I do this too).
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.
Agreed. It helps to have one central key per identity.
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.
This is good. I might want to use the top key for internal personal
encryption, e.g. local files or something. I would leave the model to by
default be PS(SE...,SS...) especially so that the PS would be used so that
the keyservers could easily manage things. (prior Acronyms expand to
Primary/Secondary Sign/Encrypt). You could override things for special
usages.
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?
Yes, red lights should flash if you find the same subkey under two
non-revoked primary keys (and then should consult a keyserver). I would
say SHOULD NOT with the note that the implementation should complain, but
might want to complete the operation, since I might get your new keys
before I can confirm your old primary key is invalid
--- reply to tzeruch - at - ceddec - dot - com ---