93a17f79b9
Since we don't use the eay style any more, there's no point tryint to tell emacs to use it. Reviewed-by: Ben Laurie <ben@openssl.org> |
||
---|---|---|
.. | ||
Makefile | ||
README | ||
store.h | ||
str_err.c | ||
str_lib.c | ||
str_locl.h | ||
str_mem.c | ||
str_meth.c |
The STORE type ============== A STORE, as defined in this code section, is really a rather simple thing which stores objects and per-object associations to a number of attributes. What attributes are supported entirely depends on the particular implementation of a STORE. It has some support for generation of certain objects (for example, keys and CRLs). Supported object types ---------------------- For now, the objects that are supported are the following: X.509 certificate X.509 CRL private key public key number arbitrary (application) data The intention is that a STORE should be able to store everything needed by an application that wants a cert/key store, as well as the data a CA might need to store (this includes the serial number counter, which explains the support for numbers). Supported attribute types ------------------------- For now, the following attributes are supported: Friendly Name - the value is a normal C string Key ID - the value is a 160 bit SHA1 hash Issuer Key ID - the value is a 160 bit SHA1 hash Subject Key ID - the value is a 160 bit SHA1 hash Issuer/Serial Hash - the value is a 160 bit SHA1 hash Issuer - the value is a X509_NAME Serial - the value is a BIGNUM Subject - the value is a X509_NAME Certificate Hash - the value is a 160 bit SHA1 hash Email - the value is a normal C string Filename - the value is a normal C string It is expected that these attributes should be enough to support the need from most, if not all, current applications. Applications that need to do certificate verification would typically use Subject Key ID, Issuer/Serial Hash or Subject to look up issuer certificates. S/MIME applications would typically use Email to look up recipient and signer certificates. There's added support for combined sets of attributes to search for, with the special OR attribute. Supported basic functionality ----------------------------- The functions that are supported through the STORE type are these: generate_object - for example to generate keys and CRLs get_object - to look up one object NOTE: this function is really rather redundant and probably of lesser usage than the list functions store_object - store an object and the attributes associated with it modify_object - modify the attributes associated with a specific object revoke_object - revoke an object NOTE: this only marks an object as invalid, it doesn't remove the object from the database delete_object - remove an object from the database list_object - list objects associated with a given set of attributes NOTE: this is really four functions: list_start, list_next, list_end and list_endp update_store - update the internal data of the store lock_store - lock the store unlock_store - unlock the store The list functions need some extra explanation: list_start is used to set up a lookup. That's where the attributes to use in the search are set up. It returns a search context. list_next returns the next object searched for. list_end closes the search. list_endp is used to check if we have reached the end. A few words on the store functions as well: update_store is typically used by a CA application to update the internal structure of a database. This may for example involve automatic removal of expired certificates. lock_store and unlock_store are used for locking a store to allow exclusive writes.