Subject: RE: NEW Data type for certificate selection ?

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Sep 1998 11:17:31 +0200

Let me clarify my case.

The problem I want to solve is how to pick 1 out of many certificates
within an end user application.

An example.

Alice has 4 certificates. 
1) E-mail based ID with low security 
2) Anonymous cert used for anonymous information services. 
3) Qualified ID-certificate (with her social security number) 
4) VISA SET-certificate.

In this example: 
- Cert 1 and 2 are issued by the same CA and have the same key usage. 
- Cert 3 has key usage non-repudiation

The problem is how to select the right certificate in every suitable
occasion when several certificates is accessed by the same application.
Clearly certificate 4 is no problem since it is used by a separate
application (the SET wallet). So starting the SET wallet application
automatically selects the right certificate.

The problem in this case is not even S/MIME since Alice in this example
only uses certificate 1 in her mail application.

Here the problem is her web-based applications since she use certificate
1,2 and 3 with her browser. So every time she is asked to make a signature
or authenticate via TLS, there is a risk that she will select and export
the wrong certificate. In some cases maybe with a very unpleasant result.

In order to make this user friendly, we have to create a mechanism where a
server can help a client application to select one proper certificate out
of many. In the example there is just 3 certificates to choose among but
what if there is 20 or 30?

The way to do this is, as I would suggest, a 2 step process: 
1) To define a general selective mechanism (such as the X.500 match rule) 
2) Get protocols, script languages and applications to support this.

So this is not about whether selection should be done based on issuer name,
policy OID pr something else, but instead how to define a general
mechanisms which allows customized selection rules within a broad range of
applications and protocols. (In step 2 it is also about how a certificate
can be stored and marked so it won't be exported by any application without
the consent from its owner.)

I still think that The X.500 certificateMatch rule sounds interesting. 
Is there any will to go further in this process? 

To us this is a MAJOR factor for succeeding with a broad CA business case
and the vendors picking up this line will at least be in favor in those
procurements that I'm involved in.

/Stefan

At 09:30 AM 9/27/98 +1000, Alan Lloyd wrote:
>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: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>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                <[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
>-------------------------------------------------------------------
>
>
>
-------------------------------------------------------------------
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: "吉武 淳" <[email-masked]>
Date: Mon, 28 Sep 1998 22:11:42 +0900

Mr. Santesson,

I am not necessarily against you.
I write all of my comments below
because I would like to contribute
to this issue.

> within an end user application.

I think that the real problem is how an application select a suitable
(or correct) certificate when there are multiple applications and
multiple certificates within one PC.

In your example below, S/MIME and another application (say,
application X) hold Cert 1 in common. If we limit the situation to
e-mail applications, this may be easy, but how do we realize it
in a generalized way ?

> the wrong certificate. In some cases maybe with a very unpleasant result.

In this example, I think the client application needs two kinds of
information: which application it is and which level of security it
needs.
Something like "application identifier" and "secuirty level
identifier" are necessary ?
(Honestly speaking, I myself don't like the idea, "let's register
 an object identifier for each application in the world".
Somebody has a good idea for this ?)
Or something like "security context" which can determine
a suitable certificate from among Cert 1, 2, or 3 ?

> what if there is 20 or 30?

This is not limited to that a server can help a client application.
I think there is a case where a client application has to "think"
which certificate it must select for itself. (I mean, without help
from other party.)

I think there is a case where an application has to
select a certificate before it begins to communicate with other
party, especially in the case of peer to peer communication.

> 2) Get protocols, script languages and applications to support this.

Regretfully, the X.500 matching rule doesn't have "application identifer",
"security level identifer",  "security context", or something like that.

I think we have to think a new mechanism outside it, if we don't
modify or enhance it any more.

> the consent from its owner.)

For this purpose, too, I think we need a general mechanism to store
and to select (namely, to manage) certificates within one machine.

> Is there any will to go further in this process?

As I said, I think we have to think a new mechanism outside the X.500
matching rules.

I also think we can use the X.500 matching rules if we have some pieces
of information within a certificate, but that in the situation which we are
thinking, we are trying to select a certificate based on the information
outside the certificate. (This is the one reason that I think of the term,
"security context".)

> procurements that I'm involved in.

(snip)

Actually I have designed a system where there are a few applications
and a few certificates in one PC. And I faced the problem how an
application could select a suitable or correct certificate.
In the end, I used something like "application identifier" for that system.
But as I said, to "register an object identifier for each
application in the world" don't seem to be a good idea.
I have kept seeking a good solution since then ...

Sorry that I can't show a clear and good solution,
but I hope my comments will be of some help.

Regards,

Jun Yoshitake
Mitsubishi Electric Corp.