ietf-openpgp
[Top] [All Lists]

Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?

1997-11-30 16:57:54
Gunther Schadow wrote:

Sorry for the massive cross-post, I just didn't know which e-mail list
David's reply came about...

It was posted to all the groups your original post went to. I simply did a
"reply" in my mailer. ;-)

First I'll summarize your points:

(more like labelling, but let's assume readers are following this thread.)


1. The "userbase"

2. Trust "algorithms"

3. Either has "unique" advantages

4. Intellectual "property"

5. The "gift model" no longer holds today

Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge
RSA-key PGP user base in free version 5.53, along with the web of
signatures built up over several years. Again--never mind; the Open PGP
working group must simply insure that that cannot happen again with Open
PGP.

6. David, you are obviously from the S/MIME camp, and you keep
fighting against PGP, even though I did not raise my voice for PGP
vs. S/MIME. There is a misunderstanding to my open letter.

I am a user of both. I was one of the first users of PGP until I found it
infringed. I then mounted a campaign behind the scenes (I wasn't looking for
credit, and I wasn't the only one) with Bidzos to license RSA for PGP. In the
event, Phil's intransigence (see Garfinkel's book) got in the way for a very
long time, but this wasn't because of any lack of my efforts, Eric Hughes'
efforts, or the goodwill of Jim Bidzos (see Garfinkel). When MIT PGP came out
as street-legal I was one of the first users, and both Jeff Schiller and Derek
Atkins signed my key. I have also helped beta test various versions, including
two US/Canada ones and FileCrypt. I find each of PGP and
S/MIME-X509-Netscape/Explorer have their unique and non-substituable uses,
mainly revolving around distinctions between their trust models.

As for your claim that you weren't raising your voice for PGP, if you reread
your post perhaps you will see why I thought in places you were. Never
mind--it's not worth sidetracking a discussion of principles and objectives
for that.


7. Either standards are not a reduction of choice and optionality, or
you are against the standardization.

There are two distinct trust models and systems involved. Each has a
non-substitutable and important place. Thus two standards are appropriate and
a reductionist argument isn't. Such cases are common in standards work.
Eventually the marketplace may choose one over the other, or each may be
viable for its purpose. We're not writing the Decalogue here.


If yor S/MIME has the "user base" and is self sufficient in that, why
are you seeking for the blessings of being called an Internet
standard? It sounds to me as if you're arguing  It is probably an abuse > of 
the term "standard" not being an end in itself but a marketing tool.

Do you have a question about substance here rather than an accusation?


I   have a strong  personal distaste  with S/MIME,   as the PKCS specs
require ASN.1, X500 and other OSI stuff that  does not merge very well
with  the rest of  the Internet infrastructure.

Like the bumblebee, S/MIME is out there in millions (well over 25 million)
of installed base copies of Netscape and Explorer. Perhaps if there is a
problem with the "internet infrastructure" it is that which needs
adjustment.

What I meant by "infrastructure" is design and technology. The IETF
has early enough opened itself up to OSI concepts and ASN.1. However,
these keep to not really fit into the rest of the internet
infrastructure. One good example is that X500 needed LDAP to be
deployed within the Internet infrastructure.

Sounds like you're arguing for some combination of the status quo and the easy
way out.


Thus far I've not heard of the Internet crashing down because
of the particular crypto protocols in, say, Netscape. There are far more

I am not talking about crashes -- these happened to me back in the
times when I used "userbase" and "marketplace" software :-). I am
talking about interoperability on an open an equal basis. I speak your
language, you speak mine.

Esperanto has not caught on in the marketplace, and for good reason.

most innovations have been achieved by governamntal funding and *not*
on industry on a competitional basis.

That isn't accurate. "Some" would be more apt. But you weren't arguing for
that in any case, since government funding for the Internet is mostly over.
You were arguing for the free "gift" model rather than the intellectual
property model.

<more stuff on the big government R&D model omitted>


 There is not much to be
theoretically developed in security today, all knowledge is there for
more than ten years.

I leave that statement for readers to contemplate, with my jaw hanging down in 
amazement.

The problem is deployment. Companies seem to be
too involved with patent rights and marketing that they are unable to
deploy knowledge and standards that do exist since many many
years.

That's also one for the readers to consider. Hint--there are well over 25
million copies of complete mail/news/browser software packages deployed using
S/MIME, and more copies are downloaded by the day--at a massive rate
heretofore not seen.



2. Trust "algorithms"

PGP is already on its way towards trusted third parties. And it is
useful. Conversely, I have heard S/MIME and SSL to be used without
real TTPs, but with a locally base of certificates. You are right,
both methods have its uses. But you are badly wrong in pointing out
that both methods require mutually non-interoperable software.

I didn't say "require". I said each trust model would become corrupted if it
attempted to encompass the other.


3. Either has "unique" advantages

see above. If they had, why not listing them and join all advantages
into one standard? 

Perhaps I should have said "unique and mutually exclusive" to drive the point
home, though I thought I had done that with my examples. For instance it is
mutually exclusive to allow anyone to be a signer and to allow only those
meeting certain standards to be signers.

David

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