in message
Everytime I take on a new client I always get a rash of quesitions
that
pertain to viewing my signed e-mail in the preview pane. Is it
possible to
toggle this feature on?
Anyone else have this probelm?
Since you did not mention WHAT warning or error was presented to the
recipient by whatever UNNAMED e-mail client that they use, all I can
do is offer guesses and some background information.
It might mean the recipient cannot contact the CA (certificate
authority that assigned you the certificate) to validate your
signature. The certificate revocation list (CRL) could not be
retrieved. So the e-mail client doesn't show the signed e-mail by
default because it can't guarantee the cert is still good. That
should not prevent the user from seeing the unvalidated signed e-mail
as they should still get a choice to see it, anyway.
You will need to find out WHAT is the warning or error that the
recipient sees when trying to view your digitally signed e-mail. I'm
assuming that the recipient cannot get their e-mail client to connect
to the CA to validate the cert that you used is still valid (i.e., has
not expired or has not been revoked). Outlook isn't very good or
reliable at downloading the CRLs from CAs (i.e., it often, if not
always, fails). Microsoft demands that a cert specify its CA. It's
been a few years since I checked, but the freebie e-mail certs from
Thawte did not specify the CA from where the e-mail client is to
retrieve the CRL. Because the path to the CRL was not specified in
the certificate, automation of retrieving and checking the cert
against the CRL is not possible. Thawte's solution
(
http://tinyurl.com/37dh8n) was to manually download their CRL so
Outlook could use it but it wasn't anything that I was going to bother
with. I'm not going to waste my time downloading CRLs because the CA
can't bother putting in the path to the CRLs in their certs. So the
problem could be with WHOSE certificate you use.
This CRL scheme works similar to cashiers that have lists of bad
checks: they get a check and then look at the "bad" list to see if the
check is on that list and, if so, reject the check. If the cert is in
that CA's CRL then the cert gets rejected by the e-mail client. If
the e-mail client cannot retrieve the CRL then it cannot validate that
the cert is still good. This old CRL scheme doesn't work very well.
Some certs don't specify the path of where to get the CRL list, so the
e-mail client can't download it automatically to check a cert (and
users certainly aren't going to waste time downloading them manually
even if they knew the reason for the warning from their e-mail
client). The CRL had to be updated but it is possible a cert got
revoked before the CRL was updated that day. The cert had to be
checked against a rather huge list of revoked certs (revocation could
be due to expiration, the user revoked their own cert, like when they
had problems and needed a new one, or the cert's owner supplied bogus
info and the CA yanked the cert). The CRL scheme is supposed to get
replaced by the OCSP scheme; see:
http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
http://www.openvalidation.org/whatisocsp/whatindex.htm
Although RFC 2560 was ratified back in 1999, I don't know if any
Outlook version yet supports it. Someone more intimate with Outlook
would have to answer if Outlook 2003 or 2007 yet support OSCP (it
isn't there in Outlook 2002). Maybe Sue Mosher or other
Outlook/Windows MVP might chime in here. I've seen some blurbs
mentioning that Windows Vista will use OCSP for speedier cert status
checking, so apparently cert checking is performed at the OS level
rather than at an application level (although it seems that it would
be the application that initiates the request for the revocation
list). You did not mention WHICH version of Windows that your
recipients use but then you have no control over that, either.
Another reason why they may not be able to read your signed e-mails is
that something altered them. The hash code calculated for your
outbound e-mail along with your cert key does not match what the
recipient got. Some possible reasons is that you send your e-mails
out through a freebie e-mail service that appends their spam
promotional signature onto the end of your e-mails. Your e-mail
client uses its cert to calculate the hash for your e-mail and then
sends it to your sending mail host but then that mail host appends on
its spam signature which adds more content to the body of your e-mail.
Obviously the hash that was calculated did not include the spam
signature that your service added. Likewise, if the user employs any
spam filtering that adds anything into the body of the e-mail,
de-obfuscates URLs, replaces <IMG> tags or modifies their parameters
in HTML-formatted e-mails to block externally linked content, or does
anything else to modify the body of your message then the hash value
won't match to the one generated for what you actually sent them.
Digital signing doesn't only identify who you are. It can also
attempts to let the recipient know that what they received was
unaltered. It depends on how you have your e-mails signed. If you
send in "clear text" mode, they get your cert key to identify you as
the sender but it doesn't allow checking that the message was
delivered unaltered. If you do NOT send in "clear text" mode, you are
using opaque signing which does let the recipient know if the content
got altered.
Note: "clear text" doesn't mean your e-mail is sent in plain-text only
format. ALL e-mail is sent as text but which may be encoded, like for
HTML or RTF. HTML is just text. All attached files, whether
originally binary or not, are converted into a MIME part that is text
using encoding depending on the filetype. If you look at the raw
source of e-mails, they are always just text. "Clear text" signing
means that you are not encoding the body of your message that combines
your cert's public key.
There are two types of signing: opaque and clear-text. For clear-text
signing, the digital signature (cert key) is included as a separate
attachment. The message itself remains as clear-text. You may want
to sign in clear-text mode because some older e-mail clients cannot
decode opaquely signed e-mails. For opaque signing, the message and
the digital signature are encoded (not encrypted) into a single binary
MIME part. Signing a message does not mean it is encrypted.
Encrypting a message does not require a digital signature. So check
your e-mail client's options to see HOW you are signing your e-mails.
http://www.entourage.mvps.org/smime/security_options.html
http://searchexchange.techtarget.com/generic/0,295582,sid43_gci1252037,00.html
(click to skip the ad, if presented; read the S/MIME section)
