Some commands lead to bad signature

If I attempt to track a user via the website I get the following error:

```
Error: failed to post to the server: bad signature: Can't find a key for 471fdacff982d4b0: We don't have a key for the requested PGP ops (flags = 2)
```

Provisioning a new device via the CLI using GPG also leads to a similar error _if_ I tell Keybase to export the secret.

```
~ ●» keybase login «
How would you like to sign this install of Keybase?

(1) Use an existing device
(2) Use a paper key
(3) Use my Keybase passphrase
(4) Use GPG
Choose a signing option: 4
In order to authorize this installation, keybase needs to sign this installation
with your GPG secret key.

You have two options.

(1) Keybase can use GPG commands to sign the installation.

(2) Keybase can export your secret key from GPG and save it to keybase's local encrypted
keyring. This way, it can be used in 'keybase pgp sign' and 'keybase pgp decrypt'
going forward.
Which do you prefer?: 2
# Algo Key Id Created UserId
= ==== ====== ======= ======
1 R 4A00DB3D202D5E3C 2012-09-21 Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen
2 R 96142F938748D32B 2012-02-01 Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen
Choose a key: 1
Enter a public name for this device: CiscoLaptop
▶ ERROR bad signature: Can't find a key for 471fdacff982d4b0: We don't have a key for the requested PGP ops (flags = 2) (error 1002)
```

However, if I use GPG commands it works fine:

```
~ ●» keybase login «
How would you like to sign this install of Keybase?

(1) Use an existing device
(2) Use a paper key
(3) Use my Keybase passphrase
(4) Use GPG
Choose a signing option: 4
In order to authorize this installation, keybase needs to sign this installation
with your GPG secret key.

You have two options.

(1) Keybase can use GPG commands to sign the installation.

(2) Keybase can export your secret key from GPG and save it to keybase's local encrypted
keyring. This way, it can be used in 'keybase pgp sign' and 'keybase pgp decrypt'
going forward.
Which do you prefer?: 1
# Algo Key Id Created UserId
= ==== ====== ======= ======
1 R 4A00DB3D202D5E3C 2012-09-21 Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen
2 R 96142F938748D32B 2012-02-01 Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen , Brian Hartvigsen
Choose a key: 1
Enter a public name for this device: CiscoLaptop

You need a passphrase to unlock the secret key for
user: "Brian Hartvigsen "
4096-bit RSA key, ID 81255BEB, created 2015-10-03 (main key ID 202D5E3C)

✔ Success! You provisioned your device CiscoLaptop.

You are logged in as tresni
- type `keybase help` for more info.
~ ●»
```

`keybase status` does show a weird expiration date on the root public key:

```
PGP Fingerprint: C04E B13D 266B 3C2F 56CB 8880 4A00 DB3D 202D 5E3C
PGP Identities:
Brian Hartvigsen
Brian Hartvigsen
Brian Hartvigsen
Brian Hartvigsen
Brian Hartvigsen
Brian Hartvigsen
Brian Hartvigsen
Brian Hartvigsen
Created: 2014-09-26 10:59:19 -0600 MDT
Expires: 1969-12-31 17:00:00 -0700 MST
```

But `gpg -K` / `gpg --list-keys` shows something different:

```
sec 2048R/202D5E3C 2012-09-21 [expires: 2019-10-03]
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
ssb 2048R/F982D4B0 2012-09-21
ssb 4096R/81255BEB 2015-10-03
ssb 4096R/CF53D84F 2015-10-03
```

```
pub 2048R/202D5E3C 2012-09-21 [expires: 2019-10-03]
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
uid Brian Hartvigsen
sub 4096R/81255BEB 2015-10-03 [expires: 2019-10-03]
sub 4096R/CF53D84F 2015-10-03 [expires: 2019-10-03]
```

The 2048R/F982D4B0 subkey was revoked in favor of the 4096bit keys.

Tried doing a `keybase pgp select --multi` and telling it to update the public key but it says it's up-to-date. No idea what to do to resolve this and get everything working 100% again.

Start by reproducing the failure through website user tracking and the CLI `keybase login` flow that exports a GPG secret key; compare it with the working CLI path that invokes GPG commands. Check how the revoked and replacement subkeys are handled, and consider the issue resolved when both affected flows accept the selected key without the bad-signature error.

Written by the indexing model from the issue text.