I think this book's explanation of how private and public
keys work when encrypting (vice signing) is backwards.
For example, the second paragraph in the section reads: "In order to
view an encrypted message that you send, the recipient must have a copy
of your digital ID with your public key. Similarly, for you to read an
encrypted message from someone else, you need his digital ID."
However, my understanding is that if I send an encrypted message, I
encrypt it using the RECIPIENT'S public key. When he gets it, he decrypts
it using his corresponding private key.
If my understanding is correct, this paragraph should read something along
the following lines: "In order to view an encrypted message that you
send, the recipient decrypts it using his own private key, because you
encrypted it using his public key (for how you got his public key, read
the next paragraph). Similarly, for you to read an encrypted message from
someone else (who encrypted it using your public key), you will decrypt it
using your own private key."
Thus the logic of the encrypted-but-not-signed email process is that
the sender should not need his own digital ID but should need only the
recipient's digital ID (containing the recipient's public key). But my
wife and I ran an experiment, with each of us using Netscape Communitor
4.77's Messenger email component. I sent my wife (who does not have her
own digital ID) a signed but not encrypted email, so she would get my
public key, which her Netscape saved. She could read my email with no
problem, but could not send me an encrypted email in return, even though
in principle she should be able to do so because she had my public key.
So as a practical matter, the book's section 1.2 apparently is
correct in stating that (even for a one-way encrypted but not signed
email), recipient and sender each must have a copy of the other's digital
ID. I guess that this requirement is because Verisign (the only provider
with which I have any experience) wants to encourage everyone to have
everyone else's public key, so the process is set up (either in the
certificate itself or in the software that makes it work, I know not
which) to require both parties to acquire digital IDs. I have no problem
with that mutuality condition, but at least in my understanding it's not
part of the underlying process.
Given my understanding, I did not find any problems with the book's
explanation of signed (vice encrypted) email, in section 12.1, pages
237-239 (although I can't testify about the details for either Outlook
Express or Outlook because I've never used either one).
But for completeness, I'll note that the role of public and private
keys with signed email is differs from their role in encrypted email. As
explained above, the sender encrypts email using the recipient's public
key, and the recipient decrypts the email using the recipient's private
key. But the sender signs email using the sender-signer's private
key, and the the recipient reads the signature using the sender-signer's
public key (contained in the digital ID that is sent along with the
signed email).