Certificate Purpose

VanguardLH wrote:
> "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).
>
> 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" <V@nguard.LH> 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 <michael@stroeder.com> 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...

re:
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 <news:ghaki5-t1v.ln1@nb2.stroeder.com>:

> 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)" <brian.komar@nospam.identit.ca>
>
>| 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.