Re: NEW Data type for certificate selection ?

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

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".
 
Take the example of using a cert for email encryption.  You start by trying a
search for one of the extKeyUsage's which cover email encryption.  If this
fails you try again with a Netscape cert-type.  If that fails you try again
with one of the appropriate keyUsage's.  Finally, if that fails you try again
with no particular usage specified.  This is an incredible pain to do,
especially since each step can involve matching on multiple usage attributes,
possibly with some sort of preferred order for a match.
 
I never really came up with a solution for this, the best I could do was define
a meta-attribute which summarised the various usage types in a single place so
I could perform a single query to match on "name = foo and usage = mail
encryption" (rather than arbitrary numbers of queries with the possibility of
conflicting usages).  The disadvantages of this are that you have to keep
extending it to cover new usage types, and it needs to be stored somewhere
other than the cert itself.  My general idea was to include a kind of TLB
mechanism for cert lookups which would allow (reasonably) fast and simple
matching for frequently-used certs, but this is messy to do in an abstract
manner.  After discussing it with various people I dropped it into the "leave
it for the next release" basket.
 
If anyone has any useful solutions for this (apart from "We should force
everyone to use an X.500 directory, that would solve everything" :-) I'd be
interested in hearing them.
 
Peter.