Subject: Re: NEW Data type for certificate selection ?

From: Stefan Santesson <[email-masked]>
Date: Wed, 30 Sep 1998 16:43:41 +0200

David,

Thank's for putting this issue in the right focus.

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.

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. Well the Bank can
get far using Java Scripts but it will fail due to the problem that the
end-user may have to select a certificate.
Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION.

I realize that today there is no way to do this without distributing
customized plug-in components to end-users, but I strongly would like to se
options developed that helps getting around this. The current matching
mechanism in SSL and TLS is just not good enough to solve the problem.

So If we instead had a standardized matching rule that could be invoked
into protocols and Java Scripts etc, then the situation would be much more
hopeful for the Bank in my case.

They would then construct a match rule that with high probability would
point out the right end-user certificate and invoke that matching rule both
in the TLS protocol and in the Java Script, forming their secure
transaction application.

It wouldn't have to be perfect, just good enough to handle some 95%+ of the
cases as long as the Bank could detect cases where it didn't work. Then the
non-working cases could be fixed by personal customer service.

I see even more use for this matching rule. It could be used in S/MIME so
specify a preferred encryption certificate for replies to a mail. Of course
this matching rule could be used for X.500 directories as well (that's what
it was built for). MY concern here is however not _where_ the certificates
are stored but, how to select 1 of several known certificates regardless of
where they reside.

Comments?
How do wee proceed ?
Could we have any comments from Microsoft and Netscape ?

/Stefan

At 11:15 AM 9/30/98 -0400, David Horvath wrote:
>--- Message on the SEIS mailing list ([email-masked])
>
>Alan,
>
>While I personally agree that X.500 provides a mature and feature rich
>core to implement certificate repositories, I am having trouble
>understanding some of your assertions as to why X.500 is the answer to
>so many problems.  
>
>It seems to me that the first step for locating certificates in a
>repository is to define the fields in the certificate object that are a
>prerequisite to perform the match.  Matching rules are a good start and
>foster the thought process required to provide a well designed solution.
>Once the matching rules are defined, a protocol such as DAP or LDAP V3
>with extensions may be used to exploit the matching rules.  In some
>cases, clients may choose not to use the matching rules and retrieve all
>certificates.  Perhaps matching rules are not supported by the protocol
>(LDAP V2 or HTTP), therefore the client will collect all the
>certificates and perform the match locally.  This may be even more
>efficient than submitting multiple searches with different variations of
>matching rules.  It could easily be more efficient to submit one search
>and retrieve 10 certificates, then to submit 3 searches with different
>matching rules each time until the required certificate is found.  This
>should be defined by local policies based on performance analysis.  
>
>Once the rules for matching certificates are defined ( and I think X.500
>matching rules are an excellent start ) the distribution model can be
>analyzed.  This is another case where X.500 may be superior to LDAP, but
>unless you have a well planned global infrastructure neither X.500 or
>LDAP can help with the distribution model.
>
>Dave Horvath
>
>Alan Lloyd wrote:
>> 
>> 
>> Snip
>> 
>> ----------
>> From: [email-masked]
>> To: [email-masked]; [email-masked];
>> [email-masked]
>> Sent: 9/29/98 1:01:30 PM
>> Subject: Re: NEW Data type for certificate selection ?
>> 
>> Peter - you went through great lenghts to define the problem with
>> relationships between and searching directory based objects and a
>> distributed information issue and then you say:
>> "
>>  If anyone has any useful solutions for this (apart from "We should
>> force
>> everyone to use an X.500 directory, that would solve everything" :-) I'd
>> be interested in hearing them.
>> 
>> "
>> Oh well - that counts me out. I cannot do solutions - without the
>> solution :-)))
>> regards alan
>> 
>> Peter.
>>
>
>
>----------------- SEIS mailing list ([email-masked])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [email-masked]
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Dave Horvath <[email-masked]>
Date: Wed, 30 Sep 1998 13:20:43 -0400

Stefan,

Agreed, particularly on the point of not creating any new extensions.  

I would add that I firmly believe the matching rule mechanisms should be
compatible with the work being done in X.500 and LDAP.   I would also like to
see X.500 and LDAP join forces and be compatible in the area of matching rules,
I am not sure where LDAP stands at this time.

Dave Horvath

-- 
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  [email-masked]

---

From: Ed Gerck <[email-masked]>
Date: Wed, 30 Sep 1998 15:08:26 -0300 (EST)

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

>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                     [email-masked]
http://novaware.cps.softex.br