ietf-openpgp
[Top] [All Lists]

Re: PGP evolving, improving

1997-11-26 09:59:31
(This message is being copied to the S/MIME list only for the matter in the last
paragraph of my response. Readers of the S/MIME list are requested to ignore the
matter that is PGP-specific).

Peterson is quite mistaken in his post below.

Free PGP had used RSAREF (for RSA), a software package made available free by
RSADSI for anyone's non-commercial use. No patent issues, fees, or litigation 
are
involved. This is TOTALLY clear, not "not exactly clear" as Peterson claims.  
There
is no "may be exempt" about those versions of free PGP. Thay are, in fact, fully
licensed for non-commercial use of RSA.  He should read the RSAREF license.

The usage has nothing to do with Viacrypt, mergers, or anything else of the 
sort.
It was that package, used in MIT PGP 2.x, (as well as the use of RSA overseas) 
that
produced the huge RSA key base that made PGP's reputation and which they wave in
front of the IETF to legitimiize themselves,. That PGP Inc. dropped RSA key
generation in Free PGP 5.0 (while continuing to use RSAREF--so it was a 
completely
gratuitous act), and then in Free 5.52 completely disabled any RSA compatibility
with that huge user base, is, I assert, unconscionable. SInce they have done 
that,
leaving aside the 'biting the hand that feeds one' aspect, the IETF should not
credit any PGP Inc. user base claims involving number of holders of RSA PGP 
keys.
This leaves PGP as a minuscule segment of the market compared with, for example,
the installed base of S/MIME applications (well over 25 million) from Netscape 
and
Microsoft. Any IETF standards activities must take account of that physical 
reality
in the marketplace.

Of more technical importance, this group should insure that this cannot happen
again. "Open" anything should not be designed so that an entire user base of 
keys
and certificates resulting from the standard will later become obsolete just
because a post-release algorithm is later added to the standard or an existing
algorithm in the release is "improved".

PGP Inc., having proven (in my view) their untrustworthiness on this point, 
should
not be allowed any configuration influence at all with an Open PGP standard, and
the IETF should insure that no control or influence of any kind over 
intellectual
property can be exercised on Open PGP by PGP Inc. I make this point not as a
general principle (since "non-discriminatory access on equitable terms" is the 
IETF
policy mantra despite the attempts of some to go beyond that in the case of
S/MIME), but rather because of PGP  Inc's specific behavior in obsoleting this
entire user base of PGP RSA keyholders in their latest versions of Free PGP..

Finally, a related point. If the pace of the Open PGP standards group is 
anything
like the past history of voluntary PGP efforts (or maybe voluntary anything
efforts), by the time the standard is done the RSA patent will have expired (or
close enought not to make much difference to reasonable market penetration 
rates).
It seems to me a realistic view of that eventuality and of realistic project
scheduling might be useful in avoiding much of the to and fro fussing on this 
topic
as well as totally avoiding all the noise about PGP Inc. vs. RSADSI. So to do 
would
have the advantage that one resultant IETF standard (Open PGP) could be 
designed to
be equally available to commercial users while using as "musts" two 
widely-trusted
algorithms, RSA and TDES.

If that thinking were accepted, the focus, as between the Open PGP standard and 
the
S/MIME 3 standard, can become what at least this writer thinks it ought to 
be--one
standard for web of trust and another for rigid heirarchical certification. This
would insure the (security) purity of each model, its use for the things it is 
most
suited for, and avoid any attempt to corrupt either (to try to emulate the other
and get some of its market share). To do otherwise would lose some of either the
free-form character of web of trust, or the exclusionary assurance character of
rigid heirarchical. (By "exclusionary" I mean that every certifier must fall 
within
the overall tree structure and to do so must meet specified, audited standards 
for
certification operations assured from the top down, as an "if and only if"
condition.)

David

A. Padgett Peterson P.E. Information Security wrote:

Note: this is really politics and not RFC business - my apologies but 
something
      of a sore point.

David rote:

And free PGP users didn't deserve an eased upgrade path, but rather to 
forcibly
obsolete all their keys, signatures and web of trust in the new version?
Especially since the RSA-key Free PGP user base is where PGP Inc. made their
reputation and the size of that base is constantly cited to the IETF and in
press releases as PGP's "customer base". Don't be ridiculous. And watch who 
you
throw stones at--can you say "glass house"?

Am surprised at this posting as it seems to forget one major problem: RSA is
patented. I have been told repeatedly by PGP that one of the reasons they do
not offer a site license (nor a real personal license for that matter in the
sense of being authorized to operate on all solely-used computers) is a
requirement by RSA for a "per CPU" fee.

True, the "free" version may be exempt under the terms of the patent but
this has never been exactly clear. Do suspect that when PGP and Viacrypt
did their inverse triangular multibuyout which resulted in a common point
for both free and commercial versions that some of the clauses of the RSA
license began covering PGP Inc and thus the "free" version as well (do you
realize that there are fifty thousand lawyers in Florida alone ?  Twice as
many Southern Bell yellow pages of attorneys as doctors and churches
combined ?)

Would be nice if RSA put the mechanism into the public domain but since they
reniged on the S/MIME components, I have doubts that this will happen.

Sounds like an opportunity for some programmer to create a "front end" to
determine which is being used and to invoke the correct version but this is
the reason that RSA (or any proprietary mechanism) should *never* be a MUST.

                                                Warmly,
                                                        Padgett


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

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