The Messaging Choice Is Clear

By Dan Backman  In the world of S/MIME (Secure/Multipurpose Internet Mail Extensions) messaging, there are two distinct ways of encoding signed messages. Popularly referred to as ıclearı and ıopaqueı signatures, the ımixed-multipartı versus ısigned-dataı MIME message formats caused compatibility problems in our interoperability testing. While most products default to ıclear-signedı message formatsıwhich are legible regardless of whether the message recipient understands S/MIMEıclear-signing breaks when you use an external MIME processor, such as those in MAPI/SMTP gateways. Clear signed messages are preferred when dealing with non-S/MIME clients, as the signature (signed message digest and digital ID) is carr ied as a standard MIME attachment outside the human-readable message body. In this way, the original message traverses the mail transport, which is followed by an unintelligible block of Base64-encoded S/MIME content. Standard mail clients simply see an attachment called ısmime.p7sı full of illegible text, in addition to the standard message. The primary disadvantage is that the mail gateways are free to translate character sets of the message, or re-encode MIME attachments, thereby altering the messageıs contents. This breaks the digital signature (since the signature guarantees the original contents of the message are unaltered) and often yields false warning of message tampering. Opaque signing is designed to avoid problems caused by invasive mail gateways that can alter message formatting in transit, thus invalidating the signature. By wrapping the entire message in a MIME-encoded block of illegible text (usually Base64-encoded), the entire message is treated as an attachment, and is not altered by gat eways that wish to translate character sets or recode MIME headers. This guarantees the message, but it is illegible (not to be confused with encrypted) to the gateway. It is also illegible to non-S/MIME clients that canıt unwrap the envelope. MAPI/Internet mail gateways are a good example of situations that require opaque signed messages. As MAPI handles messages and attachments in a proprietary (i.e. non-MIME) format, the actual MIME headers are generated at the SMTP gatewayınot in the secure mail client. Therefore, the message signature cannot account for the MIME headersı content when generating the message signature. This automatically invalidates the digital signature as the message passes through the SMTP gateway. Does this mean every Exchange or Outlook S/MIME client is incapable of supporting clear-signed messages? While both Exchange plug-ins we tested suffer from this limitation, OpenSoft claims to have solved the problem in its Windows Messaging client by replacing Microsoft Corp.ıs Intern et Mail Service with its own SMTP gateway. What About Compatibility? While MAPI-based clients are theoretically limited to opaque-signed messages, IMAP, POP and SMTP clients process both message types (but only S/MIME clients can decode opaque-signed messages). Unfortunately, in our tests, several S/MIME clients ran into trouble when trying to decode opaque messages. We uncovered bugs in both Microsoftıs Outlook Express and OpenSoftıs ExpressMail when they attempted to decode opaque-signed S/MIME messages.

O ther Reviews FRADs Make Sound Sacrifices to Get the Data Through By Jeff Newman Secure E-Mail Clients: Not Quite Ready for S/MIME Prime Time. Stay Tuned. By Dan Backman