Re: NEW Data type for certificate selection ?

[Ed Gerck <egerck@xxxxxxxxxxxxxxxxxxx>]

On Wed, 30 Sep 1998, Stefan Santesson wrote:

>
>Alan, I don't suggest any new certificate extensions
>Ed, I don't want to define any universal criteria for how certificate
>selection SHALL be done or any who decides what for whom, regulations.

Stefan:

Thank you for changing the focus and not requiring (as in your
previous examples) that Alice would have her SSN in a public cert :-)

Your question below fits now the first part of my previous reply,
with a direct solution in SSL, as I present below.

>
>All I want to do is to define some mechanisms that CAN be used, if
>required, by local PKI-related services in order to make it POSSIBLE for
>them to build working services with STANDARD components.
>
>Let me highlight this again and describe a realistic problem relevant to me.
>
>Bank A offer web-based banking applications. This requires the end user to
>get a specific certificate issued by Bank A. The certificate and the
>corresponding private key is processed through the standard web browser of
>the client.
>
>Two certificates and private keys are used in the normal process.
>1) Certificate for SSL (TLS) security
>2) Certificate for non-repudiation protection of Bank transactions.
>
>In addition to these certificates, a specific end-user may be populated
>with several other certificates, un-known to the Bank.
>
>The question is. How can this Bank create a web based application without
>distributing a customized client plug-in for the purpose.


Suppose the Bank signs its own CA certificate and uses that
self-signed CA cert to sign all Bank customer's certs of a certain
class (to make your problem still more realistic), for types (1) and
(2) above for each customer or, (for higher security) with a
different CA cert for each type. 

Of course, that CA cert can be easily registered in a costumer's
browser -- just using the standard menu options. This is justifiable
regarding trust acceptance by a Bank's customer, because the Bank
already exibits trusted functionality to the Bank's customer and the
Bank's CA cert is used in the realm of said trusted functionality in
regard to the customer's browser in cases (1) and (2) of your
example. In other words, it requires no new assumptions, for neither
party.

Now, you have two phases:

1. The customer's browser must automatically authenticate the Bank's
server, using the pre-acquired and trusted public-key Bank CA cert.

 If the Bank's server sends its server cert to the browser in SSL,
 right after the "server hello" message and self-signed by their own
 CA, the browser will be able to automatically verify and accept the
 Bank's server cert -- since it can be checked by the public-key
 contained in the Bank's own self-signed CA cert stored at the
 costumer's browser.

2. The Bank's server must authenticate the required customer's cert,
which is appropriately requested by the Bank's server and is
automatically presented by the customer's browser according to cert
class and cert type, from a larger collection.

 Since the Bank's server is non-anonymous, it can automatically
 request the intended cert from the browser by sending only the DN of
 their own appropriate (ie, for that customer's class) CA cert in the
 "certificate request" message sent from server to browser in SSL --
 which Bank CA cert is exactly the one that signed the required
 customer's cert. Since the Bank certainly did not use their own CA
 cert to sign any other types of certs for the customer, the Bank
 (and the customer) can trust the browser/SSL combination to block
 other customer certs that could have been selected from the
 customer's certificate pool and sent back in response. The server
 can also specify in the "certificate request" message the customer's
 "certificate type" it is requesting, as needed by the Bank -- for
 example in your cases (1) and (2) above. Or, for higher security,
 the Bank can use different CA certs for each type and send their DNs
 accordingly, in each case.


It is important to note that *if* the customer's browser fails to
authenticate the Bank's server, then this will generate a fatal
handshake-failure alert in SSL if the non-authenticated Bank still
tries to go into phase 2 above -- so, the second phase is privacy
protected by the first. Perhaps, this also answers some of your
previous concerns and could allow more sensitive information (from
the customer) to be included in the customer's cert sent to the
server -- but, by all means, not in plain (eg, the SSN itself) if
privacy is really a concern since public client certificates are
stored in general access areas at the server.


Regarding possible problems of using hashes to protect US's SSN
numbers in public certs (as I suggested in my previous reply), I
include below one comentary I received and my reply -- since it may
be also useful in your context:

===============================
>This does not help. American SSN is only 9 digits long and only
>includes digits. It will be trivial to do a dictionary attack in
>this case. This may be true for other pieces of sensitive info as
>well.

The solution is to add "salt" -- like it is done in UNIX passwords.
For example, you can add 50 chars of salt or as many as you want -- a
passphrase. The point here is that since you know the SSN and the
salt, no one else can guess the SSN from a dictionary attack on only
9 digits. Better still, you can change the hash in a new cert and
keep the SSN constant, by changing the salt, so no one can verify
your SSN in a new cert without your cooperation.

Part of this technique is used in the MC-DN token in the
Meta-Certificate Standard being developed by the MCG. See
http://www.mcg.org.br/mcfaq.htm

===============================


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br