PGP 5.X implements an extension to the trust model to address the issue
raised by David Sternlight.
Another flaw in the web of trust and PGP is now revealed and comes home
to roost. Now that PGP Inc. has deep-sixed RSA in new free versions,
not only does everyone with an old RSA key have to generate a new key
but also a complete new set of signatures and web of trust must be built
if they wish to use the "better" algorithms. And the new keys must be
distributed to correspondents, either directly or by "pull" from
servers. This took years the first time--perhaps the second time it will
be a bit faster.
The way it works is as follows. If you have two keys with identical
userids, and the first key signs the second userid, then validity from
the signatures on the first user ID gets propagated to the second userid.
The effect is that if you generate a new DSA key with the same name
as your old RSA key, and sign it with your old key, then your new key
inherits the validity from the old key. (This propagation happens
irrespective of whether the old key is marked as a trusted introducer.)
In effect, the signatures on your old key automatically get applied to
your new key. This is an easy way to inherit the signatures from the old
web of trust. The new keys do not have to start from scratch, as implied
above.
There may be some concern that this would introduce certain kinds of
spoofing attacks. Let us assume that the old signatures are valid,
that the old key is in fact properly bound to the userid. (If the old
signatures are invalid, no one should trust them anyway, so they have no
impact on the web of trust.) Now, when that old key issues a signature
on the same userid on another key, it is in effect asserting that the
same keyholder controls this other key.
If the other key actually does belong to the same keyholder, then there
is no danger in transferring validity from the signatures on the old
key over to the new one. The new key is in fact valid, and so measures
which show it as valid are proper.
The questionable aspect arises if the new key does not actually belong
to the keyholder. For example, someone might create a key and put Phil
Zimmermann's name and email address on it. If Phil signed that name, he
would be falsely claiming that this other key belonged to him. With the
5.X extension to the trust model, other signatures on Phil's true key
would be treated as though they apply to this new key. Someone trying
to encrypt a message to Phil might find their software encrypting it to
this new key instead of Phil's real key. This might appear to be a
security weakness.
Note, though, that this can only occur with Phil's active cooperation.
He has knowingly signed a userid which matches his own but is bound to
someone else's key. Only in this circumstance can it occur that other
people will encrypt to this key when they mean to encrypt to Phil.
However, since this was done with Phil's active cooperation, he is
intentionally sharing the contents of messages with the other keyholder.
But if this is his intention, he can do that even with the old trust
model. He has the power to share the contents of his encrypted messages
with anyone he wants.
It was our conclusion that this feature does not add any new weaknesses
to the PGP trust model, and it greatly improves its robustness and
usability as new keys are introduced. In fact, the basic idea can
probably be improved to make it easier to retire and replace old keys
in a more general way, while retaining the validity of old signatures.
This would be a good topic for OP V2.
Hal Finney
hal(_at_)pgp(_dot_)com
hal(_at_)rain(_dot_)org