mirror of
https://github.com/oxen-io/session-android.git
synced 2024-12-25 09:17:44 +00:00
96 lines
3.4 KiB
Plaintext
96 lines
3.4 KiB
Plaintext
|
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.
|