Certificate Purpose

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

 

[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

 

[David H. Lipman]

From: "Brian Komar (MVP)" <[email protected]>

| 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

 

[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

 

[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 <
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: (e-mail address removed)

 

[Michael Ströder]

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.

 

[David H. Lipman]

From: "VanguardLH" <[email protected]>


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

 

[Michael Ströder]

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]

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.

 

[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

 

[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

 

[Michael Ströder]

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.

 

[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

 

[David H. Lipman]

From: "Brian Komar (MVP)" <[email protected]>

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

 

[Michael Ströder]

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.

Whether it does make sense to use e-mail certs also for client
authentication depends on the security policy in effect and the
enrollment process.

Where do these clients get those certs to authenticate themself to your
site? Aren't they issued by your site?

They were issued by a CA in a well-defined enrollment process with
client-side key generation.

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?

In former times I were the CA (I've implemented the open source solution
was http://www.pyca.de back in 1998). But I see no problem to use my
Thawte e-mail cert also for SSL client authc. Whether one trusts a 3rd
party to properly do the identity checking is a question everybody has
to answer himself.

For me the important key point is the client-side key generation done
over a web interface and the authc done when submitting the
certification service request (CSR) containing my public key.

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.

Sorry, please have a closer look at the cryptographic protocols used.
Checking with a IT guy during lunch is not enough to fully understand
things.

There is no distinction between using the client cert "only for
encryption". There is no proper authorization (here allowing to use a
connection key) without proper authentication.

A cert could be moved to another host.

How to keep private keys secret is another issue. Smartcards usually
help. Well, a user can pass his smartcard to another user telling him
also the PIN. There is no technical solution to prevent this from happening.

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.

Use smartcards which people need all the time (accessing the building,
buying lunch) so it's a loss for them to give it to others.

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.

Is this Cisco VPN? Then SCEP is used. But skilled people can surely
extract the private key from the registry.

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.

I think this is flawed because they are reyling on a host-based private
key which they assume cannot be exported and reimported on another
system. I would not do it like this.

And even then you come into
a special "zone" in their network that has further restrictions than a
host sitting in their building.

This does not have anything to do with PKI and certs. That's network
infrastructure.

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.

Sounds like SCEP.

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.

Well, you need a trusted root CA cert.

I can't just move their trusted cert
to another host to get it to connect to their network

I think you could if having enough skills. ;-)

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.

Well, that might be true in their configuration. But that does not mean
that it's impossible or insecure to do it otherwise.
The key point with X.509 certs is that the user or system is the only
holder of the secret key. The public-key certs have to be validated
against a public-key cert of a (root) CA cert marked trusted.

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

Well, that's another point.

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.

I know that technique. There are off-the-shelf products implementing
something like this.

Ciao, Michael.

 

[Michael Ströder]

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

X509v3 extensions:
X509v3 Subject Alternative Name:
email:<my email address>
X509v3 Basic Constraints: critical
CA:FALSE
[..]
Didn't notice extensions keyUsage and extendedKeyUsage in the above..

Well, obviously these extensions aren't in your cert.

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

Enhanced key usage (property)
Secure Email
Client Authentication

Are you sure you're looking at the *exactly* same cert? If yes, then
welcome to the wonderful world of certificate profiles and the
differences in interpretation of X.509v3 extensions. ;-) It's always
recommended to look up what's actually in a cert and not simply trust a
UI interpreting what's (not) in there.

Whether a particular S/MIME implementation decides that you can use a
cert for S/MIME encryption/signing depends on their interpretation of
keyUsage and extendedKeyUsage.

Therefore I recommend to set in your cert profile for S/MIME certs:
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = emailProtection (OID 1.3.6.1.5.5.7.3.4)

Ciao, Michael.

 

[Michael Ströder]

You sure the recipient is able to connect to the CA to validate the cert
used in your signed e-mails? As I recall from playing around with
e-mail certs maybe a couple years ago, Outlook had problems connecting
to the CA to get an updated copy of their certificate revocation list
(CRL). As I recall, it really wasn't in the method that Outlook used to
retrieve the CRL but in how Thawte implemented it (maybe the path to the
CRL was wrong).

Well, that's a matter of well-planned deployment and how to correctly
set up the infrastructure.

I don't remember the specifics anymore as to why
Outlook couldn't get at Thawte's CRL. Because of this problem, Thawte
had their process to manually download the CRL (don't have the URL to
their FAQ anymore) so you could manually update

Unfortunately Thawte does not add the cRLDistributionPoint extensions to
the e-mail certs. So clients cannot automatically derive where to
retrieve the accompanying CRL for a cert. You have to manually retrieve
it. But once you did the client should be able to memorize the URL of
the CRL and automatically update the CRLs (Mozilla-based clients do this
way).

I don't know if Outlook finally abandoned the CRL scheme

I hope not!

(of checking a
"bad certs" list) with the OSCP scheme; see RFC 2560, ratified in June
1999, http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
which mentions IE7 - but only on Vista - supports OSCP.

In Windows you need a so-called revocation provider for OCSP. Don't know
Vista but until Windows XP you have to buy a third-party software for
OCSP. But OCSP is not the overall solution to the problem. The client
has to locate the OCSP responder, OCSP responder asked has to know about
a particular CA to return the correct revocation status of certs issued
by that CA...

There might not be an obvious
popup alert about the problem. As I recall, the user would see in
Outlook a "quality seal" icon at the right-side of the header pane in
the preview pane when viewing the e-mail. If there was a problem, the
icon looked broken and the user clicked on it to get more information.
No information was given as to what e-mail clients the recipients are
using.

No doubt there are still a lot of deficiencies in the UI of PKI-enabled
applications. I'm fighting with this since 10 years now.

Ciao, Michael.

 

[S. Pidgorny]

G'day:

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.

Sometimes can be used for something better. My original "anyone to
subordinate CA": http://seclists.org/bugtraq/2002/May/0178.html

A variation of the method will work, still, today.

 

[Vadim Rapp]

Besides this thread, I also asked this question to Thawte support. After two
totally irrelevant replies, here's what they say: "Yes, the certificate
proves your identity however that does not need to been included in the
certificate properties. When you send a signed email you are proving your
identity to the recipient. "

It does not seem accurate to me, but maybe I'm wrong?

Vadim Rapp

 

[Paul Adare]

From: "Brian Komar (MVP)" <[email protected]>

| 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

No, and actually non-repudiation is very difficult to implement. A signed
email is more typically signed to indicate that the contents have not been
tampered with during transit than to assert non-repudiation.