It is often useful to include some information associated with a signature
that is not in the hashed portion. There are several reasons for this.
First, some information is not security critical and there is no reason
to hash it. Second, some such information may be subject to change and
updates, and it is desirable for the document to be edited in place in
order to make changes without invalidating the siganture. And third,
some information cannot be calculated until after the signature hash is
calculated due to the semantics involved.
Examples of the first case would be an identifier which indicates the
signing key. In PGP this would be the key ID; in SMIME, CMS and other
PKCS-7 derived formats it is the IssuerAndSerialNumber. These fields
are not hashed. This is not security critical because it is essentially
a hint about where to find the key. If this data is altered, the wrong
key will be found and the signature won't verify.
Examples of the second case would be other kinds of hints for finding the
signing key, in the form of URLs or database pointers which might change.
PGP's preferred key server subpacket might fall into this category.
Another example would be the KeyInfo field in the XML signature format
(http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/). This has a
number of options for ways to identify and locate keys. It is not in
the hashed area.
Examples of the third case would be the UnauthenticatedAttributes of the
PKCS-7 family. CMS (RFC2630) uses this field to hold a countersignature,
which is a signature on a signature. This cannot be calculated until
after the signature is calculated so it must be in the unhashed region.
PGP might want to add a countersignature mechanism in the future and an
unhashed subpacket would be a good place for it.
If you are really convinced that allowing unhashed data is wrong, you
should lend your expertise not only to PGP, but to the many other ongoing
cryptographic working groups and let them know that they are all on the
wrong track.
