Re: Proposal for a KeyStore package

I created another release, v0.1.8dev, to address more issues/suggestions. This release addresses the following: - Removed the concept of a "provider", so the Provider class is no longer necessary - Changed KeyStore::getInstance(...) to dynamically load the appropriate implementation - Change the KeyStore to NOT be a singleton - this is not necessary - Added layer of abstraction between KeyStore and key data so that meta-data can be persisted with the keys/certificates (i.e., algorithm, key size, etc.) Still more work to come. I look forward to feedback. The release can be downloaded from http://phpkeystore.org/download/Crypt_KeyStore-current.tgz. Documentation and source also available at http://phpkeystore.org. By the way, SPI stands for Service Provider Interface. The concept of the KeyStore is that an abstract, pluggable interface API is available for providers to implement with different underlying mechanisms (i.e., mcrypt, mhash, OpenSLL, GPG, etc.). The KeyStore class in itself does not do any cryptographic functions. The SPI implementation is responsible for that. That is the purpose of the classes in the SPI directory. Thanks, Steve Wamsley Steve Wamsley wrote:

Thanks for your review and comments. I made the following changes for a new development release today: - Changed package name to Crypt_KeyStore and re-packaged the classes - Removed the "@" from the require_once statements - Replaced define with const - Added dependencies to package.xml - Replaced logging with PEAR::Log I will continue through the list and post updates. Philippe Jausions wrote:

Hi Steve, Couple of comments on the form (most minor stuff, easy to fix if you move forward with your proposal: - Package name should probably be Crypt_KeyStore - Classes should be Crypt_KeyStore_Entry, Crypt_KeyStore_Exception, etc... and files should be placed accordingly in Crypt/KeyStore/Entry.php, Crypt/KeyStore/Exception.php, etc... - To reflect hierarchy, I suggest to use Crypt_KeyStore_Entry_Base, Crypt_KeyStore_Entry_PrivateKey, and so on for all the "Entry" classes - Do not prefix require_once with "@" - Use class "const" instead of define() global constants - Missing dependencies declaration in package.xml for MHash, OpenSSL and MCrypt extensions. - Interfaces need to be identified as such in their name. For instance Crypt_KeyStore_EntryInterface (or Crypt_KeyStore_IEntry). AFAIK there is no standard nor convention in PEAR for interface naming. Otherwise: - Use PEAR::Log for logging facility (don't reinvent the wheel, especially when it introduces an "echo") - What is the "Provider" actually for? - What does SPI in the class names stand for? - The default key store doesn't seem easily "extendable" with all the private members. - How does one use a key store different from KeyStore_SPI_DefaultKeyStore? getInstance() doesn't currently allow for overriding it. More critical: - There seems to have too many specialized method in KeyStore base class that don't necessarily belong there. For instance all the CSR, certificate-stuff don't apply to symmetrical keys, or other types of asymmetrical keys. How about verify() with symmetrical keys? - What do KeyStore::DEFAULT_KEYSTORE_TYPE and "$type" in KeyStore::getInstance() refer to? Don't seem to really be used anywhere as a "type" per-se. - There should be support for PGP/GnuPG keys. - Mostly important: I'd like to see the secret key to be more self-contained, with algorithm information. - There's probably a need for a better way to provide a storage back-end independently to the key types being stored. So encryption functions would be decoupled from storage functions (i.e. file vs. database storage, and PECL extension vs. PHP implementation of cryptographic functions) Overall seems like a good idea, but the API needs some cleaning up and re-organizing. -Philippe Steve Wamsley wrote:

This is my first PEAR package proposal, so please excuse if I'm doing this wrong. I already submitted the proposal at http://pear.php.net/pepr/. I thought I'd also drop the proposal on this mailing list. What I propose is a KeyStore package under the Encryption category. The KeyStore library will be used to manage cryptographic keys and perform cryptographic functionality (encrypt, decrypt, sign, verify, etc.). See the package overview at http://phpkeystore.org for more information. Thanks, and I look forward to the feedback. Steve Wamsley swamsley@gmail.com http://ne0phyte.com