Certificate Purpose

Hello,

I have a personal email signing certificate from Thawte. The certificate is
issued in my name. The certificate is installed in the system.

If I look at the certificate from Internet Explorer
Options/Content/Certificates, or from MMC, I see two purposes of the
certificate: "proves your identity to a remote computer" and "Protects email
messages".

But if I send an email signed with this certificate, and then look at the
certificate already in the email (sent or received - same thing), I see only
purpose "Protects email messages". Same in Outlook and in Outlook Express.

Why I don't see "proves your identity" purpose in the certificate in email?

--
Vadim Rapp
Polyscience
www.polyscience.com

Because the application is filtering on the actualy application policy used
to sign the email
You use the secure email apploication, you did not use the certificate for
authentication
Brian

"Vadim Rapp" wrote in message
...
Hello,

I have a personal email signing certificate from Thawte. The certificate
is issued in my name. The certificate is installed in the system.

If I look at the certificate from Internet Explorer
Options/Content/Certificates, or from MMC, I see two purposes of the
certificate: "proves your identity to a remote computer" and "Protects
email messages".

But if I send an email signed with this certificate, and then look at the
certificate already in the email (sent or received - same thing), I see
only purpose "Protects email messages". Same in Outlook and in Outlook
Express.

Why I don't see "proves your identity" purpose in the certificate in
email?

--
Vadim Rapp
Polyscience
www.polyscience.com

From: "Brian Komar (MVP)"

| Because the application is filtering on the actualy application policy used
| to sign the email
| You use the secure email apploication, you did not use the certificate for
| authentication
| Brian
|

Aka; non-repudiation

--
Dave
http://www.claymania.com/removal-trojan-adware.html
Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp

BKM Because the application is filtering on the actualy application policy
BKM used to sign the email
BKM You use the secure email apploication, you did not use the certificate
BKM for authentication

I see. I was thinking that the main purpose of singing an email with digital
id is in ensuring that the email has indeed come from the individual who
signed it, kinda digital notarizing. Thawte gives away free certificates
issued to "thawte email user", which only ensure that email message is
intact; but they also have a procedure where you meet their notary, present
your papers, and the notary then enables Thawte to issue you your personal
certificate - already in your name, and having the purpose "proves your
identity" - which is what I did. If this still can't be used in email
communication, then what's the point, and where can it be used is not in
email? how can such certificate be used for authentication?

thanks,
Vadim Rapp

"Vadim Rapp" wrote in :

BKM Because the application is filtering on the actualy application policy
BKM used to sign the email
BKM You use the secure email apploication, you did not use the certificate
BKM for authentication

I see. I was thinking that the main purpose of singing an email with digital
id is in ensuring that the email has indeed come from the individual who
signed it, kinda digital notarizing. Thawte gives away free certificates
issued to "thawte email user", which only ensure that email message is
intact; but they also have a procedure where you meet their notary, present
your papers, and the notary then enables Thawte to issue you your personal
certificate - already in your name, and having the purpose "proves your
identity" - which is what I did. If this still can't be used in email
communication, then what's the point, and where can it be used is not in
email? how can such certificate be used for authentication?

thanks,
Vadim Rapp

So are you saying that you went through their WOT (Web of Trust) notary
scheme to get more information added to your Thawte e-mail cert? All
you get with the initial free one is that it is tied to a particular
e-mail address, not who owns (actually leases) that e-mail address.

When you look at the attributes of your Thawte cert (run certmgr.msc),
do you see anything more of you identified in the cert than just your
e-mail address?

V When you look at the attributes of your Thawte cert (run certmgr.msc),
V do you see anything more of you identified in the cert than just your
V e-mail address?

It's issued in my real name. Without WOT, it would be issued to "email user"
or something like that.

Vadim Rapp

Hello, VanguardLH!
You wrote on Sat, 14 Jun 2008 02:07:45 -0500:

V "Vadim Rapp" wrote in :

