I have created a key, and created a subkey. With a subkey, I signed a file. Verification works. Revoked the key, verification does not hold. This is the expected behavior.
However, If I try to sign with the same subkey and verify it still works. What am I doing wrong? Here is what am I doing in full:
$ gpg --gen-key
$ gpg -k
/Users/mustafa/.gnupg/pubring.kbx
---------------------------------
pub rsa2048 2019-02-03 [SC] [expires: 2021-02-02]
5DD923FBCF6392A5CB366167D4C0627A07510C6C
uid [ultimate] Mustafa <mustafa91@gmail.com>
sub rsa2048 2019-02-03 [E] [expires: 2021-02-02]
Using edit key, add a subkey.
$ gpg --edit-key 5DD923FBCF6392A5CB366167D4C0627A07510C6C
sec rsa2048/D4C0627A07510C6C
created: 2019-02-03 expires: 2021-02-02 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/E058B91696C43666
created: 2019-02-03 expires: 2021-02-02 usage: E
gpg> addkey
sec rsa2048/D4C0627A07510C6C
created: 2019-02-03 expires: 2021-02-02 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/E058B91696C43666
created: 2019-02-03 expires: 2021-02-02 usage: E
ssb rsa2048/38616BDAE66E418C
created: 2019-02-03 expires: 2019-02-13 usage: S
[ultimate] (1). Mustafa <mustafa91@gmail.com>
gpg> q
Save changes? (y/N) y
Sign a file and verify it.
$ gpg --armor --detach-sign --default-key 38616BDAE66E418C test.txt
gpg: using "38616BDAE66E418C" as default secret key for signing
$ gpg --verify test.txt.asc test.txt
gpg: Signature made Sun Feb 3 21:49:43 2019 +03
gpg: using RSA key 485FC77FC73DA3B800C7F41538616BDAE66E418C
gpg: Good signature from "Mustafa <mustafa91@gmail.com>" [ultimate]
Revoke the key with message "This key is now in the hands of the enemy."
$ gpg --edit-key 5DD923FBCF6392A5CB366167D4C0627A07510C6C
gpg> key 2
sec rsa2048/D4C0627A07510C6C
created: 2019-02-03 expires: 2021-02-02 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/E058B91696C43666
created: 2019-02-03 expires: 2021-02-02 usage: E
ssb* rsa2048/38616BDAE66E418C
created: 2019-02-03 expires: 2019-02-13 usage: S
gpg> revkey
sec rsa2048/D4C0627A07510C6C
created: 2019-02-03 expires: 2021-02-02 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/E058B91696C43666
created: 2019-02-03 expires: 2021-02-02 usage: E
The following key was revoked on 2019-02-03 by RSA key D4C0627A07510C6C Mustafa <mustafa91@gmail.com>
ssb rsa2048/38616BDAE66E418C
created: 2019-02-03 revoked: 2019-02-03 usage: S
[ultimate] (1). Mustafa <mustafa91@gmail.com>
Try to verify the old signature and see it fails.
$ gpg --verify test.txt.asc test.txt
gpg: Signature made Sun Feb 3 21:49:43 2019 +03
gpg: using RSA key 485FC77FC73DA3B800C7F41538616BDAE66E418C
gpg: Good signature from "Mustafa <mustafa91@gmail.com>" [ultimate]
gpg: WARNING: This subkey has been revoked by its owner!
gpg: reason for revocation: Key has been compromised
gpg: revocation comment: This key is now in the hands of the enemy.
However, trying to sign with revoked key.
$ rm test.key.asc
$ gpg --armor --detach-sign --default-key 38616BDAE66E418C test.txt
gpg: using "38616BDAE66E418C" as default secret key for signing
Why does it not fail? How can it be verified?
$ gpg --verify test.txt.asc test.txt
gpg: Signature made Sun Feb 3 21:53:11 2019 +03
gpg: using RSA key 5DD923FBCF6392A5CB366167D4C0627A07510C6C
gpg: Good signature from "Mustafa <mustafa91@gmail.com>" [ultimate]
Look at your last two excerpts. Despite the fact that you specified the default signing key to be 38616BDAE66E418C, when you do the verify it reports having been signed with D4C0627A07510C6C.
If you utilize the -v verbose option of gpg, you will see that if the specified default key is revoked, it falls back to the next usable signing key.
To illustrate this, I recreated your scenario:
sec rsa2048/4E5CB15076F1318E
created: 2019-02-09 expires: 2021-02-08 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/3303CBB274AECA3B
created: 2019-02-09 expires: 2021-02-08 usage: E
The following key was revoked on 2019-02-09 by RSA key 4E5CB15076F1318E Herp Derp <herp@derp.com>
ssb rsa2048/8ABD3900E64E7972
created: 2019-02-09 revoked: 2019-02-09 usage: S
[ultimate] (1). Herp Derp <herp@derp.com>
Signing with subkey prior to revoking:
$ gpg -v --armor --detach-sign --default-key 8ABD3900E64E7972 test.txt
gpg: using pgp trust model
gpg: using "8ABD3900E64E7972" as default secret key for signing
gpg: using subkey 8ABD3900E64E7972 instead of primary key 4E5CB15076F1318E
gpg: writing to 'test.txt.asc'
gpg: RSA/SHA256 signature from: "8ABD3900E64E7972 Herp Derp <herp@derp.com>"
Signing with subkey after revoking:
$ gpg -v --armor --detach-sign --default-key 8ABD3900E64E7972 test.txt
gpg: Note: signature key 8ABD3900E64E7972 has been revoked
gpg: using pgp trust model
gpg: using "8ABD3900E64E7972" as default secret key for signing
gpg: Note: signature key 8ABD3900E64E7972 has been revoked
gpg: writing to 'test.txt.asc'
gpg: RSA/SHA256 signature from: "4E5CB15076F1318E Herp Derp <herp@derp.com>"
You can see that in the second example, gpg identifies the subkey as revoked and falls back to the primary key.