
Bill Frantz <frantz@netcom.com> writes:
At 2:41 AM -0700 10/11/97, Adam Back wrote:
5. The IETF process should be accepting proposed designs and deciding on the best ones, which PGP Inc, and the other suppliers would then go and implement. As it is now, as William Allen Simpson just pointed out, PGP Inc is cruising ahead implementing, and deploying things without bothering with the OpenPGP process.
Just a quick reality check here. Frequently implementations have proceeded IETF standards. That is one of the strengths of the IETF process (as compared with e.g the CCITT.)
I must admit some ignorance of the IETF processes due to my only understandings being gained from intermittent following of the IPSEC standardisation process, and in that respect I thank you for the data point... However, I would defend that my understanding is, and my point was more that proposals with trial implementations should be used as discussion points, and as competing draft proposals rather than being used as arguments for it being necessary to build compatibility with just because someone has rushed off and sold copies of them, prior to ratification of those proposals by the standardisation process. And that independently of the technical merits of those proposals, or arguably even in the face of evidence that there are more secure alternatives to these proposals. The IETF standardisation process is supposed to make decisions based on technical merit. Not based on marketing clout. Nor even based on reputation capital, something which PGP surely has in abundance, as transferred to it by Phil Zimmermann with his virtual net.god status. I also take exception to PGP's Will Price's attempt at silencing negative discussion of the security and political aspects of PGP's GAKware, in his rhetoric on this being an inappropriate forum for discussion of political aspects of CMR. If Will Price thinks that we should just lie down and accept PGP fielding inferior security GAKware systems, and accept PGP trying to impose them on the standard, he can think again. Crypto politics can't help but play some part in discussion of crypto standards. As Tim May pointed out in an earlier post, we gave the same roasting to companies participating in the Key Recovery Alliance Program, and to companies like TIS, and IBM for various GAK sell out deals. In fact, Netscape got worse roastings for far lesser crimes than PGP's crimes in attempting to architect GAKware into the OpenPGP standard, or if that fails, in PGP's death wish in attempting to commit reputational suicide by implementing and widely deploying GAKware. My concern specifically is that some of the less desirable aspects of the way that PGP have implemented CMR should not be adopted into the standard for interoperability reasons alone. I am worrying that PGP Inc will shortly be using this line of reasoning, for backwards compatibility with pgp5.5 functionality for similar reasons as one might reasonably argue for backwards compatibility with pgp2.x. I noticed that Ian Grigg (Systemics) also expressed this point about standards process manipulation well in his article. Systemics has a much better track record for open development, and openness of design decisions than PGP Inc since it's incorporation, or before that than the pgp3.0 development team of two in beetling themselves off in a room at Sun or wherever and taking ages to develop software. (No offense intended to said developers technical ability, which I respect immensely, the error was organisational.) Systemics is also outside of the US and for that reason better placed to compete internationally. PGP Inc is losing reputation capital to Systemics and other such small companies in eroding it's support from netizens by fielding GAKware systems. (I have no affiliation with Systemics). Adam