Certificate Purpose

V

Vadim Rapp

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
 
B

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

"Vadim Rapp" <nospam@sbcglobal.net> wrote in message
news:eGUbwsXzIHA.3968@TK2MSFTNGP04.phx.gbl...
> 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
>
 
V

Vadim Rapp

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
 
V

VanguardLH

"Vadim Rapp" wrote in <news:#6VsT4ZzIHA.4476@TK2MSFTNGP06.phx.gbl>:

> 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

Vadim Rapp

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 <news:#6VsT4ZzIHA.4476@TK2MSFTNGP06.phx.gbl>:

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: vr@nospam.myrealbox.com
 
V

VanguardLH

"Vadim Rapp" wrote in <news:#cNK0EnzIHA.3968@TK2MSFTNGP04.phx.gbl>:

> 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 <news:#6VsT4ZzIHA.4476@TK2MSFTNGP06.phx.gbl>:
>
> 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: vr@nospam.myrealbox.com

According to
https://www.thawte.com/secure-email/web-of-trust-wot/index.html?click=main-nav-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 JohnDoe@ISPdomain.com 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.
 
A

Anne & Lynn Wheeler

"Vadim Rapp" <nospam@sbcglobal.net> 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).
 
M

Michael Ströder

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.
 
V

VanguardLH

"Michael Ströder" wrote in <news:s5dfi5-ss4.ln1@nb2.stroeder.com>:

> 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.
 
D

David H. Lipman

From: "VanguardLH" <V@nguard.LH>


|
| 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
 
M

Michael Ströder

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.
 
V

VanguardLH

"Michael Ströder" wrote in <news:66fhi5-p16.ln1@nb2.stroeder.com>:

> 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.
 
M

Michael Ströder

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.
 
B

Brian Komar \(MVP\)

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" <DLipman~nospam~@Verizon.Net> wrote in message
news:eBShdnyzIHA.2068@TK2MSFTNGP05.phx.gbl...
> From: "VanguardLH" <V@nguard.LH>
>
>
> |
> | 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
>
>
 
V

Vadim Rapp

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

This is not different from the "paper" situation. Compare: A applies for a
loan. The bank will request the ID.
A presents the ID issued by secretary of state. The bank trusts that
secretary of state has sufficiently verified A's papers when the ID was
given, so with this presumption, the bank assumes that this application is
indeed coming from A.

If the application was done by email, then

secretary of state -> certification authority
driver's license -> certificate

So, if the bank trusts that certification authority has sufficiently
verified A's papers when the certificate was given (Thawte did that in the
process of WOT), then the bank assumes that this email application is indeed
coming from A.


V> Presumably you are asking about Thawte's freemail certs used to validate
V> your identity when digitally signing an e-mail. Well, that' is why the
V> purpose of the cert says "protects e-mail messages". That is the only
V> purpose of that cert.

No as I said, if I look at the certificate in MMC/Certificates, it shows
two purposes: "protects email message" and also "proves your identity to a
remote computer". So the purpose of proving the identity is in the
certificate. The question is why it does not propagate to the receiver of
the email with this certificate, and he does not see that this certificate
also proves the identity.


The only thing I can think of is indeed the fact that the purpose is to
prove identity to remote computer rather than to the recipient and since I
indeed did not connect directly to their computer, this did not occur. But
then, what's the point of Thawte's issuing certificate that is supposed to
confirm my identity, but does not have that purpose and instead is using the
purpose that appears to be irrelevant for this?

Vadim Rapp
 
M

Michael Ströder

Vadim Rapp wrote:
> if I look at the certificate in MMC/Certificates, it shows
> two purposes: "protects email message" and also "proves your identity to a
> remote computer". So the purpose of proving the identity is in the
> certificate. The question is why it does not propagate to the receiver of
> the email with this certificate, and he does not see that this certificate
> also proves the identity.

Well, looking at messages shown by the MMC snap-in is not really a
viable debugging method. You should rather try to look what's exactly
the X.509v3 cert extensions keyUsage and extendedKeyUsage.

Maybe export this cert and let OpenSSL display it:

openssl x509 -in <certfile>.pem -noout -text

or for the binary form

openssl x509 -inform der -in <certfile>.pem -noout -text

Ciao, Michael.
 
V

Vadim Rapp

exported and ran openssl x509 -inform der -in <certfile>.pem -noout -text
it showed the following (with values after the headers)

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1d:92:4a:ba:9c:f0:e9:d9:57:d0:96:21:46:c4:ba:09
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte Personal
Freemail Issuing CA
Validity
Not Before: Jun 10 15:14:43 2008 GMT
Not After : Jun 10 15:14:43 2009 GMT
Subject: SN=Rapp, GN=Vadim, CN=Vadim Rapp/emailAddress=<my email
address>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b1:14:f2:76:b3:c4:fc:19:81:f8:d3:54:80:71:
(...)
b5:e0:34:c4:3d:fd:cf:57:e3:50:3d:9f:c7:e2:43:
42:68:5e:54:50:15:0b:ef:ad
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
email:<my email address>
X509v3 Basic Constraints: critical
CA:FALSE
Signature Algorithm: sha1WithRSAEncryption
70:f1:67:49:41:4d:a6:15:86:0c:5b:59:11:3e:bb:ad:3a:3b:
(...)
9f:4b:3b:5e:06:0e:c3:e7:06:95:00:60:9e:17:05:0d:57:d3:
72:fe
==========================================

