Richard Levitte - VMS Whacker wrote:
>
> From: Bear Giles <[EMAIL PROTECTED]>
>
> bear> The primary key is an opaque string henceforce known as the "alias".
> bear> The plugin may treat this as a primary key, but must not attempt to
> bear> interpret it as a hash, email address, keyid, serial number, etc.
>
> I think I like the idea. Let's see what Dr Genson has to say.
>
Dr Genson, who he?
Well let me mention a variation on the API of the partial work I'd done
which avoids some of the problems I'd noticed with it. I'll stick to the
"search" details for now.
The stuff was called an "object database" OBJDB. An "object" would be a
certificate, CRL, private key or perhaps opaque data objects too.
Each object is a set of attributes. For certificates this would include
an "alias" (a human readable version of the object: e.g. "Steve's
Certificate") key id (opaque binary data intended to allow the private
key to be looked up) subject name, issuer name, serial number, subject
key ID, email address and several others... Private keys would typically
have less info such as just an alias and key id.
In PKCS#11 the "object type" is also an attribute. Not sure whether we
need to do that or not. This would allow us for example to do a single
lookup by key id and get back a mixture of types (certificates and keys)
matching this.
Now a few structures. If we allow object types to be included then we
could use the existing X509_OBJECT to represent the matching structures,
it currently looks like this:
typedef struct x509_object_st
{
/* one of the above types */
int type;
union {
char *ptr;
X509 *x509;
X509_CRL *crl;
EVP_PKEY *pkey;
/* others */
} data;
} X509_OBJECT;
We could also have the attribute use a similar structure:
typedef struct objdb_attr_st
{
/* one of the above types */
int type;
union {
unsigned char *hash;
ASN1_INTEGER *serialNumber;
X509_NAME *subjectName;
X509_NAME *issuerName;
/* Lots more in here */
} data;
} OBJDB_ATTR;
[note: we could alternatively have a single attribute for issuer and
serial number PKCS7_ISSUER_AND_SERIAL_NUMBER]
Now the lookup mechanism. This is done by exact matches of attribute.
Whether we need to handle matches of multiple attributes is debatable.
PKCS#11 can do that though and it isn't too hard to handle. I'll stick
with the more complex multiple attribute stuff and multiple object types
for now...
Each object database would support a triple of lookup functions which
look like this:
int search_init(OBJDB_SEARCH *ctx, STACK_OF(OBJDB_ATTR) *search_attr);
int search_next(OBJDB_SEARCH *ctx, STACK_OF(X509_OBJECT)
**matching_objects, int *count);
int search_final(OBJDB_SEARCH *ctx);
This is effectively an "OpenSSL friendly" variant of the PKCS#11 API. In
outline this is how a search looks at the object database level (the
application would use a friendly API on top of this)...
search_init() is called to intialize a search context.
search_next() is called repeatedly to retrieve succesive matching
objects. "count" is an input/output parameter. The application will set
it to the maximum number of objects to retrieve and the object database
sets it to the number actually retrieved. The object database can return
less matching objects that requested (for example some database specific
imposed limit to avoid having to return a huge number of matching
objects). When count is zero the search is complete.
search_final() is called to terminate the search. This can be done at
any point and need not necessarily be done after retrieving all matching
objects.
This API makes not mention of how the objects are stored, how they are
retrieved and how the search mechanism works. The database can do this
in whatever way it finds convenient whether an in looking in an in
memory database, Berkeley db lookup or hand transribed by Tibetan monks.
Now *internally* the database could do lots of different things. The
OBJDB_SEARCH parameter will have (among other things) database specific
data stored in it.
An in memory database might store all the matching STACK_OF(X509_OBJECT)
structures directly in here and just pop them in search_next() until the
stack is empty.
A different database (to use the earlier API example) could store a
stack of matching keys in here and perform a pop+lookup when search_next
is called.
A huge database might store some kind of "upto" context to avoid having
to satisfy a huge request in one go.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
