William, simply decode the packets as specified by the draft:
0xb9 = 10111001 = 10 1110 01, packet type 14.
What is packet type 14? You seem hung up on the idea that it is a
signature packet. It's not! Look at section 4.3:
: 0 -- Reserved. A packet must not have a tag with this value.
: 1 -- Encrypted Session Key Packet
: 2 -- Signature Packet
: 3 -- Conventionally Encrypted Session Key Packet
: 4 -- One-Pass Signature Packet
: 5 -- Secret Key Packet
: 6 -- Public Key Packet
: 7 -- Secret Subkey Packet
: 8 -- Compressed Data Packet
: 9 -- Symmetrically Encrypted Data Packet
: 10 -- Marker Packet
: 11 -- Literal Data Packet
: 12 -- Trust Packet
: 13 -- Name Packet
: 14 -- Subkey Packet
: 15 -- Reserved
: 16 -- Comment Packet
Packet type 14 is a subkey packet. It's not a signature packet. You are
completely mistaken in trying to interpret it as one.
The format of packet type 14 is in section 5.5.1.2 of the draft, where
it is explained that the same format is used as for a public key packet.
These are defined in 5.5.2. There you will see:
: A version 4 packet contains:
: - A one-octet version number (4).
: - A four-octet number denoting the time that the key was created.
: - A one-octet number denoting the public key algorithm of this key
: - A series of multi-precision integers comprising the key
: material. This algorithm-specific portion is:
:
: Algorithm Specific Fields for RSA public keys:
: - multiprecision integer (MPI) of RSA public modulus n;
: - MPI of RSA public encryption exponent e.
:
: Algorithm Specific Fields for DSA public keys:
: - MPI of DSA prime p;
: - MPI of DSA group order q (q is a prime divisor of p-1);
: - MPI of DSA group generator g;
: - MPI of DSA public key value y (= g**x where x is secret).
:
: Algorithm Specific Fields for Elgamal public keys:
: - MPI of Elgamal prime p;
: - MPI of Elgamal group generator g;
: - MPI of Elgamal public key value y (= g**x where x
: is secret).
This will explain the format of your packet.
As to your problem with the signatures sometimes being exported and
sometimes not: this usually means you are changing to a different public
keyring without also changing your secret keyring. Signature packets
are stored on the public keyring only, in 5.0 and earlier versions.
Key and userid packets are stored on both public and private keyrings.
If you change to a different public keyring file, you'll still see
your old key and userid, because they are stored on the secret keyring,
which you didn't change. But if you look for signatures, you will see
that they are now absent. That is because they were only stored in
the original public keyring file. If you export now you will get a key
without signatures.
This behavior goes back to PGP 2.X, and is due to the desire to segregate
the sensitive key material from the public material. However there is
some worry that it causes confusion like it has for you, and therefore
we might want to consider abandoning the dual-key-ring model and go to
a single file to store all the key/certificate information.
Hal Finney
PGP, Inc.