Cryptography Reference
In-Depth Information
(Distinguished Encoding Rules) that X.509 mandates. Indefi nite-length encod-
ings mean that the length is not explicitly output following that tag byte but
instead, the application should read until it encounters two back-to-back 0 bytes.
In other words, you process it just like a null-terminated C string, except that
it has two null terminators instead of one. Parsing indefi nitely encoded ASN.1
values can get somewhat complex because they can be nested inside one another.
The format of the message itself is currently described by RFC 5652, which
refers to it as Cryptographic Message Syntax (CMS), a superset of PKCS #7.
PARSING PKCS #7
Parsing a PKCS #7-formatted S/MIME document is not for the faint of heart;
I'll give an overview here, but if you're interested you should read the offi cial
specifi cation document for complete details.
An S/MIME document body — such as the Base64-encoded .p7m part in
the earlier example — is an ASN.1 sequence of what the specifi cation refers
to as content types . The most interesting case, and probably the most com-
mon, is when there is a single entry of content-type enveloped-data , which
indicates that the content is encrypted. Of course, as you know, if anything
is encrypted, a key is needed to decrypt it, so that key must be exchanged
somehow. As you can probably guess, the key is exchanged using public-key
techniques; if the sender has a certifi cate with the receiver's public RSA key,
the content encryption key is encrypted using that key.
Securing Email When There Are Multiple Recipients
What about emails with multiple recipients? If you've ever sent an email, you
know that there are often many recipients, some on the To: line and some on the
CC: line. If this is the case, only one key is used to encrypt the message content,
but that same key is public-key encrypted multiple times in the recipientInfo
section of the .p7m attachment.
An encrypted S/MIME attachment with two recipients and a DES-encrypted
attachment, then, takes the general form shown in Figure 10-1.
So, if you have the private-key corresponding to one of the public keys, you
decrypt the symmetric key and use it to decrypt the message body. Notice
that the certifi cate is identifi ed by serial number, which is unique to an issuer;
therefore the issuer must also be specifi ed.
NOTE S/MIME also permits Key Agreement (for example, Diffi e-Hellman)
and pre-shared symmetric keys for encryption of the content encryption key.
Very often, when you fi nally decrypt the message body itself, you fi nd that
the contents are yet another S/MIME attachment! This is usually a plaintext
 
Search WWH ::




Custom Search