Re: Proposal for a KeyStore package

Hi, I'm the co-author and maintainer of Crypt_GPG. If you need any help with creating a GPG provider I'd be glad to help. One thing I notice in the SPI interface is there is no ability to encrypt using multiple recipients. Also, will there be any support for streaming for large files? I like the idea of this package and ideally, it could simplify the Crypt_GPG package to only be a low-level package. Right now, the Crypt_GPG package does some keystore-related tasks like listing, importing and exporting keys. Cheers, Mike On Tue, 2008-08-07 at 15:14 -0500, Steve Wamsley wrote: > 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 > >>> > >> > >> > >> > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php