| Index: openssl/crypto/store/README
 | 
| diff --git a/openssl/crypto/store/README b/openssl/crypto/store/README
 | 
| deleted file mode 100644
 | 
| index 966168f6a5a811c87c8bf829f323179f71130b15..0000000000000000000000000000000000000000
 | 
| --- a/openssl/crypto/store/README
 | 
| +++ /dev/null
 | 
| @@ -1,95 +0,0 @@
 | 
| -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.
 | 
| 
 |