[Top] [All Lists]

Re: The armour issue

1997-11-25 17:29:14
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 
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.


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>, 
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 
          NetBITS#005/23-Oct-97 <>

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.


Gavan Schneider           | In a world without fences,
<gavan(_at_)magna(_dot_)com(_dot_)au>      | who needs Gates?

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