karlsson(_at_)hal-pc(_dot_)org wrote:
On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote:
Such as:
Version: 1.0.0 non-commercial, upgrade to
Version: 2.0.0-commercial
When the line slicing behaviour is set to (about) column 42.
If I have to set my line width to 42, your mail system is so broken
that I don't need to talk to it. 72 is reasonable, and and one should
expect lines exceeding 80 characters to be wrapped. Anything under 68 is
unreasonably small. I, for example, am using 72 character lines in my
editor (vim).
It does appear to be the consensus that there
is no need or desire to change the ID on this
issue. However, I'm not seeing a lot of real
consideration of the real points here. So I'm
unclear here whether to keep kicking this dying
horse, or perhaps Derik could rule on closing
it?
? I disagree with the above logic on the
following grounds:
OpenPGP is not only used for mail, and in
fact takes great care to be more universally
useful (scan the ID for the word "mail", I
just did!). We here should also strive to
move from the particular to the general, when
looking at examples, and back again.
Security standards are not built on such
considerations of "yours is broken because
I don't like your numbers." Bad software
is certainly built with those sorts of
criteria, but bad software is not what we
are about here. This is about security,
so detail is important.
The offending number chosen was related to
the example; the point remains with an
example of a different number. You pick.
Notwithstanding many peoples' desires to
impose their views of how mail works on
the rest of the world, there are other
mail considerations in the future: PDAs
and phones have smaller screens, for example.
Web mailers and hush-style mailers can be
very unkind to formatters. Chat is replacing
email.... the list goes on - if OpenPGP is
to be based on the email view of the past,
then, we should all stop work on it right
now.
The greatest success comes when multiple
competing implementations communicate with
ease, and without games. Here we have a case
where it is apparently easy to legally create
a correct message that gets turned into a
recipient message of indeterminate legality
by transport.
Fixing this costs nobody much at all [1].
if (!(ptr=(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=' ')
exit(1);
Please make sure you read the entire example.
That doesn't decide which line of the two lines
in the previous text, post-slicing, goes on to
become the dominating one.
The game to play in security programming is to see
if a) we can confuse the other party, and b) we can
create a security breach out of a confusion.
We've shown a). I grant b) is a little harder, as
optional headers aren't supposed to be "used" for
such things. But, who knows what adventurous souls
have in their minds for the future... [2]
iang
[1] I just thought late last night how to breach
b)... Imagine you are a company selling a device
that filters on the headers. Imagine that you
make commercial decisions on the basis of those
headers. (Because that's all you can read.) Then,
an enterprising young chap realises that all he
has to do is to slice the headers, and they are
still human-readable, but they bypass the filtering
of the proxy that handles incoming messages.
marketing reference: NY AG v. WS == 1.3 bn.
[2] the guys
over at PGP Inc might want to rewrite their
comment to be a bit shorter than the ASCII-
Armoured data lines - rule of thumb - and to
change the extra ": " to some other symbol.
If they haven't already done these steps,
I'd be very surprised! Also, they should
reject sliced headers, or suggest we change
the ID on that point. But, no real cost.
GPG might want to detect and warn that the
headers appear corrupted and can be fixed
easily with an editor, rather than silently
bailing on ID strictness.