Certificate Purpose

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

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.

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 Befo 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" wrote in message
...
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.

From: "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
|

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

"Michael Ströder" wrote in :

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.

VanguardLH wrote:
"Michael Ströder" wrote in :

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

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

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.

Vadim Rapp wrote:
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.

VanguardLH wrote:
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_...tatus_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.

G'day:

"VanguardLH" wrote in message
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.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

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

Michael Ströder writes:
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...


http://www.garlic.com/~lynn/2008i.html#80 Certificate Purpose

basically public key operation is "something you have" authentication
.... i.e. business process that keeps the corresponding private key
confidential and never divulged to anybody. verifying digital signature
(created by a specific private key) with the corresponding public key
.... demonstrates the entity has possession of that "private key" (kept
confidential and never divulged to anybody).

as mentioned, digital certificate is the electronic version of the
ancient letters of credit/introduction ... indicating something about
the entity associated with "something you have" authentication for first
time communication between two strangers (who have no other access to
information about each other, either locally and/or in an online
environment).

we had been called in to consult with a small client/server startup that
wanted to do payment transactions on their server and they had invented
this thing called SSL that they wanted to use as part of the process. as
a result we had to do detailed business walkthru of the SSL process as
well as these new operations calling themselves certification
authorities ... and these things they were calling digital certificates.

we had signoff/approval authority on the operation between the server
and this new thing called payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway

and were able to mandate some compensating procedures. We only had
advisory capacity between the servers and clients ... and almost
immediately most deployments violated basic SSL assumptions to meet
necessary security (which continues up to current day).

In those early days, we were getting comments from certain factions that
digital certificates were necessary to bring payment transactions into
the modern age. We observed that the use of digital certificates (with
their offline design point) actually set online payment transactions
back decades (not made them more modern). It was somewhat after a whole
series of those interchanges that saw the advent of work on (rube
goldberg) OCSP ... which has the facade of providing some of the
benefits of online, timely operation while still preserving the archaic
offline digital certificate paradigm. The problem with OCSP is that it
doesn't go the whole way and just make things a real online, timely
operation (and eliminate the facade of needing digital certificates for
operation in offline environment). In a online payment transaction
scenario, not only is it possible to do real-time lookup of
corresponding public key for real-time ("something you have")
authentication, but also do real-time authorization ... looking at
things like current account balance and/or do other analysis based on
current account characteristic and/or account transaction
activity/patterns.

There were other incidental problems trying to apply digital
certificates (specifically) to payment transactions (other than
reverting decades of real real-time, online operation to a archaic
offline paradigm). After we worked on what is comingly referred to
electronic commerce today (including the SSL domain name digital
certificate part) ... there was some number of efforts to apply digital
certificates to payment transactins ... at the same time we had been
called in to work in the x9a10 financial standard working group (that
had been given the requirement to preserve the integrity of the payment
infrastructure for all retail payments). we came up with x9.59 financial
standard which could use digital signature authentication w/o the need
for digital certificates (i.e. use digital signatures in a real online
mode of operation w/o the trying to maintain any fiction of digital
certificates and offline operation).
http://www.garlic.com/~lynn/x959.html#x959

we would periodically ridiculed the digital certificates based efforts
(besides noting that it was attempt to revert the decades of online
operation to an offline paradigm). some of that presumably sparked the
OCSP effort. However, the other thing we noted was that the addition of
digital certificates to payload transaction increased the typical
payload size by a factor of 100* times along with increase in processing
by a factor of 100* times. This was enormous bloat (both payload and
processing) for no incremental value (digital certificates were
redundant and superfluous compared to having public key on file in the
account record ... which turns out was necessary for other purposes
anyway). misc. past references
http://www.garlic.com/~lynn/subpubkey.html#bloat

we also noted that the primary purpose of SSL in the world today is in
the electronic commerce application and used to hide the account number
and transaction details (as a countermeasure to account fraud flavor of
identity theft). we pointed out that the work on x9.59 had also slightly
tweaked the payment transaction paradigm and eliminated the need to
"hide" the transaction details. From the security acronym PAIN

P ... privacy (sometimes CAIN, confidential)
A ... authentication
I ... integrity
N ... non-repudiation

.... in effect, x9.59 substitutes strong authentication and integrity for
privacy as countermeasure to account fraud (flavor of identity theft).
We noted that not only did the x9.59 standard eliminate the major use of
SSL in the world today (hiding the account number and transaction
details) ... but no longer needing to hide that information ... also
eliminates the threats and vulnerability with the majority of the data
breaches that have been in the news (doesn't eliminate the breaches,
just eliminated the ability of the attackers to use the information for
fraudulent purposes).

Vadim Rapp wrote:
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?

Well, naturally language is somewhat ambigous. Since you're hopefully
the only one holding the accompanying private key it's true that *you*
are proving your identity to the recipient. But "identity" is quite a
broad term since one is using a name as address of an identity. But a
name is not an identity

A nice presentation about identity by Dick Hardt:
http://identity20.com/media/OSCON2005/

Ciao, Michael.

"Michael Ströder" wrote in :

VanguardLH wrote:

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

That sounds very familiar. I remember that Outlook couldn't find the
CRL and that either the path was wrong in the cert or Thawte didn't have
it in that path (or in some default path that would be assumed to be
used by CAs as to where to find their CRL). That Thawte's cert doesn't
even specify the path to the CRL would account for why Outlook cannot
find the CRL. So, there is no default path for CRLs from CAs (if not
specified within the cert)?

VanguardLH wrote:
So, there is no default path for CRLs from CAs (if not
specified within the cert)?

Yes, PKIX does not define standard URLs for CRLs. The client
implementation should maintain a cache of the URLs if the user once
downloaded a CRL manually.

Ciao, Michael.

On Fri, 13 Jun 2008 16:22:20 -0400, David H. Lipman wrote:

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

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.

--
Paul Adare
http://www.identit.ca
The determined programmer can write a FORTRAN program in any language.