comment and version fields. [Long]

[Matt]

Robert J. Hansen wrote:
> This is a nonissue.  I can't think of a stronger way to put it.  The
> mutability of the comment and version string is well known and
> clearly documented in the RFC.

It is well known to people who have followed PGP & GPG for years, some
who didn't watch as well will see that this 'flaw' has been patched on
multiple occasions so it is nothing to worry about.

Its in the RFC? Should I quote Arthur Dent about where the plans to
destroy his home were hidden, when such a notice should have been mailed
to his home?

Now I haven't read the OpenPGP RFC, but if it is anything like the other
RFCs that I've looked at (but been unable to read) its language is the
worst possible combination between a lawyer and an engineer. Designed to
kill all interest in the subject before getting down to the subject.

Now I just double checked, but the RFC wasn't included as the
documentation of the last GPG release I received. There are man pages,
which can't be read under windows, and there isn't a manual. I assume if
I got GPG more directly, the manual would be included, but I didn't want
install problems and used ThunderbirdPortable, so perhaps that
distributor removed that documentation.

> If you wish to use a tool, you are responsible for knowing the
> operation of that tool.  

I buy a drill, I know a hand crank or motor turns the bit, and the bit
makes holes. I buy a refrigerator, its job is to keep food cool, I have
now idea how it turns electricity into cooling - and it is not addressed
in the manual, as long as it does its job it doesn't matter. I have a
tool I use to get to work each day, it is called a car. I have the
faintest and most basic understanding of an internal combustion engine,
but have no idea why a muffler reduces pollution so my vehicle passes
emissions tests. I download 7-zip, and use it to compress and decompress
data, do I understand how each compression and decompression work? No.
When I look at the manual, does it tell me how to compress and
decompress by hand? Or does it tell me what non-free programs it makes
obsolete? Even if it started to tell me how to (de)compress, would it
explain the phrase 'dynamic hash table'? I download GPG. Does the manual
explain how each encryption/signing algorithm works? Or does it say it
supports RSA, DH, AES... possibly mentioning limitation of each choice?
 Or does it assume that such details are unimportant as long as the user
gets "gpg -e -r heine file"? Does it say that the comment lines I read
in the (clearsigned) message before running it through GPG are not part
of the signed message, that any third party between the sender and me
could have altered them?

> For every human-factors problem there exist technological solutions
> which are cheap, easy and wrong.

Which explains airport security.  If the RFC had been made to have the
comments above the " --- BEGIN" line, or made it so that it started "---
Begin PGP Message" had comments (and hash) then "--- begin signed" so
that the comments are clearly indicated outside the signed area, this
wouldn't be a problem. Okay, it would be less of a problem, but clearly
showing the signed portion is everything within the beginning and ending
markers (and only that within the markers) is the obvious way people
think.  Instead of an answer along the lines of 'It is not in the
manual, but mentioned in some obscure document surrounded by many
incomprehensible documents says that lines before the first double enter
(normally just "comment" and "hash" lines) are not part of the signed
content, and are meant to be informational to either the OpenPGP client,
or those without a client so they can become informed'.

Fixing the RFC is probably not an option, but being more clear in user
documentation is. Not just the official GnuPG manual, but the OpenPGP
help file in enigmail, and other MUA wrappers.