ietf-openpgp
[Top] [All Lists]

Re: armour pierced with PGP 8 arrow

2003-12-10 10:09:30

Peter Gutmann wrote:

Ian Grigg <iang(_at_)systemics(_dot_)com> writes:

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:

Version: PGP 8.0.2 - not licensed for commercial use:
www.pgp.com

Is it really a line-length issue, or something else like the presence of the
second colon in the line for something that's scanning for <string>:<string>?


Well, the slicing that is occuring is in the
transmission process, in this case, so I am
theorising that this is a line length issue.
(I haven't been able to check this, because
the person sending the dodgy email doesn't
understand what I am asking...  That's the
way it is in userland.)

But you raise a point I hadn't seen, the line
above is badly formatted in a second way, in that
it includes two ": " separators.

Examination of the para in section 6.2, page 50:

    The format of an Armor Header is that of a key-value pair.  A colon
    (':' 0x38) and a single space (0x20) separate the key and value.
    OpenPGP should consider improperly formatted Armor Headers to be
    corruption of the ASCII Armor.  Unknown keys should be reported to
    the user, but OpenPGP should continue to process the message.

indicates that this is not explicitly ruled
against, but I'd say it is implicit stated
that only one separator is permitted.

Or, in the alternate, if two separators are
permitted, then the text should be clarified,
as different parsing strategies will result
in confusion.

Should there be only one ": " or are additionals
permitted in the value and thereafter ignored?

As the ID says "OpenPGP should consider improperly
formatted Armor Headers to be corruption of the
ASCII Armor," I suggest this be explicitly
clarified to improve interworkability.



For a mailer to be unable to handle a 66-char line sounds pretty... broken.


My view is that when it comes to lines, all
mailers seem broken.  But what do I know?

Mostly, this seems to occur when going from
one distinct community to another.  Within
a particular flavour of mailers, they all
understand each other, but across distinct
communities, the mailers have different
ways of dealing with things.

I did a quick straw poll today, and found

   76,72,76,58,72,56,72,72

A few points:

* In communities where they always reply
with full interpolation, and full (audit)
chains of replies, sometimes people set
the width to be very narrow, because they
end up with scores (i.e., 20) series of
replies, which scan across to the right
hand columns.

* from the *same* email, 50-72!  Which
makes me think that this guy had his mailer
set up for proportional text.  Another couple
of emails I wasn't able to work out what was
going on, but inserted lines seemed to be
part of the bug set.

* I've just noticed another thing about
the community stuff - Macs tend to interpret
a trailing space as a continuation character,
and that sometimes works and sometimes doesn't
(I suppose it always works on Macs).

* If you look at my original mail, you will see
that the sliced line I presented was broken,
but in Will Price's reply, it had been repaired,
presumably by his mailer, so in his view, there
was apparently nothing wrong!


iang