summaryrefslogtreecommitdiff
path: root/app/openssl/crypto/store/README
diff options
context:
space:
mode:
authorParménides GV <parmegv@sdf.org>2014-04-09 16:03:55 +0200
committerParménides GV <parmegv@sdf.org>2014-04-09 16:07:34 +0200
commit1684c8f398922065a97e7da4dac4ac6a33cc5218 (patch)
tree76a4b11ae0d7b217c088f3c2b8fc7e69a7b8ae0d /app/openssl/crypto/store/README
parentb9a2b085a8f508cd09e2639c70be845c992c4a3e (diff)
Back to the standard "app" module.
This return to "app" instead of "bitmask_android" is due to this reading: https://developer.android.com/sdk/installing/studio-build.html#projectStructure I'll have to tweak the final apk name in build.gradle.
Diffstat (limited to 'app/openssl/crypto/store/README')
-rw-r--r--app/openssl/crypto/store/README95
1 files changed, 95 insertions, 0 deletions
diff --git a/app/openssl/crypto/store/README b/app/openssl/crypto/store/README
new file mode 100644
index 00000000..966168f6
--- /dev/null
+++ b/app/openssl/crypto/store/README
@@ -0,0 +1,95 @@
+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.