Re: New Draft... going forward

[Ian Grigg <iang@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----

Paul Hoffman / IMC wrote:
> 
> At 07:29 PM 10/20/97 -0500, William H. Geiger III wrote:
> >There is no need to modify the MIME toolkit or at least none above what
> >must be already done to accommodate incorporating PGP/MIME types. The
> >ascii armor encoding is handled by PGP and would be included in any PGP
> >toolkit a programmer may be using.
> 
> I don't understand why you think that everyone will use a PGP toolkit. One
> of the main purposes of us doing the open spec work is so that people don't
> have to use anyone else's toolkits. If we assume everyone will use a PGP
> toolkit, there's no need to do this work in the IETF. Simply let PGP, Inc.
> specify what is PGP x.y and be done with it.

This is a confusion of the two meanings of PGP - another issue in itself
that must be sorted out before we can really finish the standard.

Every programmer will use a toolkit that implements PGP format tools. 
Whether they choose the one supplied by PGP, Inc is up to them.

Or, to put it another way, if your programmers are not using a toolkit,
then you have more problems than worrying about Ascii Armouring.  In all
probability, they are using an old codebase that needs replacing with a
proper toolkit.  PGP Inc have one, I recall there are a few floating
around, including a couple in the <plug> Cryptix </plug> libraries.

> >As a matter of fact any Open PGP
> >implementation would require a programmer be able to use ascii armor so
> >his program can process messages generated by older version of PGP.
> 
> We definitely have the option of requiring that. We also have the option of
> not requiring it.

We only theoretically have the option to not require it.  The number of
people using anything other than 2.6 or thereabouts is minute compared
to the installed base of "classic" PGP.  Any clues on how many copies of
5.* have been sold?



> >You
> >are not seriously advocating that an Open PGP application be unable to
> >process these older formats are you??
> 
> I most certainly am. If the IETF Calendaring and Scheduling Working Group,
> for example, wants to use OpenPGP for handing around scheduling events in
> an automated environment (that is, without human intervention), there is
> absolutely no reason why the must be able to process older PGP formats. If
> our spec requires that they do so, it is that much harder for them to chose
> it over competing specs.

Hardly.  They simply choose not to choose on the basis of this unneeded
feature.  All products are standardised around a set of features that is
good for most of the people and perfect for none of them.  Ignoring
non-specific features is part of their selection process.

> OpenPGP can be useful for many types of applications other than humans
> sending email to each other. Many other IETF messaging protocols can use
> the privacy and authentication offered by OpenPGP. They would have
> absolutely no use for backwards compatibility with earlier versions.

True, we can construct these scenarios.  Fact is, the majority of
implementators and the majority of interested parties are here because
they have existing applications, existing code bases, existing needs. 
We'll worry about futures once we get out code into shape.



> This isn't to say that we shouldn't try to get software to be able to
> process and possibly even emit messages from earlier versions, but there is
> no reason to *force* them to because what we specify will be complete and
> secure by itself. We should make it as easy as possible for some who starts
> with OpenPGP to add support for earlier versions without burdening them
> with implementation issues that aren't relevant to OpenPGP.

"Complete and secure" is not the only goal.  Standardisation necessarily
accomodates the existing implementations.  Are you seriously suggesting
that the process of standardisation would ignore major features of
existing implementations, such as the favoured method of message
passing?  That's not standardisation as I know it; that's a new
protocol.

> >This is silly, I really can't see anyone saying "I'm not going to support
> >PGP because it uses ASCII armor encoding".
> 
> By itself, no. But if we require lots of other things that make it that
> much harder for people to implement (such as requiring them being able to
> handle all the earlier packet formats), they will probably have the same
> attitude as they have had up to now: "I won't bother". That hurts all of
> us, and is one of the driving forces for us to make a simple and useful spec.

A simple and useful spec that doesn't talk to the millions of 2.6 users
out there is an contradiction in terms, at least if we are still talking
about standardisation.  Just look at the chaos in the market place as
people bump into the allegedly compatible PGP 5 programs with their
incompatible default keys.  Not that I don't sympathise with PGP Inc for
their patent grumbles, but what made them think the users would accept
PGP Inc's problems with willing arms?  Users don't give a damn, they
just want to send messages.  And if the messages don't get through, then
the program doesn't work.

- -- 
iang                                      systemics.com

FP: 1189 4417 F202 5DBD  5DF3 4FCD 3685 FDDE on pgp.com

-----BEGIN PGP SIGNATURE-----
Version: Cryptix 2.21

iQCVAgUANEwe2pUdDk1bRs+FAQGr7gP+JkLK+XOKDskm9kdLSsklbw9PlAjWDPgW
MH+9btupRhMUezTaOt2jraja3sH3m9BxXOFcNE/7wk82yQmtald2eOplh6bRYMei
hx5m9vAEmIYnZfv33eBpGBP0v4uhpuP8grSo94DIAT+ZOuc3Qa1o2aNGCwW+o195
9ZXNJMV+NJM=
=AQFD
-----END PGP SIGNATURE-----