On Thu, 23 Jul 1998, Hal Finney wrote:
I had not noticed that the spec required the issuer keyid to be in the
hashed area. PGP 5.X has always put it in the unhashed area. The theory
is that this is advisory information to help the software find the key
which issued the signature. In some applications it may not be necessary,
such as for an embedded system which has hardwired keys. There is no
security reason to put it in the hashed area.
Can we change this in the draft or is it too late?
I know that many drafts ago, there was nothing that needed to be included,
and I pointed out that the Keyid and Signature Creation time (which are in
all V3 sigs) should be a MUST, and the time MUST be in the hashed area,
But I don't think I said the KeyID needed to be in the hashed area, only
that it needed to be there.
Though I think someone else pointed out that it might be possible to find
(or generate) a key with the 64 bit ID that when combined might match the
two bytes of hash and the signature or something like that, and instead of
anyone knowledgable investigation, it was decided to move it into the
hashed area.
There are lots of extra things being hashed, so total time is minimally
affected by hashing 8 extra bytes (every uSec is sacred/ every uSec is
great...?) and it is easier to only have to search one area for both time
and key - the system could simply skip over the unhashed area entirely.
I am neutral on the spec change (except that the keyid MUST appear, it may
appear either place). Technically it doesn't have to appear for 1pass
signatures, but it avoids having to add a memory, and provides a check on
the layering. Wildcard key support is not a MUST (which would imply a
keyid of zero, not absence, and I think this is for encryption). If you
remove keyids entirely, you might need to download the entire database
from a keyserver and check each one to see if it matches - not a fast
process.
It is reasonable to have wildcard keys for encryption since you only have
a small number of secret keys to test. But for signatures it creates
problems.
Would it be ambiguous if a false keyid appeared in the unhashed section?
If one did appear, but was fake, do you say the signature is actually bad
when the hash corresponds (first two octets), and matches another key on
your ring?