Didn't notice extensions keyUsage and extendedKeyUsage in the above..

Looking at the certificate details in MMC at the machine where it's
installed:

Enhanced key usage (property)
Secure Email
Client Authentication


Vadim Rapp


"Michael Ströder" <michael@stroeder.com> wrote in message
news:akdii5-vkn.ln1@nb2.stroeder.com...
> Vadim Rapp wrote:
>> if I look at the certificate in MMC/Certificates, it shows two purposes:
>> "protects email message" and also "proves your identity to a remote
>> computer". So the purpose of proving the identity is in the certificate.
>> The question is why it does not propagate to the receiver of the email
>> with this certificate, and he does not see that this certificate also
>> proves the identity.
>
> Well, looking at messages shown by the MMC snap-in is not really a viable
> debugging method. You should rather try to look what's exactly the X.509v3
> cert extensions keyUsage and extendedKeyUsage.
>
> Maybe export this cert and let OpenSSL display it:
>
> openssl x509 -in <certfile>.pem -noout -text
>
> or for the binary form
>
> openssl x509 -inform der -in <certfile>.pem -noout -text
>
> Ciao, Michael.
 
D

David H. Lipman

From: "Brian Komar (MVP)" <brian.komar@nospam.identit.ca>

| 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
|

And that's what an email certificate is all about.

We aren't talking about a Smart Card here where we have email, encryption and
authentication certificates.

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

VanguardLH

"Michael Ströder" wrote in <news:9q0ii5-u7e.ln1@nb2.stroeder.com>:

> 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.

Yep, after I checked, client authentication can be provided via a
certificate. However, I sincerely doubt that a cert obtained for e-mail
use is usable for a site's authentication of clients that connect to it.

Where do these clients get those certs to authenticate themself to your
site? Aren't they issued by your site? The e-mail certs are coming
from a trusted 3rd party. In your scenario where you want to regulate
who can connect to your server and have them authenticate when to do so,
aren't you the one issuing the cert?

> > 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.

I checked with a guy from IT during lunch. The brief discussion was,
yes, they do issue a cert (they issue it, not some 3rd party). That
cert really only gets used during the encryption phase to protect the
traffic and only partially to verify the client connecting to their
network. A cert could be moved to another host. They don't want just
any host connecting to their corporate network even if their cert is on
that client host. They want their own specific laptops connecting from
the outside (for contractors) or to regulate exactly which desktops (for
their full-time employees) can connect to their network. So they have
you install their VPN software which requires negotiation with an IT rep
to generate a secret key that is encrypted in the registry and which
snapshots that laptop so the secret key isn't usable on another host.
So when you use their VPN software, it needs the secret key to check
that host is allowed to connect to their network along with THEIR cert
to authenticate that host on their network. And even then you come into
a special "zone" in their network that has further restrictions than a
host sitting in their building. I knew about the VPN setup and key
because I had to input the generated key provided by a code generated by
their program on my host, giving it to the IT guy, and getting back
another code. I wasn't aware that the process also connected to their
cert server to get a special trusted one installed on the host that I
must use to connect from outside. I can't just move their trusted cert
to another host to get it to connect to their network although in a much
less restrictive environment that does seem doable and fits with what
you mention.

Still, I really doubt an e-mail cert from a 3rd party is being used in
this situation to validate the client host is authorized to connect to
the corporate network. The IT guy said it must be THEIR cert used on
the client host. Another reason this setup is used (where their cert
gets installed) is something the IT guy alluded to: man-in-the-middle
"attack" but which is their proxy being able to intercept and
interrogate SSL traffic (so any employee's traffic can be investigated
for policy or company violation). They are the CA for the trusted cert
they installed on your host to validate themself as whatever site was
originally targeted for an SSL connect. Since their cert is trusted,
and since they are their own CA, there is no prompt from the web
browser. He didn't want to go into details, and lunchtime was over,
other than to mention they can look at anyone's SSL traffic going
through their network, in or out or internal. He mentioned a name for
this proxy or appliance but I didn't hear it when we were dumping our
lunch trays. I didn't catch everything he said. Tough to get in half a
hour what he was saying and with not wanting to be too specific in their
implementation.
 
You must log in or register to reply here.

Similar threads

H
Smart card logon on windows says "Signing with a smart card isn't supported for your account. For more info, contact your admin".
Replies
0
Views
31
Hanish Gopi
H
H
Smart card logon on windows says "Signing with a smart card isn't supported for your account. For more info, contact your admin".
Replies
0
Views
32
Hanish Gopi
H
H
Smart card logon on windows says "Signing with a smart card isn't supported for your account. For more info, contact your admin".
Replies
0
Views
27
Hanish Gopi
H
L
Question on LDAPS server certificate selection and openssl
Replies
0
Views
44
LSZ_82
L
B
Strong Certificate Issues
Replies
0
Views
35
B_055
B
Back
Top Bottom