[Top] [All Lists]

Re: The web of trust has no clothes.

1997-11-27 15:09:54
Ed Stone wrote in

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
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
raised by David Sternlight.

Another flaw in the web of trust and PGP is now revealed and comes
to roost.  Now that PGP Inc. has deep-sixed RSA in new free
not only does everyone with an old RSA key have to generate a new
but also a complete new set of signatures and web of trust must be
if they wish to use the "better" algorithms. And the new keys must
distributed to correspondents, either directly or by "pull" from
servers. This took years the first time--perhaps the second time it
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
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

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
web of trust.  The new keys do not have to start from scratch, as

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
(Nothing personal--this is a notional example with details to fix
approach you adopted forces the entire user base to generate new keys if
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
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.
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
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
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
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
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
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
including "Classical" RSA-IDEA PGP, with appropriate flags to enable
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

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
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
example). GIven empirically-based time tables for the completion of the
work, and likely implementation times thereafter, I think this could be
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
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
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
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

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
groups in this distribution, since even the Open PGP folks can benefit
understanding PGP Inc.'s thinking and intentions with respect to its


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

<Prev in Thread] Current Thread [Next in Thread>