Re: V4 RSA keys??? Incongruities

[nospam-seesignature@xxxxxxxxxx]

On Fri, 3 Apr 1998, Jon Callas wrote:

> At 10:07 AM 4/3/98 -0500, nospam-seesignature@xxxxxxxxxx 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 ---