COEN 350 S/MIME
	RFC 821	RFC 822	RFC 1521	RFC 1522	RFC 2045	RFC 2046

Secure / Multipurpose Internet Mail Extension (S/MIME ) is a security enhancement to the MIME e-mail format standard.

MIME

RFC 822 defines a format for text messages that are sent using e-mail. The format adds to the text message an envelope of meta-data, namely the header. The header is separated from the body of the email by a blank line. Each line in the header consists of a keyword such as From, To, Subject, Date. Mime addresses shortcomings in the 822 scheme or the Simple Mail Transfer protocol. For instance

• SMTP cannot transmit executable or other binary data. (But UNIX users can use uuencode / uudecode.)
• SMTP text is confined to the 128 7-bit ASCII characters.
• SMTP servers can limit the size of email.
• Not all SMTP implementations adhere completely to the SMTP standard. Problems are with the treatment of carriage return and linefeeds, truncating or wrapping lines longer than 76 characters, padding lines, and conversion of tab characters.

MIME introduces five new headers.

1. MIME-Version: This field must have a parameters value of 1.0 to indicate that the message conforms to RFC 2045 and 2046.
2. Content-Type: Describes the data contained in the body so that the receiver can pick the appropriate application to represent the data to the user.
3. Content-Transfer-Encoding: Indicates the type of transformation that has been used to represent the body of the message in order to render it amenable to the mail tranport.
4. Content-ID: Used to identify MIME entities.
5. Content-Description: A text description of the object within the body, e.g. audio-data.

The most interesting content-type is the multipart type. The content-type header then contains a parameter, called boundary, that defines the delimiter between body parts. Each boundary starts on a new line and consists of two hyphens followed by the boundary value. The final boundary also has a suffix of two hyphens. Here is an example

From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"

This is the preamble. It is to be ignored, though it
is a handy place for composition agents to include an
explanatory note to non-MIME conformant readers.

--simple boundary

This is implicitly typed plain US-ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii

This is explicitly typed plain US-ASCII text.
It DOES end with a linebreak.

--simple boundary--

This is the epilogue. It is also to be ignored.

MIME has a number of transfer encodings, including 7bit (7b ASCII characters), 8bit (uses the full ASCII character set), binary, quoted-printable (the data is encoded as mostly ASCII text and remains readable by humans), and base64 (encodes 6-bit blocks of input to 8-bit blocks of output, all of which are printable ASCII characters). The base64 mode allows us to encode arbitrary binary data so that intermediate mail agents do not mingle them up.

S/MIME

S/MIME has the same functionality as PGP, that is, it offers the ability to sign and to encrypt messages. In more detail, S/MIM provides:

• Enveloped Data, to apply privacy protection to a message. A sender needs to have access to a public key for each intended message recipient.
• Signed Data, to provide authentication. Only a S/MIME enabled mailer can view this message.
• Clear-signed Data, to provide authentication for users with S/MIME capabilities, but to retain readability other viewers.
• Nesting of signed and encrypted data.

S/MIME incorporates three public-key algorithms, DSS for digital sigantures, Diffie-Hellman for encyrpting session keys, or RSA. It uses SHA1 or MD5 for calculating digests, and three-key triple DES for message encryption. In an ideal situation, a S/MIME sender has a list of preferred decrypting capabilities from an intended recipient, in which case it chooses the best encryption. Otherwise, if the sender has received any previous mail from the intended recipient, it then chooses the same encryption mechanism.

To secure a MIME entity (e.g. the entire message with exception of the RFC 822 header), S/MIME produces a PKCS object. The PKCS object is then treated as the message object and encoded with MIME. Since the result of encryption is typically in binary, it needs to be transferred in a more secure way, such as in base64 mode.

To make an EnvelopedData MIME entity we:

1. generate a pseudo-random session key for either tripleDES or RC2/40 (a weak, exportable encryption).
2. for each recipient, encrypt the session key with the recipients public RSA key.
3. for each recipient, prepare a block known as RecipientInfo that contains the sender's public-key certificate, an identifier for the algorithm used to encrypt the session key, and the encrypted session key.
4. encrypt the message content with the session key.

To recover the encrypted message, the recipient first reconverts the base64 encoding and uses his private key to recover the session key. He uses this key to decrypt the message.

To make an SignedData MIME entity we:

1. select either SHA1 or MD5
2. compute the message digest of the content to be signed
3. encrypt the message digest with the signer's private key
4. prepare the SignerIno block that contains the signer's public key certificate, an identifier of the message digest algorithm, an identifier of the algorithm used to encrypt the message digest, and the encrypted message digest.
5. the whole block is then encoded in to base64 (excluding the RFC 822 header).

Clear signing uses the multipart content type in MIME to transmit body and signature separately. The body needs to be encoded in some way so that it is not altered during transit. The second object, the signature, is sent in base64. Thus, only S/MIME enabled mail readers can use the signature.

Certification

The crux of any secure email system is the distribution of public / private key pairs and certification. S/MIME is very liberal about certification. There are public certifiers, such as Verisign and Thawte that distribute certificates at various levels of security. There are mail products that include certification authorities to be used within an organization. These products can be configured to accept these certificates. Finally, S/MIME is most frequently used without a directory for storing certificates and without a need for trusted certifiers. If Alice wants to sent an encrypted message to Bob, he first has to send her a signed message. The signed message contains his certificate that she accepts into her address book.