BAD sig from own key

Fri Dec 7 03:56:01 2001

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--Boundary_(ID_BlJDEx4GN8pfQ8bXRiiIyw)
Content-id: <Pine.LNX.4.33.0112061942151.1426@dorm852.resnet.nau.edu>
Content-type: TEXT/PLAIN; CHARSET=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am using gpg 1.0.6 from an RPM made by RedHat (gnupg-1.0.6-3.rpm) along 
with pgp4pine 1.76 from an RPM made by CW Zuckschwerdt <zany@triq.net> 
(pgp4pine-1.75-1.rpm) with Pine 4.33 from an RPM also made by RedHat 
(pine-4.33-15.rpm).

I have been using this configuration successfully for nearly a year. 
Tuesday I sent a signed mail to a friend, as I do daily, and the signature 
did not verify. The recipient was not able to verify it, nor was I. I have 
attached the original mail to this mail so that others might be able to 
look at it. My public key is available from http://www.keyserver.net

gpg output is:

gpg: Signature made Tue 04 Dec 2001 08:41:49 PM MST using DSA key ID 
6550D214
gpg: BAD signature from "Chad Davis <cad8@dana.ucc.nau.edu>"

which is the correct key. The two things I have noticed here are that the 
gpg output refers to only one of the two user ids that are on that key, 
whereas a successful verification outputs something like:

gpg: Good signature from "Chad Davis <cad8@dana.ucc.nau.edu>"
gpg:                 aka "Chad Davis <cad8@acm.org>"

The other thing I noticed is that my signature (from my ~/.signature, not
the gpg signature) in the file which does not verify has one character
replaced by (what appears to be) a space. This would seem to be the source
of the problem, but how does something like this happen? I believe Pine
simply pipes the message to pgp4pine and displays the output that is
returned. This would seem to indicate a problem in pgp4pine or gpg. I
would suspect pgp4pine before I would suspect gpg, but I know a few of the
people on this list are using pgp4pine. Either way it seems like a serious
issue. 

I can't see how this could be simply stupid user error, because, like I
said, I've been using this configuration for a year and all signatures
before and since this particular mail have verified. Naturally, one's
first encounter with the "BAD signature" message is unnerving, but this
was my own signature!

Any insight whatsoever would help me sleep better at night as well as
restore my faith in applied cryptography. I'm willing to supply any and
all information, including my private key (after revoking it) if it will
help find the source if this confusion.

- ---------------------
Chad Davis
cad8@dana.ucc.nau.edu

PGP Key ID 0x6550D214
available from:
http://www.keyserver.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE8EC9KDaIf/GVQ0hQRAjylAJ9IChmjbJ0ZdZ2PtknS/IIr6vf15wCfcUrR
9JXX3792b2S7EVMJO8GaIwk=
=rzqA
-----END PGP SIGNATURE-----

--Boundary_(ID_BlJDEx4GN8pfQ8bXRiiIyw)
Content-id: <Pine.LNX.4.33.0112061953480.1426@dorm852.resnet.nau.edu>
Content-type: TEXT/PLAIN; charset=US-ASCII; name=bad-sig
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename=bad-sig
Content-description:

RnJvbSBjYWQ4QGRhbmEudWNjLm5hdS5lZHUgVHVlIERlYyAgNCAyMDo1OTo0OCAy
MDAxDQpEYXRlOiBUdWUsIDQgRGVjIDIwMDEgMjA6NDE6MDUgLTA3MDAgKE1TVCkN
CkZyb206IENoYWQgRGF2aXMgPGNhZDhAZGFuYS51Y2MubmF1LmVkdT4NClRvOiBB
bnNlbG0gVm9zc2VuIDxBbnNlbG1WQGdteC5kZT4NClN1YmplY3Q6IE1hdGgNCg0K
LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0K
DQoNCkNoZWNraW5nIG15IGFuc3dlciB3aXRoIHlvdSBhcyBJIGdvOg0KDQoxKSAN
CmEpIE5vdCBhIGZpZWxkLCBiZWNhdXNlIDIgaGFzIG5vIG11bHRpcGxpY2F0aXZl
IGludmVyc2UuDQpiKSBJcyBhIGZpZWxkLg0KDQo1KQ0KYSkgU3VwOiAxLCBJbmY6
IDANCmIpIFN1cDogbm9uZSwgSW5mOiAwDQpjKSBTdXA6IFBpLCBJbmY6IC0xDQoN
CjMpIA0KQXNzdW1lIDAgaGFzIGEgbXVsdC4gaW52ZXJzZSwgMF4tMQ0KU2luY2Ug
RiBpcyBhIGZpZWxkLCBpdCBoYXMgYSBtdWx0LiBpZGVudGl0eSwgMQ0KU28sIDAg
KiAwXi0xID0gMQ0KQnV0LCAwICogeCA9IDAgZm9yIGFsbCB4IC0+IHN1YnByb29m
IGZyb20gY2xhc3Mgbm90ZXMNClNvLCAwID0gMSwgd2hpY2ggY29udHJhZGljdHMg
dGhlIGZhY3QgdGhhdCBGIGlzIGEgZmllbGQuDQpTbywgMCBoYXMgbm8gbXVsdC4g
aW52ZXJzZS4NCg0KNCkNCmEpDQpBc3N1bWUgeDx5DQpUaGVuIHggKyAteCA8IHkg
KyAteA0KU28sIDAgPCB5ICsgLXgNClNvLCAwICsgLXkgPCB5ICsgLXkgKyAteA0K
U28sIC15IDwgMCArIHgNClNvLCAteSA8IC14DQoNCmIpDQpBc3N1bWUgeDx5IGFu
ZCB6PDANClRoZW4gLXogZXhpc3RzIGFuZCANCnogKyAteiA9IDAgPCAwICsgLXog
PSAteg0KU2luY2UgRiBpcyBhbiBvcmRlcmVkIGZpZWxkIGFuZCB4PHkgYW5kIDA8
LXosIHgoLXopIDwgeSgteikNCj5Gcm9tIHByb2JsZW0gMmIpLCAteCA9ICgtMSl4
DQpTbywgLXogPSAoLTEpeg0KQW5kIHgoLTEpeiA8IHkoLTEpeg0KKC0xKXh6IDwg
KC0xKXl6DQpTbywgeHogPCB5eg0KDQoNCi0gLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpDaGFkIERhdmlzDQpjYWQ4QGRhbmEudWNjLm5hdS5lZHUNCg0KUEdQIEtleSBJ
RCAweDY1NTBEMjE0DQphdmFpbGFibGUgZnJvbToNCmh0dHA6Ly93d3cua2V5c2Vy
dmVyLm5ldA0KDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJz
aW9uOiBHbnVQRyB2MS4wLjYgKEdOVS9MaW51eCkNCg0KaUQ4REJRRThEWmQ5RGFJ
Zi9HVlEwaFFSQXBIakFLQ3Y2bmhGQVdTMUkxU1BwbUdpdXB5cHhrV0d4QUNnNmxu
MA0KYXRzQnQvQzhFVit0Wi9TQU1BTEFuZkU9DQo9Y2dPOQ0KLS0tLS1FTkQgUEdQ
IFNJR05BVFVSRS0tLS0tDQoNCg0K

--Boundary_(ID_BlJDEx4GN8pfQ8bXRiiIyw)--