RE: NEW Data type for certificate selection ?

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Yes I have views - see my draft lloyd-dir-cert-stat ..

First one needs a fully distributed directory system. 
Then one needs a good set of certificate matching rules in that
directory system to permit the selection of certficate components.
Including rules that can handle multi valued attributes.
Then one needs directory based certficate searches based on  client
business semantics.
And then one needs certficate paths to associated with business
semantics in a trusted way rather than just crypto-cert-issuerId
mechanisms.

I dont see the problem, simply because one has to add something else to
certs and pkis to make them work in a scaleable and useful way - and
that is big directory systems, matching rules that assist the
verification and a business information model that supports the
cert/crypto mechanisms.


I do not believe one will achieve much with to fix this issue without an
operational, business and information perspective.


just thoughts
regards alan



----------
From: Stefan Santesson
To: ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com;
cert-talk@structuredarts.com
Sent: 9/24/98 10:41:23 PM
Subject: NEW Data type for certificate selection ?

All,

During the TLS session in Chicago (IETF meeting) I discussed with Jeff
Weinstein, Netscape, the problem of certificate selection in an
environment
where the client is populated with many similar certificates for
different
purposes.

We concluded that this is a general problem, not only for TLS, but for
S/MIME, Java, Java script, etc, where signing and encryption based on an
X.509 PKI is an option. I also conclude that the current TLS approach,
using Issuer name as selection criteria, is hopelessly insufficient for
the
general case.

In fact we can NEVER claim that we have an X.509 based architecture
ready
for the big market IF WE DON'T SOLVE THIS PROBLEM.

A normal user (I.e grandmother) will never be able to pick the right
certificate by herself, if there is more than 1 to pick.

The question raised here is:

WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD
START.

If we could create a standardized ASN.1 data type with the purpose of
defining the criteria for selecting 1 out of n certificates, then this
could be used as a common base for enhancing TLS, Java, Java script,
S/MIME
etc.

The data type could be communicated from server to client, client to
server, server to server, client to client; I.e in any case where one
party
which to assist another party in selecting an appropriate certificate
for
any purpose (defined by the context).

Do anyone have a better idea.

I think this is a lost problem that has to be fixed, hopefully in a
standardized way.

Comments, suggestions.

/Stefan Santesson
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
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
-------------------------------------------------------------------