tzeruch(_at_)ceddec(_dot_)com writes:
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.
I don't think there is actually an attack here. The only significance of
putting the keyid in the unhashed region is that a third party could change
the keyid without breaking the signature. But the only key which will
verify the signature is the correct one. He can't keep the signature
verifying unless he leaves the keyid alone.
If an attacker does change the keyid, all he can do is point at a
different key which won't verify the signature. But he could do that just
as easily even if the keyid were in the hashed portion - the signature
would still not be verified by the key selected by the altered keyid.
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?
It is difficult in general to determine the reason when a signature
doesn't verify. It could be that you've got the wrong key, or it could
be that the data has been altered (or both). Technically there is no
way to distinguish these. I don't think moving the keyid into or out
of the hashed region will help with this.
Hal