Subject: armour pierced with PGP 8 arrow

From: Ian Grigg <[email-masked]>
Date: Tue, 09 Dec 2003 13:37:00 -0500

It appears that PGP 8 is breaking the spirit and intent
of the ascii armouring format, if not the "letter of the
law."

What it is doing is in essence putting in a Version that
is too long for some mailers' line slicing paramaters.
The result is that people receive this:

Now, reading from the 28th October 2003 draft, it appears
that there is no comment on line length - but there are
comments on the line sanctity and on UTF-8 in the Comment
field that are apropos.

To cut the gordian knot, I propose:

1. changing the comment at the end of p49 to
include a warning on line length:

    ... The
    header lines, therefore, MUST start at the beginning of a line, and
    MUST NOT have text following them on the same line (BEWARE OF
    USING LINES THAT ARE LONG ENOUGH TO BE SLICED BY MAILERS).

(addition in caps...) (as a suggestion only).

2. moving the "Comment" comment out of that
section and/or expanding it to include a
comment about long lines.  Something like:

   Armor Header contents are not strictly defined, so may
   include UTF-8 strings and long lines.

   However, the point of Armoring is to provide a clean
   textual representation that survives transport over
   pernickety systems such as email.  Consequently, if an
   Armor Header includes such things as characters outside
   the range of US-ASCII or too many characters, the Armored
   message may not survive transport.

(At the bottom of page 50.) (because it seems
to apply equally to all armoured headers).

3.  It also seemed plausible to put in 
"rule of thumb" that the line length
of headers should be no longer than
the ascii armoured body line length.

I'm not wedded to any of those, just
thinking out aloud some thoughts on
improving the ID so it best serves.

iang

PS: To compound this, it appears that GPG
(1.2.2) is also rejecting these messages
out of hand.  It would appear that GPG is
in the right here, as there is this strict
rule:

   "OpenPGP should consider improperly formatted Armor Headers to be
    corruption of the ASCII Armor. ..."

(top of page 50).

---

From: Will Price <[email-masked]>
Date: Tue, 9 Dec 2003 17:04:48 -0800

I see no problem here and no need for any change to the draft or a 
product. 66 columns is at least 10 columns shorter than any 
conventional recommended line length. If your mailer wrapped that line, 
it would be almost equally likely to wrap the ASCII armor itself (65 
columns -- 11 less than the OpenPGP limit).

In addition, your claims are patently contrary to the exact words and 
spirit of the draft. Please see section 6.3 where it says: "The encoded 
output stream must be represented in lines of no more than 76 
characters each."

Thus, whatever the problem you are seeing is, and based on observing 
the line length used in your own message on this topic, it appears to 
be related specifically to a low limit somewhere in your configuration, 
it is not a fault of PGP nor the OpenPGP draft.

- - Will

On Dec 9, 2003, at 10:37 AM, Ian Grigg wrote:
> -----BEGIN PGP MESSAGE-----
> Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com
>
> qANQR1DBw04Dxrpn2akpjMkQD/457fxRygbnZG7jAssMb4JuMeXqZdXmMhcGetrm
> ...
> -----END PGP MESSAGE-----
>
>
>

- --
Will Price, VP Engineering
PGP Corporation

---

From: Ian Grigg <[email-masked]>
Date: Tue, 09 Dec 2003 21:45:06 -0500

Will Price wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

I've observed this problem many times, myself, but
it didn't occur in this recent case.

> output stream must be represented in lines of no more than 76

You are correct, I did not see that part, so it
would appear that PGP 8 is within the letter of
the draft.

> it is not a fault of PGP nor the OpenPGP draft.

This behaviour was observed with ordinary people
out there with ordinary mailers, not my own (which
is set to not slice lines at all).  That is, users
failed to communicate because their mailers sliced
the lines.

I make no comment on whether any particular product
should change, rather, I was suggesting that there
be attention brought to the line length issue within
the draft.  As line length in mailers is a moving
target, one can only be general and flexible.

As an aside, in the ascii armoured messages that
my company produces, we used to use the same or a
similar number as various other products (I guess
that would be about 65), but dropped it down to 48
about 2 years back because of continual problem
with mailers.

That's just an old observation, to match the new
one I've just seen in users' setups - if nobody
else has seen those problems then there isn't an
issue.  I don't imagine that two data points are
representative.

iang