Re: gnupg/mailing list validation error

[Albrecht Dreß <albrecht dress arcor de>]

Am 03.03.04 16:27 schrieb(en) Kacper Wysocki:
> As expected, I have verified that indeed other mailers do *not* fill  
> tabs to spaces and people on my mailing list simply never use tabs :-)
> 
> An RFC reference would be nice from you email guru's, but don't worry
> about it, it's not a problem google can't solve.

Well, I'm for sure no guru, but maybe I can give you some helpful  
information anyway... Basically a mta or list processor changing a single  
bit in the contents will break the signature - with a few exceptions. In  
short, changing a tab which is not at the end of the line to spaces or  
vice versa does *always* change the contents in a way that the signature  
will be broken.

If you used a multipart signed message, the wisdom of RFC 3156 (see  
http://www.faqs.org/rfcs/rfc3156.html) deals with trailing whitespaces  
only (I hope it's not a trailing tab, isn't it? Note that to be on the  
safe side Balsa enforces quoted printable if you send signed messages even  
if you stated something else in the prefs):

[~~~long quote from rfc 3156 starts here~~~]
3.  Content-Transfer-Encoding restrictions

   Multipart/signed and multipart/encrypted are to be treated by agents
   as opaque, meaning that the data is not to be altered in any way [2],
   [7].  However, many existing mail gateways will detect if the next
   hop does not support MIME or 8-bit data and perform conversion to
   either Quoted-Printable or Base64.  This presents serious problems
   for multipart/signed, in particular, where the signature is
   invalidated when such an operation occurs.  For this reason all data
   signed according to this protocol MUST be constrained to 7 bits (8-
   bit data MUST be encoded using either Quoted-Printable or Base64).
   Note that this also includes the case where a signed object is also
   encrypted (see section 6).  This restriction will increase the
   likelihood that the signature will be valid upon receipt.

   Additionally, implementations MUST make sure that no trailing
   whitespace is present after the MIME encoding has been applied.
      Note: In most cases, trailing whitespace can either be removed, or
      protected by applying an appropriate content-transfer-encoding.
      However, special care must be taken when any header lines - either
      in MIME entity headers, or in embedded RFC 822 headers - are
      present which only consist of whitespace: Such lines must be
      removed entirely, since replacing them by empty lines would turn
      them into header delimiters, and change the semantics of the
      message.  The restrictions on whitespace are necessary in order to
      make the hash calculated invariant under the text and binary mode
      signature mechanisms provided by OpenPGP [1].  Also, they help to
      avoid compatibility problems with PGP implementations which
      predate the OpenPGP specification.
[~~~end of long quote from rfc 3156~~~]

RFC 2480 (reference 7 above, see http://www.faqs.org/rfcs/rfc2480.html),  
dealing with gateways and mime security multiparts says in section 4:

[~~~long quote from rfc 2480 starts here~~~]
[...] In particular, gateways

    (1)   MUST provide the ability to tunnel multipart/signed and
          multipart/encrypted objects as monolithic entities if there is
          any chance whatsoever that MIME capabilities exist on the
          non-MIME side of the gateway. No changes to content of the
          multipart are permitted, even when the content is itself a
          composite MIME object.
[~~end of long quote from rfc 2480~~~]

Now a list processor is not a mail gateway, but you could argue that the  
same rules sould also apply here.

If you sent an OpenPGP message (RFC 2440, see  
http://www.faqs.org/rfcs/rfc2440.html), things are unfortunately less  
clear as RFC 2440 unlike RFC 3156 does not state that data must be encoded  
properly. However, Balsa enforces quoted-printable for such text parts to  
avoid problems. It says, however, that trailing whitespaces are ignored in  
signature calculations (section 7.1):

[...]
   Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
   any line is ignored when the cleartext signature is calculated.

Is this enough ammunition for you to convince people to leave your tabs
intact?

Cheers,

	Albrecht.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
       Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
_________________________________________________________________________

PGP signature