Open Stack

John, some comments:

1) What would be the format of the "get" request that returns just the meta data for a secret?

2) Perhaps the "name" field could be optional. Not all keys may be important enough to explicitly  name.

3) "expires" and not serving back a key that has expired ..
     If there are objects in the system encrypted with the key that has become expired, are we implying this is a way
     to burn/bury the object? (assuming we do not care to retrieve the space occupied by said object).
     If not, we need to still serve the key for decryption but no longer for encryption.
     How does one distinguish the two use cases via a simple "get" request?
     May need to "trust" the application that makes calls into key manager specify purpose in the get request.
     
4) I am a little concerned about supporting a "put" on a key ..
    For instance if one changes the secret key string itself, and it was in use, all the objects encrypted with the original
    key would no longer be accessible.  A put that changed key-string or expiration timestamp would need to trigger a work-flow that retrieved all objects encrypted with said key and decrypt, then encrypt with new key.  Time and Compute resources.
 
5) With the "post" requests, need to specify tenant-id if we want to partition the set by tenants.

6) For get https://.../v1/{tenant_id}/orders/
    A filter might be nice .. orders that are pending, or made over the last hour/day/time-range

7) Based on the input I got at the key manager design session, there was a request for the key manager to create symmetric keys.
    A simple 256/512/1024 bit key should not take long to generate (but PKI pairs with a certificate would be a different story).
    Would be nice to support a "create" key.
    https:// ../get/{tenant_id}/secrets/new  or basically one with no uuid
    Default expiration time, format ..
    Or more parameters in the get url

8) the data model for secret needs to be updated with expires, name, mime-type data.
   
9) Common mime-types could be saved in a separate table and the data-model for an encrypted secret just refer to its id.

10) kek-metadata I guess would hold any encryption algorithm and details that the encryption plug-in engine uses.
      Do we need to /want to support more than one plug-in engine?  Given a plain text string, a master key and an encryption algorithm, would any plugin generate the same cipher text? (then a common format for the kek-meta data) ..
A use case would be good for illustration.
      
11) Would the roles referred to here be the same as that in keystone?
     

Regards
Malini

-----Original Message-----
From: John Wood [mailto:john.wood at RACKSPACE.COM] 
Sent: Wednesday, May 01, 2013 1:18 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [barbican] Tech approach blueprint updated

For members interested in the Barbican key management project:

Please review the technical-approach blueprint for Cloud Keep's Barbican project, located here: https://blueprints.launchpad.net/cloudkeep/+spec/baseline-arch

Comments/corrections welcome!

--
John Wood

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev