website/bugs/monkeysphere-gen-subkey-treats-revoked-auth-subkey-as-valid.mdwn

   1 If you have a revoked authentication subkey in your keyring,
   2 monkeysphere gen-subkey thinks that I have an authentication subkey
   3 already, which I do, but it probably shouldn't care about it, since it
   4 is revoked:
   5
   6          21:30@pond> monkeysphere gen-subkey F67E2A5D1CF2D62A
   7          An authentication subkey already exists for key 'F67E2A5D1CF2D62A'.
   8          Are you sure you would like to generate another one? (y/N)
   9
  10 However: this key was revoked on 2008-04-28 by DSA key 1CF2D62A Micah Anderson <micah@riseup.net>
  11          sub  1024R/866F47D3  created: 2008-02-25  revoked: 2008-04-28  usage: A
  12
  13 I can continue to create a new authorization subkey, so its not a
  14 blocker or anything (I suppose I could also delete the revoked key
  15 from my keyring as well, although thats less than ideal).
  16
  17 It seems like the secret keyring doesn't mention that it has been
  18 revoked, so probably monkeysphere needs to be looking at gpg's
  19 computed validity from the public keyring instead of the secret
  20 keyring to be able to get the "r" flag from field 2, in addition to
  21 the "e" flag from field 12.
  22
  23 ---
  24
  25 So the problem is that there is no field 2 for secret keys.  From
  26 /usr/share/doc/gnupg/DETAILS.gz:
  27
  28       2. Field:  A letter describing the calculated trust. This is a single
  29                  letter, but be prepared that additional information may follow
  30                  in some future versions. (not used for secret keys)
  31
  32 Why would secret keys not have this field?  They have validity too,
  33 right?  This doesn't make any sense.  I verify that indeed there is no
  34 output in field 2 for secret keys.  I would say this is a bug in gpg,
  35 but it's clearly done on purpose.  Any ideas?
  36
  37 -- jrollins