weasel wrote: > No GOODSIG. > > So gpgv considers a signature valid that gpg doesn't. That in itself > should be a grave bug.
FWIW, /usr/share/doc/gnupg/DETAILS.gz says:
GOODSIG <long keyid> <username>
The signature with the keyid is good. For each signature only
one of the three codes GOODSIG, BADSIG or ERRSIG will be
emitted and they may be used as a marker for a new signature.
The username is the primary one encoded in UTF-8 and %XX
escaped.
[...]
VALIDSIG <fingerprint in hex> <sig_creation_date> <sig-timestamp>
<expire-timestamp> <sig-version> <reserved> <pubkey-algo>
<hash-algo> <sig-class> <primary-key-fpr>
The signature with the keyid is good. This is the same as
GOODSIG but has the fingerprint as the argument. Both status
lines are emitted for a good signature. All arguments here
are on one long line. sig-timestamp is the signature creation
time in seconds after the epoch. expire-timestamp is the
signature expiration time in seconds after the epoch (zero
means "does not expire"). sig-version, pubkey-algo, hash-algo,
and sig-class (a 2-byte hex value) are all straight from the
signature packet. PRIMARY-KEY-FPR is the fingerprint of the
primary key or identical to the first argument. This is
useful to get back to the primary key without running gpg
again for this purpose.
So the documentation itself is unclear about the intended behavior. Can
a signature be VALIDSIG but not GOODSIG? What about the situation where
neither GOODSIG, BADSIG, nor ERRSIG show up, as is the case here?
i agree with weasel that this is currently a really bad situation. It
is bad enough that gpg accepts a signature made by an expired key if the
signature was during the key's lifetime. But it also does not
explicitly reject signatures that were made after a key is known to expire.
That is, Key A is valid beginning at time B, and expires at time E.
gnupg does not appear to distinguish between these cases:
0) a signature made at time X where B < X < E
1) a signature made at time X where B < E < X
At the very least, any signature made by a key *after* the key itself is
believed to be expired (case 1 above) should be considered
untrustworthy, but gpg (and gpg2, according to my tests) don't seem to
compare the date of the signature against the key expiration at all
(though they do compare it against the key creation timestamp). They
*do* compare the key expiration time against "now", which is a good thing.
I'm attaching a tarball with an OpenPGP public key, a simple test file,
and two signatures made over the test file. One of the signatures is
made within the lifespan of the key, and the other is made after the key
expires.
I'm not sure what is the right thing to do about this. :(
--dkg
testsig.tgz
Description: GNU Unix tar archive
signature.asc
Description: OpenPGP digital signature
