Cryptography Reference
In-Depth Information
email with a signature section, so that the recipient can authenticate the sender.
S/M I M E i s a br o ad s p e c i fi cation that permits messages to be signed but not
encrypted and also covers certifi cate management.
OID "Enveloped Data"
Version
Recipient #1
X.500 Name of recipient #1's certificate issuer
Serial # of recipient #1's certificate
OID "RSA"
RSA
pk1
(des-key)
Recipient #2
X.500 Name of recipient #2's certificate issuer
Serial # of recipient #2's certificate
OID RSA
RSA
pk2
(des-key)
OID "Data"
OID "Des Encryption"
IV
DES
des-key
(data)
Figure 10-1:
S/MIME attachment format
Signing email messages can be a bit complex, though. Recall from Chapter 4
that computing a digital signature consists of securely hashing a set of data and
then encrypting it using a public-key encryption algorithm with the private key.
Verifying that same signature involves computing that same hash over the same
data, decrypting the encrypted hash using the public key, and verifying that
they match. It's important to the process that both sides agree on exactly what
the data being hashed is; if even one bit of data changes between the genera-
tion of the signature and the subsequent verifi cation, the signature is rejected.
In the context of TLS, this is not an issue, because the message format is rigidly
defi ned. The data that is signed is the data that is received; it's streamed over
an open, established socket immediately after it's signed
However, email is a different story. The signature is generated sometimes
days before it's verifi ed, and traditionally, email relay systems have assumed
Search WWH ::
Custom Search