On 2001-02-13 15:22:33 +0100, Bodo Moeller wrote:
Again, this is only true only if binary-mode signatures are made
mandatory. If both forms are legal, with the restriction the
senders have to avoid trailing unencoded whitespace (but
recipients are not required to strip any trailing whitespace
before interpreting the message), then it is up to the senders to
decide if they want to use binary-mode signatures as a
countermeasure against addition of whitespace in transit or if
they think that text-mode signatures suffice; and clients will
still be able to verify signatures in a single pass.
This suggestion indeed sounds quite reasonable. Thanks!
Actually, thinking a bit more about this, I think I found one case
in which trailing white space can make a semantic difference. (Which
would be another argument for mandating binary mode, however.)
More precisely, let's have a look at RFC822's grammar:
field = field-name ":" [ field-body ] CRLF
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents = <the ASCII characters making up the
field-body, as defined in the following
sections, and consisting of combinations of
atom, quoted-string, and specials tokens, or
else consisting of texts>
field-body-contents can, in particular, consist entirely of
whitespace.
Example:
^some-tag: some text$
^ $
^ some more text$
^next-tag: ...$
^$
^body$
(^ marks the beginning of the line, $ the end of the line).
I.e., within an RFC822 header (which can in turn be any MIME header,
or a message header within a message/rfc822 body part), a line which
entirely consists of whitespace will be folded, and will - in
paritcular - _not_ separate the header from the body. This
semantics will, of course, change if the MUA removes trailing white
space before the message is sent. To make things still worse, we
can't even call quoted-printable or base64 to the rescue, since
nested encodings are explicitly prohibited.
What do you think - should we really worry about this, or should we
just put a warning into the Security Considerations section of the
text, pointing out that this case can happen and that
implementations should avoid it when sending messages, which is what
I'd suggest?
--
Thomas Roessler <roessler(_at_)does-not-exist(_dot_)org>
pgppD893NoKrY.pgp
Description: PGP signature