BKM Because the application is filtering on the actualy application
BKM policy used to sign the email You use the secure email apploication,
BKM you did not use the certificate for authentication
??
?? I see. I was thinking that the main purpose of singing an email with
?? digital id is in ensuring that the email has indeed come from the
?? individual who signed it, kinda digital notarizing. Thawte gives away
?? free certificates issued to "thawte email user", which only ensure
?? that email message is intact; but they also have a procedure where you
?? meet their notary, present your papers, and the notary then enables
?? Thawte to issue you your personal certificate - already in your name,
?? and having the purpose "proves your identity" - which is what I did.
?? If this still can't be used in email communication, then what's the
?? point, and where can it be used is not in email? how can such
?? certificate be used for authentication?
??
?? thanks,
?? Vadim Rapp

V So are you saying that you went through their WOT (Web of Trust) notary
V scheme to get more information added to your Thawte e-mail cert? All
V you get with the initial free one is that it is tied to a particular
V e-mail address, not who owns (actually leases) that e-mail address.

V When you look at the attributes of your Thawte cert (run certmgr.msc),
V do you see anything more of you identified in the cert than just your
V e-mail address?

With best regards, Vadim Rapp. E-mail:

"Vadim Rapp" wrote in :

V When you look at the attributes of your Thawte cert (run certmgr.msc),
V do you see anything more of you identified in the cert than just your
V e-mail address?

It's issued in my real name. Without WOT, it would be issued to "email user"
or something like that.

Vadim Rapp

Hello, VanguardLH!
You wrote on Sat, 14 Jun 2008 02:07:45 -0500:

V "Vadim Rapp" wrote in :

BKM Because the application is filtering on the actualy application
BKM policy used to sign the email You use the secure email apploication,
BKM you did not use the certificate for authentication
??
?? I see. I was thinking that the main purpose of singing an email with
?? digital id is in ensuring that the email has indeed come from the
?? individual who signed it, kinda digital notarizing. Thawte gives away
?? free certificates issued to "thawte email user", which only ensure
?? that email message is intact; but they also have a procedure where you
?? meet their notary, present your papers, and the notary then enables
?? Thawte to issue you your personal certificate - already in your name,
?? and having the purpose "proves your identity" - which is what I did.
?? If this still can't be used in email communication, then what's the
?? point, and where can it be used is not in email? how can such
?? certificate be used for authentication?
??
?? thanks,
?? Vadim Rapp

V So are you saying that you went through their WOT (Web of Trust) notary
V scheme to get more information added to your Thawte e-mail cert? All
V you get with the initial free one is that it is tied to a particular
V e-mail address, not who owns (actually leases) that e-mail address.

V When you look at the attributes of your Thawte cert (run certmgr.msc),
V do you see anything more of you identified in the cert than just your
V e-mail address?

With best regards, Vadim Rapp. E-mail:

According to
https://www.thawte.com/secure-email/...v-products-wot,
you need to visit enough WOT registrars to accumulate 50 trust points to
get your name added to the cert. Each notary can assign from 10 to 35
points to your trust rating depending on the notaries own trust rating,
so it takes 2, or more, notaries to authenticate your cert (although
their FAQ says 3, or more, notaries are required).

You say that your name is now in the cert. So now your e-mail address
and name are in your cert. This is the extent of proving who you are in
their cert. I have heard of no national or international registry to
which you are added which can trace back to sufficient personal details
to guarantee who you are in your cert used to digitally sign your
e-mails. The WOT registrar may require identification to prove who you
are to them but that information is not recorded in some publicly
available registry for proving your identity. Name and e-mail address
are it, but obviously that really doesn't identify you to anyone who has
never received e-mails from you before and done so repeatedly to
recognize that the content matches up with who you are.

Perhaps a subpoena issued to the WOT registrars to have them divulge
their records regarding what was used as proof of your identity (which
will NOT be in the cert) could be used in court to prove a digitally
signed e-mail came from you (or someone using your computer where the
cert was stored). It is doubtful that YOU can ever prove who signed an
e-mail without that subpoena to get those validation records released.
The e-mail cert binds your digital signature to an e-mail identity.
Adding your name is extra (and a bit superfluous if your name is already
in the username portion of your e-mail address) but does show you were
willing to prove to someone as to who you are (but which is not recorded
in the cert).

