Certificate Purpose

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

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

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

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

It does not need to be.

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

Yes.

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

No.

BTW: It's not necessary.

Ciao, Michael.

"Michael Ströder" wrote in <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.

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

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

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

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

> I haven't seen that scenario.

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

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

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

Ciao, Michael.

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

"David H. Lipman" <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> 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

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

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

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