Quoting A. Padgett Peterson P.E. Information Security
<PADGETT(_at_)hobbes(_dot_)orl(_dot_)lmco(_dot_)com> on or about 1997/11/26
05:25 Sydney time-
Compatibility with Classic PGP has become optional. All OP implementations
will be compatible with each other. I suspect most will also be compatible
with the Classic PGP, but that's up to implementers and users.
Agree in principle. Armour/Mime/etc is really a mail issue with one
exception:
I would really be bothered if installation of PGPv14 made it impossible to
decrypt the thousands of instances of malicious software I keep in the
original PGP message format (easy to tell who it came from). Would also
like to read the ones received in the future as well.
...snip...
So would like to see something such as it MUST be an OPTION to any product
claiming PGP compatibility (is there such a thing as a mandatory option ?).
Personally, would not mind paying extra for the capability but would want to
be sure that it was available (I know - keep the old version around. Ever
read an upgrade license ?).
At the risk of sounding pedantic and apologies if this is really an
example of very dry humour (if intended it is very good :-) A 'mandatory
option' sets the scene where a product can only be compliant if there is
an option to support some list of old (proprietary) implementations. And
products which do support these implementations must allow this function
to be disabled. In order to bring the implementations into the standard
(ie., they cannot remain proprietary) each version of PGP Inc. product
(and Phil Z.'s shareware versions) would have to have an exact definition
of its behaviour spelled out into the O/PGP standard along with the
proposed behaviour we are now discussing.
One result of the O/PGP standard will (I hope) be more than one O/PGP
standard compliant product. One of those versions will no doubt come
from PGP Inc. And PGP Inc. can (and should) use backwards compatibility
as one of many product differentiations in the market place. Others may
also want to add this feature. This is a commercial and licensing issue.
The O/PGP standard does not need to mandate backwards compatibility (it
can but does not have to). IMHO this functionality should be left to
actual products.
Which leads me back to the issue of this thread viz., ascii-armour.
I have watched this issue over a couple of threads, joined some ideas,
added my thoughts, had some help Dave Crocker <dcrocker(_at_)imc(_dot_)org>,
and
present the following (hopefully useful) summary. (Many thanks to Dave
but the opinions and mistakes are mine :-)
My premises:
PGP ascii-armour is a 7-bit ascii form of the 8-bit encrypted content,
includes a fixed line-wrap, and uses base64 encoding. This allows
transmission through 7-bit channels over the internet.
Therefore armour has little to do with files stored on disk, and a lot to
do with email transmission, which is where mime comes into play.
There are already mime formats for asciified binary, eg., base64, which
mime compliant applications already need to implement. So there is no
need for additional code if O/PGP uses existing mime/base64 as the format
to protect the encrypted binary data during transmission over 7-bit
channels. This also means there is no particular need to keep the PGP
version of ascii-armour in the O/PGP standard.
But there is a need to specify the encapsulation of O/PGP email parts as
they are interpreted by the mime parsing system. I personally think the
standard should specify base64 and not leave it to printed quotable. I
accept that since printed quotable is not actually wrong (just less
efficient) this issue would he handled by way of very strong advice in
the standard.
Base64 increases a message size by 25%. (Each byte transmitted carries
6-bits of original information).
Printed quotable would more than double the message size since about half
the bytes of the encrypted text would have the high order bit true (ie.,
char [128..255]) and need to be encoded with a 3 byte sequence, eg.
"=9A", the char "=" is coded as "=3D". Not to mention the soft wrapping
"=\r" sequence every 80 characters.
Ref: "Winning the MIME QP Doll" by Will Mayall
<mayall(_at_)fogcity(_dot_)com>
NetBITS#005/23-Oct-97 <http://www.netbits.net/>
Both formats (base64 and printed quotable) break the transmitted text
into lines of about 80 characters. These are removed by the receiving
end during decoding/unpacking. Depending on the system base64 adds 1
[Unix,MacOS] or 2 [DOS,WIN] characters per line, printed quotable adds an
extra one again.
My conclusions:
1. Printed quotable should be avoided for the encrypted message body
because of its much higher overhead.
2. Existing mime/base64 encapsulation can replace PGP ascii-armour in the
O/PGP standard for transmission of encrypted email over the internet.
3. The O/PGP standard will not incur higher implementation cost by using
mime/base64, rather it will be using existing code.
Regards,
Gavan
Gavan Schneider | In a world without fences,
<gavan(_at_)magna(_dot_)com(_dot_)au> | who needs Gates?