Re: The armour issue

[Jon Callas <[e-mail]>]

At 11:29 AM 11/26/97 +1100, Gavan Schneider wrote:

Thanks for writing this up. I'm addressing your message as a logical
argument. Please forgive the pickiness that follows.

   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.

This is true, but incomplete. Ascii armor allows PGP binary data to be held
or transmitted in any environment that may not be safe to raw binary data.
For example, PGP key servers transmit keys both to and from the server in
ascii armoured blocks. There are other applications that use PGP technology
for authentication, enveloping, etc. and use armor.

Armor is also useful for future applications. I am presently working with
someone who is using the new extension mechanism to build an SPKI-like
authorization system for a network server. They want to use armored blocks.

Lastly, there are systems that use (or would like to use) PGP over systems
that are not the internet. I have given the example of pager systems
before. There are other systems that use telephones, private networks, or
other non-Internet means of data transfer.
   
   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.

Well, this isn't a premise, this is a conclusion. Structurally, it's not
fair to start derivations in your statement of premises of an argument.
Even so, logically, I don't see what chain of reasoning leads one to
conclude this from the previous paragraph.

Furthermore, I disagree with this strongly. MIME is a preferrered way (by
many people) to encode email transmissions. Many people believe it is *the*
preferred way to transmit email. Other people believe that MIME is the best
solution long term, but not at the present date. Still other people don't
like MIME at all. I think we've heard on this list from representatives of
all of these classes of people. Armor has little to do with message
transmission, and everything to do with *OBJECT* (keys, authorizations,
etc.) transmission.

Lastly, for what it's worth, factually there are cases where armored PGP
objects are stored on a disk, in spite of its inefficencies. In any event,
this is an implementor's decision. To forbid armor is to say that there is
no conceivable use for it.
   
   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.

I agree with the first part, but not the last. There is no need to keep
PGP's armor only if all applications that do not want to use raw binary
want to use MIME. If there is one application that falls in the middle,
then there is a need. We may choose to discount this need in the standard,
but the need still exists. Again, pickily, this mixes conclusions with the
premises.
   
   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).

Actually, it increases the message size by 1/3. Three octets of data become
four octets of armor. There is thus a 1 octet overhead for each 3 octets of
actual data for an overhead of 33 1/3%.
   
   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 <[e-mail]>
             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.

No one has ever suggested such a thing, and I would be surprised if anyone
disagreed.
   
   2. Existing mime/base64 encapsulation can replace PGP ascii-armour in the 
   O/PGP standard for transmission of encrypted email over the internet.

I agree completely. For email etc. (Dave Crocker has written some nice
words on how in spite of its acronym, MIME isn't just for mail, so I say
email etc.) MIME is long-term the preferred way to go. Armor itself is
still a preferred way of transmitting OP objects that are not messages.
   
   3. The O/PGP standard will not incur higher implementation cost by using 
   mime/base64, rather it will be using existing code.
   
Actually, PGP's ascii armor uses the same mechanisms as MIME's base 64. The
text describing it was done by Paul Hoffman, who used MIME as a base. So
it's quite easy to do both.

The compromise that I, as editor am working with (with thanks to Ian Brown,
who came up with it) is as follows:

(1) I'm going to remove anything in OP-FORMAT that requires the use of
ascii armor. Following my touchstone that any feature needed for backwards
compatibility is a SHOULD, it'll be a SHOULD.

(2) A description of OP-MIME will be in Michael Elkin's RFC 2015.

(3) We'll leave it to implementors which they prefer to implement and
encourage the use of MIME for messages.

(4) I'm going to restructure the placement the armor discussion in
OP-FORMAT so that it doesn't just spew from section 2, which is supposed to
be an introductory section. It'll get its own chapter towards the back of
the document.

I'm going to digress here and note that in the WG's charter, we are to
strive for "limited backwards compatibility." These are weasel-words. Full
backwards compatibility is desirable, but not possible. When necessary, we
will break backwards compatibility, but we won't do it gratuitously. I
think that encouraging and supporting the use of MIME is a Good Thing, but
forbidding armor is draconian and an overreaction.

	Jon



-----
Jon Callas                                  [e-mail]
Chief Scientist                             555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                   Suite 570
[phone]                              Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)