ietf-openpgp
[Top] [All Lists]

Re: New Draft... going forward

1997-10-20 19:14:16
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.

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.

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.

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.

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.

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.

I hope that the next version of the OpenPGP draft says what is required,
what is suggested, and what's completely optional. The phrase at the
beginning of 3.1.1 of the OpenPGP draft seems wrong in that it says that
you can follow RFC 2015 and carry either ASCII armor or binary data;
however, RFC 2015 clearly says that you must use ASCII armor (in the second
sentence of section 2 of that document).


--Paul Hoffman, Director
--Internet Mail Consortium

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