Problem with personal certificates

  • Thread starter Thread starter N J Jelley
  • Start date Start date
N

N J Jelley

Hi,

I have a personal Thawte certificate installed in Outlook 2000.

I am getting an error when trying to open an email I sent to myself as a
test.

It says 'Can't open this item. Your Digital ID name cannot be found by the
underlying security system.'

What on earth does that mean?

How do I resolve this?

Thanks,

Neil
 
I actually have two - one each for two email addresses.

They are both installed, but the one for my default address is selected.

Do I have to match up the encryption algorithms with the certificate specs?
Can I uninstall and re-install them? Will this restore the default settings
for them?

Neil
 
N J Jelley said:
Hi,

I have a personal Thawte certificate installed in Outlook 2000.

I am getting an error when trying to open an email I sent to myself
as a test.

It says 'Can't open this item. Your Digital ID name cannot be found
by the underlying security system.'

What on earth does that mean?

How do I resolve this?

Thanks,

Neil

Although you have *installed* the personal freemail certificate, you
need the public key of the security certificate from the person to whom
you are going to *send* e-mail to. That is, I want to encrypt a file
that I want only Joe to receive (and the reason I encrypted it). Joe
must FIRST send me a digitally signed e-mail so I can save his public
key in an entry in my Contacts folder. Then when I send an encrypted
e-mail to him, that e-mail will use his public key to encrypt the file
and only he can then decrypt it using his private key. It guarantees
that only Joe can decrypt the e-mail because only he has the private key
that matches with his public key that was used to do the encrypting.

You can always digitally sign your e-mail using your public key from
your security certificate. That gives the recipient your public key so
they could then encrypt an e-mail using your public key which you would
then receive and then decrypt using your always protected private key.
You can digitally sign any outbound e-mails but you cannot encrypt them
without the *other* person's public key, even if the recipient is you.

So if you want to sent a test e-mail to yourself, you must be listed in
your Contacts or other contacts-type folder (that has been included in
the Outlook Address Book) so your public key is stored there. Then an
e-mail addressed (to yourself) will use your public key to encrypt the
e-mail. You then receive the encrypted e-mail and use your private key
to decrypt it. Although you are both the send and recipient, you have
to behave as you-as-sender is a different person than you-as-recipient;
i.e., you have to go through the same process as if you were sending
e-mail to someone else.

Person_A sends a digitally signed e-mail which includes their public key
to Person_B. Person_B can then encrypt a message using Person_A's
public key and send that encrypted e-mail to Person_A. Person_A
receives the encrypted e-mail and uses their private key to decrypt the
file.

In your test case, you were Person_A and Person_B but you had no record
in your Contacts that had your security certificate to make your public
key available (for your own use in this looped e-mail test).

Beware that there is a big deficiency in the defaults used by Outlook
and Outlook Express when using security certificates to digitally sign
e-mails. Outlook's default is to send clear text signed e-mails.
Outlook Express' default is not encode e-mails (which is NOT the same as
encrypting them; it means the digital signature has not encoded the
content of the message). That is, the message is sent as a separate
part than the signature (i.e., it is text sent "in the clear" even if it
is HTML content). The recipient only know that YOU were the originator
of the e-mail but there is no guarantee that the content of the e-mail
has not been altered. If you disable the "send as clear text signed"
option in Outlook or enable the "encode" option in Outlook Express then
you send opaque signed messages. That is, the signature envelopes (and
encodes) the content of the message. If the content is altered in any
way, the recipient will be alerted that what you sent is not what they
received. However, from what I've heard regarding opaque signed
e-mails, there are still mail servers and gateways that will mutilate
opaque signed e-mails because they will do some crap like trying to add
footers to the e-mails (i.e., you are using a mail service that wants to
add spam/promotional signatures or info to the end of your messages).
Some e-mail clients don't know how to handle opaque signed e-mails and
instead will show the entire e-mail as an attachment (instead of just
the digital signature portion). Almost every webmail provider I've
tried doesn't know how to handle opaque signed e-mails, so all the
recipient sees is a blank message with one attachment. With clear text
signed e-mails, the recipient will see your message and the digital
signature is an attachment. But with clear text signed e-mails, you
cannot guarantee what you said to them is what they actually get to
read.

