Re: NEW Data type for certificate selection ?

["吉武 淳 " <yositake@xxxxxxxxxxxxxxxxxxx>]

Mr. Santesson,

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

Stefan Santesson wrote:

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

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 ?

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

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

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.

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

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.

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

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

> I still think that The X.500 certificateMatch rule sounds interesting.
> 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".)

> 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

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