v3 subkeys and signatures (was: Using second keyring may be)

[David Shaw]

On Jun 22, 2012, at 5:10 AM, Werner Koch wrote:

> Because GPG uses the (long keyid) to lookup the key in its internal
> database it is prone to these errors.  The first “sig%” is due to
> checking against the wrong key.  The double listing the Ubuntu key has a
> similar cause.
> 
> To mitigate the problem we should consider to forbid v3 subkeys.  That
> is to ignore v3 subkeys in cases where a subkey is expected.  I have not
> checked the RFC whether they are allowed, but they make no sense.
> Actually it can be considered a bug: We have a strong (SHA-1) primary
> key but allow a week (MD5) subkey.

It falls out like this - V3 keys can be a subkey on a V4 key (though a V3 can't be a primary and have subkeys of their own), but it's sort of moot since V3 keys are MUST NOT generate.  So this key is legal format-wise (though obviously manipulated).

> We might also consider to ignore all v3 keys.  After all MD5 is broken
> and such keys should not be used anymore.  One exception is to allow
> decryption using a v3 key.  Importing a v3 secret key will continue to
> work, but v3 public keys would be skipped during import.

I strongly agree with this.  It's legal to ignore V3 keys in the spec ("....MAY accept or reject them as it sees fit.") so that's fine.  I'd have it ignore V3 keys by default (while still allowing decryption), but allow users to turn full V3 use back on if they must.

David