You can get free e-mail certs from both Thawte and Comodo. All they
really do is show that you really do own (actually lease) the e-mail
address that you say you own (lease) via a challenge sent to the
professed e-mail address that you own (lease). Getting your name added
is beyond that challenge, shows that some proof was presented to
someone, and gets your name added to your cert. Okay, so now you get an
e-mail from which has the John Doe name in it.
You've never received a John Doe and do not personally know anyone named
John Doe. So what do you know about this John Doe that sent you e-mail?
That they have control over the e-mail account that they used to get the
cert and managed to prove to someone that their name is John Doe for
whatever was used as such evidence to a registrar.

All certs assume trust from a 3rd party rather than trust between the
1st and 2nd parties. Each party assumes the 3rd party is trustworthy.
This 3rd party trust model can be thwarted. From what I've seen of the
paid personal certs, they don't add any more info to the cert. With
their cert, free or paid, you know (or assume):

- The e-mail address to register for the cert is under control of the
person claiming ownership of that e-mail address (but control is not the
same as legal ownership as e-mail accounts have been hacked).

- If the cert owner's name is added, you are trusting the 3rd party's
validation of that owner's identity. The name being added is the
notaries seal that they accepted proof of identity from the professed
owner of the e-mail account.

- That the CA (certificate authority) specified in the cert is who you
expect gets queried to validate the cert and that they can be trusted.


Presumably you are asking about Thawte's freemail certs used to validate
your identity when digitally signing an e-mail. Well, that' is why the
purpose of the cert says "protects e-mail messages". That is the only
purpose of that cert. You are not using a SSL site cert to "prove your
identity to a remote computer". Your computer was never connected to
their computer, so you could never prove it was your computer that
created the message. You sent your e-mail through someone else's mail
host. That's why you need the digital signature to tag along with the
e-mail. You aren't connecting to the recipient's host to prove it was
your computer that connected to them. You could go buy a site cert but
that won't help with digitally signing your e-mails that are delivered
by someone else's host to the recipient's mailbox.

The e-mail cert tries to show some level of proof of who sent the
e-mail, not of the computer used to compose it. In fact, you can
install your e-mail cert on multiple hosts and compose e-mail from each
and digitally sign it. You are attempting to prove you YOU are, not the
host you happened to use to write up the message.

"Vadim Rapp" writes:
I have a personal email signing certificate from Thawte. The certificate is
issued in my name. The certificate is installed in the system.

If I look at the certificate from Internet Explorer
Options/Content/Certificates, or from MMC, I see two purposes of the
certificate: "proves your identity to a remote computer" and "Protects email
messages".

But if I send an email signed with this certificate, and then look at the
certificate already in the email (sent or received - same thing), I see only
purpose "Protects email messages". Same in Outlook and in Outlook Express.

Why I don't see "proves your identity" purpose in the certificate in email?

asymmetric key cryptography is technology where a pair of keys are
required for encoding and decoding (vis-a-vis symmetric key where
the same key is used for both encoding and decoding).

public(/private) key cryptography is business process where one key (of
asymmetric key pair) is kept confidential and never divulged (private
key) and the other key (public) is freely distributed.

digital signature is a business process that provides authentication and
integrity. the hash of a message is encoded with a private
key. subsequently the hash of the message is recalculated and compared
with the "digital signature" hash that has been decoded with the
corresponding public key. if they are equal, then the message is
presumed to not have been modified and was "signed" by the entity in
possession of the specific "private key". If the hashes are not equal,
then the message has been altered (since "signing") and/or originated
from a different entity.

over the years there has been some amount of semantic confusion
involving the terms "digital signature" and "human signature"
.... possibly because they both contain the word "signature". A "human
signature" implies that the person has read, understood, and aggrees,
approves, and/or authorizes what has been signed. A "digital signature"
frequently may be used where a person never even has actually examined
the bits that are digitally signed.

a digital certificate is a business process that is the electronic
analogy to the letters of introduction/credit for first time
communication between two strangers (from sailing ship days and earlier)
.... where the strangers have no direct knowledge of each other and/or
don't have recourse to information sources about the other entity.

there was work on generalized x.509 identity digital certificates nearly
two decades ago. the issues, by the middle 90s, was that most
organizations realized that such identity digital certificates,
represented significant privacy and liability issues. As a result, there
was significant retrenching from the paradigm.

In part, the original scenario was electronic mail from the early 80s,
where somebody dialed up their electronic post office, exchanged email
and then hung up. There could be significant problem authenticating
first time email from total stranger (in this mostly "offline"
environment).

