Other Applications of SSL - Implementing SSL/TLS Using Cryptography and PKI - page 552

impunity to modify the email message itself however they see fi t in order to
route the message from one place to another. If an email gateway feels the need
to Base64-encode an email message, or convert from EBCDIC to ASCII, or change
the charset from ISO-8859-12 to UTF-8, it does so and lets the receiver sort it
all out later. This is a problem for email readers in general, and it's a showstop-
per for email signatures. As a result, both sides must agree rigidly on an email
format and ensure that intervening gateways either don't modify the message
content, or that the receiver can reliably undo whatever arbitrary transformations
may have been applied en route. The easiest way to do this is to apply the most
restrictive set of transformations to the message body, as detailed in RFC 5751.
S/MIME Certifi cate Management
One point that's been glossed over in the discussion so far is that of certifi -
cate management. TLS mandates a rigid means of certifi cate exchange; the cli-
ent opens a connection and negotiates a key exchange, encryption, and MAC
algorithm, and the server immediately responds with a certifi cate. The client
uses that certifi cate to complete a key exchange. S/MIME is similar, but it's a
delayed-reaction variant; the client in this scenario is the sender. In order for the
sender to encrypt the content encryption key, this certifi cate must have been
exchanged beforehand.
While TLS dictates specifi c rules on how this must happen and how this
certifi cate must be validated and even what the certifi cate contains, S/MIME
doesn't care at all; if you can uniquely identify a certifi cate, you can use its public
key to encrypt. Whether you trust the validity of that certifi cate and whether
you believe it belongs to the purported user is up to you. Of course, any email
agent supporting S/MIME goes ahead and checks the trust-path of any certifi cate
and warns you of any discrepancies in order to help you make a trust decision.
As you can see, neither TLS nor S/MIME is a complete solution to the email
security problem — they're both required. TLS ensures that the SMTP server
is really the SMTP server you think you're connecting to and that the SMTP
headers themselves are private and not modifi ed, and S/MIME (or some such
equivalent) is required to ensure privacy of the email from the time it is written
to the time it is received.
Securing Datagram Traffi c
It's somewhat ironic that SSL, originally designed as an add-on to the stateless
HTTP protocol, is itself so stateful. Everything about SSL/TLS requires that a
context be established and maintained from the start of the handshake to the
end of the tear-down; the sequence numbers must be maintained from one