Subject: Summary: NEW Data type for certificate selection ?

From: Stefan Santesson <[email-masked]>
Date: Tue, 06 Oct 1998 14:24:25 +0200

All,

I have been asked by some private mailers to sum up this thread.

The problem originally addressed was:

Experiences until today has shown that successful services over Internet
allows users to access these services through their standard internet
software components, in particular e-mail clients and web browsers.
As soon as a service require a custom designed plug-in module to be
installed at the clients computer, a threshold mechanism is introduced that
dramatically limits the probability of success.

Unfortunately X.509 PKI dependent services are many times faced with this
problem. Today many browsers and e-mail clients have to be supplemented
with plug-ins to handle directory access, certificate selection,
non-repudiation services, smart card access etc. Many of these problems
will be solved by emerging protocols and standards (like directory access
and API to cryptographic tokens). However the certificate select problem
will continue to be at least partially unsolved, unless something is done
about it.

----

So one of the most important obstacles to remove before PKI-based security
can be introduced in a large scale, is the problem of certificate
selection, i.e. to solve how one out of several certificates is selected by
standard mechanisms in standard client products without having to rely on
the end users ability to pick the right certificate.

We have seen that on the "link level" there is a solution (in SSL and TLS).
Here the server can communicate to the client a list of CA:s accepted by
the server. Except from this it is total darkness.

At the application level there is no solutions. Java script may be used to
create data forms to be signed by the client, but the process to select a
proper user certificate is not covered.

The possible solution debated here was to define a general select mechanism
in the form of a defined data type, such as the X.500 match rule. This
mechanism could then be introduced into link level protocols as well as
application level command interpreters.

I end this debate with my conclusion that this problem space remains to be
solved. As working for some potential providers of public PKI-based
services over Internet I can only encourage any effort aimed at solving
this in a near future.

/Stefan Santesson

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