Re: NEW Data type for certificate selection ?

[Ed Gerck <egerck@xxxxxxxxxxxxxxxxxxx>]

On Tue, 29 Sep 1998, Peter Gutmann wrote:

>Stefan Santesson <stefan@accurata.se> writes:
> 
>>The problem I want to solve is how to pick 1 out of many certificates within
>>an end user application.
> 
>>The problem is how to select the right certificate in every suitable occasion
>>when several certificates is accessed by the same application.
> 
>>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 was something I looked at about 6 months ago while trying to come up with
>a general abstraction for a certificate store.  The problem you face is that
>while it's easy enough to go from certificate -> capabilities, it's very
>difficult to go from capabilities -> certificate.  Put another way, given a
>cert it's easy to answer the query "Can I do X with this", but given a
>collection of certs it's very difficult to answer the query "Which cert is
>required to do X".

Stefan and Peter:

As I understood, Stefan's problem (and examples) was pertinent to
*signing* and *user authentication*. Specifically, this leads to two
different subproblems, which are how to:

1. select which user's private-key should be used in response to a
web *signing* query to be done by the user -- when many private-keys
exist that can be accessed by the same application (eg, web browser),
and

2. select which user public-key certificate should be exported in
response to a web *authentication* query on the user, without
exporting any public-key cert that has sensitive attribute data (eg,
Alice's SSN).

Of course, one can argue that "public-key certs" are just what the
name implies -- public. Hence, sensitive private data such as SSN
should not be stored in them and it is immaterial which public-key
cert you export, securitywise and privacywise. In this line of
thought, if hardpressed one would include a hash of the sensitive
data in the public cert but never the data itself.

In this scenario, subproblem (2) is trivial: select any or all.
Subproblem (1) is not trivial, due to non-repudiation bits and other
qualifiers, but is answered by each application and its user
customization/history -- how it allows signing to be done (eg, if
signing is automatic, if it requires a yes/no decision, if it needs a
passphrase, etc.), how each private-key certificate is stored (eg, in
plain-text, off-line in a SC, encrypted, etc.), and so on.

However, if we accept that there may be valid uses for "public-key
certs" which are not public, with all the security and privacy risks
that may ensue from such usage (such as when Bill trusts Monica that
trusts Linda; or, when Bill cannot revoke a token that was given to
Monica and which unfortunately Monica had to surrender) -- then we
must consider that each "non-public" public-key cert and private-key
will be handled either by a special application or by an interactive
and possibly customized procedure in a general application (eg, a web
browser). Which then answers subproblems (1) and (2) also for
"non-public" public-key certs.

In that, the server application cannot define anything, at most could
suggest a list of CAs (see below), otherwise it would be easy either
to subvert the user's security choices or do a DoS attack. So, the
server must not be allowed to "help" in a decisive way which user
cert *will* be used -- as though it might seem useful at first:
 
>> 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?

but such is not safe.

Regarding Peter's statements above, they seem to address a more
general scenario where also server authentication is involved -- not
just user signing/authentication. 

The server already sends a list of server acceptable CAs, to the
client in SSL, but indeed that does not help much as the server is
gropping in the dark as to what CAs would be acceptable to the user
and what their capabilities might be acceptable to the user at the
time. Which seems to need a deeper look in terms of Peter's two
questions, also as we ask ourselves if the first question (ie, the
relation certificate -> capabilities) is really "easy enough" in a
more general scenario.


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br