In
<3(_dot_)0(_dot_)3(_dot_)32(_dot_)19971020191755(_dot_)00855100(_at_)mail(_dot_)imc(_dot_)org>,
on 10/20/97
at 09, Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> said:
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.
<sigh> the majority of developers are going to use some type of toolkit
for developing OpenPGP apps (or directly communicate with the PGP exe's).
You realy don't think thay are all going to spend the time required
developing there own crypto algorithms do you?? This has nothing to do
with PGP, Inc. as there are other 3rd party toolkits available or in
development.
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.
I strongly dissagree with this. By not being able to process the older
formats you have completly cut off a large section of curent PGP users. So
now your developers not only have to add PGP support but also have to do
the work of porting PGP itself to the operating system they are developing
on. This is a BadThing(TM) and will do more to push users to competing
specs than anything else.
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.
I see, so one implementation could only process say RSA keys while another
would only process DSS/DH? One would only use MD5 while another only used
SHA1? This doesn't sound like much of a *standard* at all. Obviously there
will have to be a base set of algorithms that are *MUST* for compatibilty
reasons so far I have seen no valid reason for ascii armor not being
included in that set.
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.
Obviously you have little understanding of why there is the "I woun't
bother" attatude. I have been activly involved in getting various software
vendors to include PGP support for their products for quite awhile now
(longer than there has been a PGP, Inc.). some of the more common reasons:
-- Lack of understanding the need for any encryption at all.
-- Lack of knowedge of even the most basic encryption principles. -- Lack
of proper documentation on how to integrate PGP into their products. --
Lack of tools to do so easily.
-- Lack of demand by their users.
Now added to this are items perticular to the OS/2 enviroment:
-- Lack of toolkit for OS.
-- Lack of comercial version of program.
-- General lack of support for OS.
Now I have been doing my best addressing these issues including porting
5.0 to OS/2, documenting implementation techneques, numerious
correspondance & phone calls to various vendors, currently developing a
PGP toolkit, ... ect. It has been a real up hill battle and now you want
to make it that much harder by allowing OpenPGP application be
non-compatiable with previous implemntations! PGP Inc was smarter than
that when they came out with 5.0 by supporting old 2.6.x formats, the IMAP
group was smarter than that by including support for POP3. This is nothing
new nor unusal in providing backward compatablilty in a new standard. By
taking out backward compatabilty from the specs you have thrown away the
biggest motiviation to go with OpenPGP rather than some other standard:
the current PGP user base.
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).
Well I hope before the next draft comes out that we have some debate on
the list here of what is required, what is suggested, and what is
optional. Now the keyID's & the ascii armor are two changes that have
never been disscused here before this draft was compiled I imagine that
there are more. IMHO any changes from the curent PGP implemntations need
to be examined and justifyed before they are added to the specs.
As far as the must use ASCII armor in RFC 2015 there were valid reasons
for this when we developed the RFC and those reasons are still valid
today.
--
---------------------------------------------------------------
William H. Geiger III http://www.amaranth.com/~whgiii
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html
---------------------------------------------------------------