Digital certificates had started out with a fairly narrowly defined
market ... first time communication between strangers w/o direct
knowledge of each other (and/or recourse to information about the other
party). Realizing that generalized identity certificates represented
significant privacy and liability issues, resulted in retrenching and
further narrowing of the target market. The increasing pervasivensss of
the internet and online information sources further narrowed their
target market and usefulness (since there became lots of alternatives
for information about total strangers).

VanguardLH wrote:
You say that your name is now in the cert. So now your e-mail address
and name are in your cert. This is the extent of proving who you are in
their cert. I have heard of no national or international registry to
which you are added which can trace back to sufficient personal details
to guarantee who you are in your cert used to digitally sign your
e-mails. The WOT registrar may require identification to prove who you
are to them but that information is not recorded in some publicly
available registry for proving your identity. Name and e-mail address
are it, but obviously that really doesn't identify you to anyone who has
never received e-mails from you before and done so repeatedly to
recognize that the content matches up with who you are.

Mainly this boils down to:
A name is not an identity. The name can only be used to look up an
identity within a certain identity context. You will run into issues
when names are not unique within the given context.

Perhaps a subpoena issued to the WOT registrars to have them divulge
their records regarding what was used as proof of your identity (which
will NOT be in the cert) could be used in court to prove a digitally
signed e-mail came from you (or someone using your computer where the
cert was stored).

As a WOT digital notary I have to keep paper copies of the identity
cards / passports used when doing the identity check in a face-to-face
meeting for a period of at least 10 years. After this meeting I'm
issuing this user (referenced by e-mail address) the trust points.

All certs assume trust from a 3rd party rather than trust between the
1st and 2nd parties.

Yupp.

But the digital signatures most times are not used without a business
context. So in real life there is already a trust link between 1st and
2nd party (subscriber and relying participant).

Presumably you are asking about Thawte's freemail certs used to validate
your identity when digitally signing an e-mail. Well, that' is why the
purpose of the cert says "protects e-mail messages". That is the only
purpose of that cert. You are not using a SSL site cert to "prove your
identity to a remote computer". Your computer was never connected to
their computer, so you could never prove it was your computer that
created the message.

This is not true since the challenge-response is most times a
combination of both: Challenge is sent via e-mail, response is sent from
the client via HTTP.

Ciao, Michael.

"Michael Ströder" wrote in :

VanguardLH wrote:
Presumably you are asking about Thawte's freemail certs used to validate
your identity when digitally signing an e-mail. Well, that' is why the
purpose of the cert says "protects e-mail messages". That is the only
purpose of that cert. You are not using a SSL site cert to "prove your
identity to a remote computer". Your computer was never connected to
their computer, so you could never prove it was your computer that
created the message.

This is not true since the challenge-response is most times a
combination of both: Challenge is sent via e-mail, response is sent from
the client via HTTP.

The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
used to identify a host, as is, say, an SSL cert used when connecting to
a server host. When the sender composes an e-mail, NOTHING of the host
on which it was composed is in the cert used to sign the e-mail. That
same cert could be used on a completely different host to also compose a
digitally signed e-mail. When the recipient gets a digitally signed
e-mail, nothing in the *cert* will identify on which host the e-mail was
composed.

Are you claiming that a digitally signed e-mail will hash up the value
of the Received headers in the e-mail to identify from which host the
e-mail was composed? If so, that would be impossible because the
Received headers are added AFTER the e-mail was signed because those
headers are added by the mail hosts, not by the user's e-mail client
that signed their e-mail.

A site cert's purpose is different than an e-mail cert's purpose. One
provides identification (via a trusted 3rd party) of the server to which
the user connects an application and the other identifies WHO composed
an e-mail regardless of on which host the e-mail was composed.

From: "VanguardLH"


|
| The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
| used to identify a host, as is, say, an SSL cert used when connecting to
| a server host. When the sender composes an e-mail, NOTHING of the host
| on which it was composed is in the cert used to sign the e-mail. That
| same cert could be used on a completely different host to also compose a
| digitally signed e-mail. When the recipient gets a digitally signed
| e-mail, nothing in the *cert* will identify on which host the e-mail was
| composed.
|

snip

