You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pgpdump states a key expiration time subpacket as an absolute time in seconds since the epoch, but https://tools.ietf.org/html/rfc4880#section-5.2.3.6 indicates that it should be read as "seconds after key creation" instead. compare with gpg --list-packets:
0 dkg@alice:/tmp/cdtemp.Tvk0D4$ pgpdump < 000015-002.sig
Old: Signature Packet(tag 2)(549 bytes)
Ver 4 - new
Sig type - Subkey Binding Signature(0x18).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA512(hash 10)
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used for authentication
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Wed Jan 21 15:54:17 EST 2015
Hashed Sub: key expiration time(sub 9)(4 bytes)
Time - Thu Aug 4 01:50:07 EDT 1977
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xCCD2ED94D21739E9
Hash left 2 bytes - 98 20
RSA m^d mod n(4094 bits) - ...
-> PKCS-1
0 dkg@alice:/tmp/cdtemp.Tvk0D4$ gpg2 --list-packets < 000015-002.sig
# off=0 ctb=89 tag=2 hlen=3 plen=549
:signature packet: algo 1, keyid CCD2ED94D21739E9
version 4, created 1421873657, md5len 0, sigclass 0x18
digest algo 10, begin of digest 98 20
hashed subpkt 27 len 1 (key flags: 20)
hashed subpkt 2 len 4 (sig created 2015-01-21)
hashed subpkt 9 len 4 (key expires after 7y217d5h50m)
subpkt 16 len 8 (issuer key ID CCD2ED94D21739E9)
data: [4094 bits]
0 dkg@alice:/tmp/cdtemp.Tvk0D4$
in particular, the claim about 1977 in pgpdump is bogus :)
it should either display the expiration date as a temporal offset, or it should calculate the actual absolute date.
The text was updated successfully, but these errors were encountered:
pgpdump states a key expiration time subpacket as an absolute time in seconds since the epoch, but https://tools.ietf.org/html/rfc4880#section-5.2.3.6 indicates that it should be read as "seconds after key creation" instead. compare with
gpg --list-packets
:in particular, the claim about 1977 in pgpdump is bogus :)
it should either display the expiration date as a temporal offset, or it should calculate the actual absolute date.
The text was updated successfully, but these errors were encountered: