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

[Werner Koch]

On Fri, 22 Jun 2012 05:57, dkg at fifthhorseman.net said:

> colliding at how many trailing bits?  what happens if you use
> "--keyid-format long"?

The problem is that the colliding key is a v3 key (MD5 fingerprint).  It
is easy to create key id collissions for such keys; that is the reason
that back in the time of PGP 2 folks were used to compare the creation
date and key size.

If we list 0BFB847F3F272F5 we see a couple of irregularities:

  pub   1024R/0BC39F3FB1C08810 2012-06-14
        Key fingerprint = C42E F0DA 1A9C 27FA 5032  D7CB 0BC3 9F3F B1C0 8810
  uid                          kkkkkkk5 <k at k>
  sig!3        0BC39F3FB1C08810 2012-06-14  kkkkkkk5 <k at k>
  sig%         0BFB847F3F272F5B 2012-06-14  [Time conflict] 
  sig!         0BFB847F3F272F5B 2012-06-14  kkkkkkk5 <k at k>
  sub   1024R/C3A7416F0354AE88 2012-06-14
        Key fingerprint = 2F55 379F 8AB0 E8F1 D2BB  7EAF C3A7 416F 0354 AE88
  sig!         0BC39F3FB1C08810 2012-06-14  kkkkkkk5 <k at k>
  sub   2179R/0BFB847F3F272F5B 2012-06-14
        Key fingerprint = 7F C0 FE A6 A0 11 78 5A  06 7A CA CE A4 D7 12 80
[Note: a v3 key with a uncommon key size!]
  sig!         0BC39F3FB1C08810 2012-06-14  kkkkkkk5 <k at k>
  
  pub   4096R/0BFB847F3F272F5B 2007-11-09
        Key fingerprint = 153F 1C9E F139 5FBF 0035  2E8D 0BFB 847F 3F27 2F5B
  uid                          Ubuntu Archive Master Signing Key <ftpma[...]
  sig!3        0BFB847F3F272F5B 2007-11-09  kkkkkkk5 <k at k>
  
  pub   4096R/0BFB847F3F272F5B 2007-11-09
        Key fingerprint = 153F 1C9E F139 5FBF 0035  2E8D 0BFB 847F 3F27 2F5B
  uid                          Ubuntu Archive Master Signing Key <ftpma[...]
  sig!3        0BFB847F3F272F5B 2007-11-09  kkkkkkk5 <k at k>
  
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.

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.

A complete solution to this problem would be a v5 signature packet
format to put the entire fingerprint into the signature packet.  However
this breaks backward compatibility and thus will take a few years before
those signatures become mainstream.  

If we expect v4 long key id collisions to occur more often in the
future, we should implement a workaround.  For example we could store
the fingerprint for a signature packet in the meta data after we
successfully verified a signature the first time.  Key lookups would
then use the fingerprint if available in the signature packet meta
data.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.