Yes... as I stated earlier for non-repudiation.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp

VanguardLH wrote:
The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
used to identify a host, as is, say, an SSL cert used when connecting to
a server host.

You can also use the cert for SSL client authentication. And if the
e-mail address is used as user name then there's nothing wrong with that
approach.

When the sender composes an e-mail, NOTHING of the host
on which it was composed is in the cert used to sign the e-mail.

It does not need to be.

That
same cert could be used on a completely different host to also compose a
digitally signed e-mail. When the recipient gets a digitally signed
e-mail, nothing in the *cert* will identify on which host the e-mail was
composed.

Yes.

Are you claiming that a digitally signed e-mail will hash up the value
of the Received headers in the e-mail to identify from which host the
e-mail was composed?

No.

BTW: It's not necessary.

Ciao, Michael.

"Michael Ströder" wrote in :

VanguardLH wrote:
The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
used to identify a host, as is, say, an SSL cert used when connecting to
a server host.

You can also use the cert for SSL client authentication. And if the
e-mail address is used as user name then there's nothing wrong with that
approach.

When connecting to a mail server and using SSL, the cert comes from the
server, not from the client. After the SSL session is established, the
client authenticates to the server still using it login credentials.
The SSL simply protected those login credentials from being sniffed from
the network.

For a web browser, the client is not proving who they are. The site is
providing prove of their identity. The client doesn't prove their
identity. You don't need ANY local certs owned by the host owner to
connect to a site that requires an SSL connection. The site's cert is
the only one used. Same when you connect your e-mail client using SSL
to a mail host.

In fact, I've read several security articles where the suggestion is to
immediately delete all locally stored certs on the user's host. That
will NOT bar them from connecting to an SSL-enabled web site or mail
host because it is the host that needs to prove its identity to
establish the connection, not the client.

Please indicate in what scenario a client would need to first obtain a
cert to then use to identify itself to a target web or mail host. I
haven't seen that scenario. I have seen encrypted "keys" used by some
VPN programs to validate that the client's host is allowed to connect to
the corporate network but those keys were not certs. They were keys
generated by the VPN setup, usually by the IT folks, so they know that
key is in their database of allowed outside hosts that are allowed to
connect to their network.

VanguardLH wrote:
Please indicate in what scenario a client would need to first obtain a
cert to then use to identify itself to a target web or mail host.

I started using SSL client authentication (additional to the required
server authentication) for HTTPS, IMAPS and SMTP/STARTTLS with
client-side user certs 10 years ago (using Netscape Communicator 4.5 and
Apache/mod_ssl, stunnel to imapd and postfix with starttls patch).

Most people still prefer passwords but sometimes the security policy
might require stronger authentication.

Another example: My web server (stock Apache with mod_ssl configured)
trusts my customer's PKI. So customer's staff can authenticate at my web
server with their authentication cert. With private keys stored on a
PIN-protected smartcard this is even 2-factor authentication. The user
name is in the subject-DN and is used for authorization. In this
scenario I'm correctly authenticating the user. I'm not interested in
from which host the HTTPS request is coming from.

I haven't seen that scenario.

Well, the fact that you don't know examples does not mean that it's
unfeasible or even unsecure. ;-)

I have seen encrypted "keys" used by some
VPN programs to validate that the client's host is allowed to connect to
the corporate network but those keys were not certs.

You can also use end user certs for client authentication in a VPN. Have
already used this with IPsec/IKE and SSL-based VPNs where appropriate.

Ciao, Michael.

Except that non-repudiation is not needed for client authentication either.
Non-reupdiation is more of an assertion of the measures used to link the
holder of the private key to the subject of the certificate *and* the
mechanisms used to protect that private key to prevent unauthorized access.
Brian

"David H. Lipman" wrote in message
...
From: "VanguardLH"


|
| The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
| used to identify a host, as is, say, an SSL cert used when connecting to
| a server host. When the sender composes an e-mail, NOTHING of the host
| on which it was composed is in the cert used to sign the e-mail. That
| same cert could be used on a completely different host to also compose a
| digitally signed e-mail. When the recipient gets a digitally signed
| e-mail, nothing in the *cert* will identify on which host the e-mail was
| composed.
|

snip

Yes... as I stated earlier for non-repudiation.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp