How to handle a subkey whose self signature uses SHA256, but for which there is a revocation certificate that uses SHA1
I found a subkey whose binding signature uses SHA256, and for which there is a revocation certificate that uses SHA1. This is a problem, because the StandardPolicy doesn't consider this subkey to be rejected: instead, the StandardPolicy consider the revocation certificate to be invalid (it uses SHA1).
Public-Key Packet, old CTB, 525 bytes
Version: 4
Creation time: 2016-03-05 13:08:25 UTC
Pk algo: RSA (Encrypt or Sign)
Pk size: 4096 bits
Fingerprint: EA7E 6B72 4BC9 FBF2 D171 EB72 6B72 0BE9 C5CF 6D9E
KeyID: 6B72 0BE9 C5CF 6D9E
...
Public-Subkey Packet, old CTB, 525 bytes
Version: 4
Creation time: 2016-08-19 00:26:00 UTC
Pk algo: RSA (Encrypt or Sign)
Pk size: 4096 bits
Fingerprint: 1B7E 3A5A 587E BEB4 B045 09F2 6109 2ABB 9741 9DF3
KeyID: 6109 2ABB 9741 9DF3
Signature Packet, old CTB, 1086 bytes
Version: 4
Type: SubkeyBinding
Pk algo: RSA (Encrypt or Sign)
Hash algo: SHA256
Hashed area:
Signature creation time: 2016-08-19 00:26:00 UTC
Key flags: S
Unhashed area:
Issuer: 6B72 0BE9 C5CF 6D9E
Embedded signature:
Signature Packet
Version: 4
Type: PrimaryKeyBinding
Pk algo: RSA (Encrypt or Sign)
Hash algo: SHA256
Hashed area:
Signature creation time: 2016-08-19 00:26:00 UTC
Unhashed area:
Issuer: 6109 2ABB 9741 9DF3
Digest prefix: F064
Level: 0 (signature over data)
Digest prefix: 1F23
Level: 0 (signature over data)
Signature Packet, old CTB, 543 bytes
Version: 4
Type: SubkeyRevocation
Pk algo: RSA (Encrypt or Sign)
Hash algo: SHA1
Hashed area:
Signature creation time: 2017-04-26 01:40:10 UTC
Reason for revocation: Key is superseded
Unhashed area:
Issuer: 6B72 0BE9 C5CF 6D9E
Digest prefix: 3B24
Level: 0 (signature over data)
Edited by Neal H. Walfield