On Thu, 17 Feb 2011 14:12:20 -0500 David Shaw
<dshaw(_at_)jabberwocky(_dot_)com> wrote:
The problem is that the issuer subpacket doesn't
differentiate between V3 and V4, so it's possible to make a
DEADBEEF V3 key and use it to do a version rollback / denial of
service attack against a V4 key.
....
In terms of the issue that originally started this thread, the
proposal to include and compare the complete fingerprint resolves
this attack as well (slightly better in this case, in fact, since
a V3 fingerprint can't even accidentally collide with a V4 one).
.....
I wonder if it would also be useful for
implementations to simply refuse (or at least give the option to
refuse) to import any V3 keys.
But if there is an effective solution that offers inclusion, and
doesn't require any additional work, (and probably needs to be
implemented anyway independent of v3 keys), then why choose a path
of exclusion of V3 keys?
(Even if only for Ian's point, that there are lots of v3 encrypted
and signed material out there, that should be accessable.)
When Senderek described the ADK flaw, people could have argued
similarly to exclude V4 keys, (but wisely chose to keep subkey
capability and simple just fixed the ADK problem).
vedaal