Ed Stone wrote in comp.security.pgp.discuss:
I believe this is a definitive response to the unsupported assertion
that the
web of trust is "broken" by new versions of PGP.
I respond to Finney, not Stone. I copy this to the open pgp list not
only
because Finney's post appeared there (in response to mine--I throw no
stones by
that remark), but also because there may be some valuable lessons here
for Open
PGP development.
From OpenPGP list:
Date: Mon, 24 Nov 1997 22:08:00 -0800
From: Hal Finney <hal(_at_)rain(_dot_)org>
To: ietf-open-pgp(_at_)imc(_dot_)org
Subject: Re: The web of trust has no clothes.
Sender: owner-ietf-open-pgp(_at_)imc(_dot_)org
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.
Since I've been somewhat critical of Jeff Schiller recently in the
context of
IETF actions toward RSADSI with respect to S/MIME and also the disabling
of RSA
key generation in MIT PGP 5.0, perhaps he'd not like to sign my newer
keys and
maybe even regrets he signed my earlier PGP key. WIth this feature , I
can get
him to "sign" my new keys iinvoluntarily. What is more, I can arrange
that my
new key, like my old one, has no expiration date, further locking Jeff
in.
(Nothing personal--this is a notional example with details to fix
ideas.)The
approach you adopted forces the entire user base to generate new keys if
they
wish the features of free 5.5x, and transfers trust in this somewhat
disadvantageous way for free 5.0. It also cuts off first-time PGP users
choosing 5.0 and all users of free 5.5x from two-way secure
communication with
those who wish to maintain their RSA keys for compatibility with what
appears
likely to be a much larger global user base for quite some time. It
also allows
the propagation of questionable signatures to the new web of trust at
the option
of the person with the signed key rather than the signer of the key.
Finally,
unless and until the new versions find their way somehow to
international users
at scale, it cuts that base off completely from even the possibility of
two-way
communication with first-time free 5.0 users and all free 5.5x users. I
do not
think this a very pretty picture, nor particularly considerate of the
existing
RSA-key user base which made your reputation.
There may be some concern that this would introduce certain kinds of
spoofing attacks. Let us assume that the old signatures are valid,
they may have been originally but the signer may have wished
subsequently to
invalidate them for either substantive or personal reasons. Since old
PGP keys
have no expiration dates and there was no CRL mechanism originally, this
is
weak. Better if you're going to start a new key structure to require new
signatures. I recognize that this seems to contradict my comment about
obsoleting the old web to trust, but I'd argue PGP should have preserved
compatibility with the old web via compatibility with the old keys,
while making
the new key structure possible in Free PGP, thus providing a graceful
and
user-driven upgrade path rather than an imposed one. The method
described above
is, instead, a kludge to attempt to avoid one of the more egregious
consequences
of what I think to have been a mistake in the first place.
I believe the direction Open PGP is moving in allows for many agreed
algorithms
including "Classical" RSA-IDEA PGP, with appropriate flags to enable
two-way
usage, and a backwards compatible upgrade path. If this is both true and
preserved as the group goes about its business, this would be a Good
Thing.
I would suggest both in light of the realities of the existing user base
and on
principle that Open PGP include Classical PGP as either a "should" or a
"must".
This would not violate what I understand to be the real ground rule:
non-discriminatory access to intellectual property on reasonable terms.
If there
is some difficulty in negotiating such terms, the date of coming into
effect of
such a "must" provision could be the expiration date of the RSA patent
(for
example). GIven empirically-based time tables for the completion of the
group's
work, and likely implementation times thereafter, I think this could be
a
practical approach.
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.)
Not so fast. See above.
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.
See above. Also, that PGP recognizes the importance of expiry is shown
by the
option to add an expiration date to newly generated keys
Hal Finney
hal(_at_)pgp(_dot_)com
While I've got you, Hal, why did PGP disable RSA key generation in free
5.0? Why
did they omit RSA entirely in free 5.5x? Why is it an extra-cost option
in pay
5.5? It it the intention to drop it completely in 6.x? It would be good
to have
an authoritative explanation. I think this would be of interest to all
the
groups in this distribution, since even the Open PGP folks can benefit
from
understanding PGP Inc.'s thinking and intentions with respect to its
products.
David
smime.p7s
Description: S/MIME Cryptographic Signature