So digital signatures don't seem to be a great security measure anyway.
You can tell the recipient that the e-mail really originated from you
but you cannot guarantee that what they read is what you wrote. Or you
could envelope your message with the digital signature (opaque) to
ensure they see what you wrote and hope that no mail server or gateway
mangles your e-mail, that the recipient uses an e-mail client capable of
reading opaque signed e-mails, and that they don't use a webmail
provider. I don't see much point in universally digitally signing all
my outbound e-mails. The only time it is useful is when you know that
Joe wants to send you a sensitive e-mail and/or file attached to an
e-mail so you send him a digitally signed e-mail so he can use your
public key to encrypt his sensitive e-mail so only you can decrypt it
with your private key. So although I have Thawte freemail certificates,
too, I don't set Outlook or OE to always sign my outbound e-mails.
Instead I use the options when composing a new e-mail to sign that
outbound message when it is appropriate. If you visit newsgroups, as
you have here, you'll find some users won't be able to read your posts;
they will look blank with attachments (at least, that's what happens for
use OE users that do not have a PGP plug-in and some *nix user digitally
signs their post using PGP).

Those who digitally sign all their outbound e-mails but send the message
as clear text don't usually realize that they've guaranteed nothing
about the content of their message. It's like sending you a letter via
postal mail with my name on the envelope as the sender but someone else
possibly removing my letter and sliding in their own. Yeah, you know
that I originally sent the letter but you don't know if the letter you
received is the one that I sent. You could try sending opaque signed
e-mails to let recipients know it came from you and that your message
did not get altered, and see if they mostly arrive unmangled. How many
times in your life has postal mail sitting in your mailbox after it got
delivered been altered to make you think the sender said something
different than they did? Same goes for e-mail. Unless there is a real
need to opaque sign or encrypt your e-mails, which is usually on a
per-mail basis and not universally, you only generate more headaches for
your recipients and yourself. What also isn't mentioned that almost no
users ever validate a security certificate. I get an e-mail from
Whackoff that pretends to be from Joe which is digitally signed (by
Whackoff) so that I can use the public key from the digital signature to
return an encrypted e-mail with a highly sensitive document or message,
and now Whackoff gets the encrypted e-mail and decrypts it. I would
have to first inspect the signature attached to the e-mail purportedly
from Joe, inspect the certificate details to check for any anomalies,
and then I would have to somehow validate that certificate. Validation
is the hard part. Supposedly the program is to use Certificate
Revocation Lists (CRLs) from an CA (Certificate Authority) that you
trust but that requires you be online to do that check and I haven't
found it to work in Outlook; instead I get a yellow triangle saying the
CRL could not be checked to see if the certificate is still valid. So
instead I am expected to hunt around on the CA's web site looking for a
downloadable file containing the CRL and then I have to check the serial
number of the certificate in the e-mail against the serial numbers in
the CRL. If there is a match then that certificate has been revoked.
That's like the really old days when stores had to use blacklists to
check which credit cards were stolen. Users are NOT going to go through
all that effort and will usually assume the certificate is valid and it
is for the person they think it is for. This security was supposed to
eliminate the need to trust the sender and provide authentication that
they are who they say they are by referencing a separate but trusted
authority. Doesn't work in practice, especially with freemail
certificates which never require any real authentication of the
certificate owner, and because recipients have no easy way to validate
the certificate, anyway. For something that is supposed to provide
security - which implies lack of trust - there's too much trust going on
with these.
 
What a thorough reply.

I have printed it, and will study it with interest.

Thankyou.

Neil
 
Back
Top