Open Stack

Hello Malini,

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

An example GET for a secret is on the wiki in the 'Secrets Resource'.  As per another thread though, the 'content_types' field might still be refined. 

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

That is probably true...the UUID/href to the secret is probably the most interesting part, with the name an optional convenient human-readable tag for it.


[
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.
]

Hmm...that make sense. Maybe we could instead consider an approach where a notification is sent to a contact list when secrets are expired?

[
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.
]

This might be another 'trust the application' situation, but could certainly leave a customer in a pickle if they didn't do this correctly. Immutable keys would be safer from that perspective...any other community thoughts here?

[
5) With the "post" requests, need to specify tenant-id if we want to partition the set by tenants.
]

The tenant-id is part of URI of the request...is that what you mean here though?


[
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
]

Query parameters could certainly be included, in addition to paging/navigating long lists.


[
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
]

A POST to secrets with the 'plain-text' omitted could do a similar thing (i.e. have Barbican create the secret). However, this behavior would be inconsistent with other secret types (such as SSL certs), that have long-running asynchronous work flows to generate them.  The orders -> create-secret flow, though a bit clunky for quick-gen secrets, would at least be consistent. Yet another thing to query the community about.


[
8) the data model for secret needs to be updated with expires, name, mime-type data.
]

Thanks.

[
9) Common mime-types could be saved in a separate table and the data-model for an encrypted secret just refer to its id.
]

Makes sense.

[
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.
]

The intent of the kek-metadata is to store whatever info is needed to be able to decrypt the data later.  Barbican would be agnostic to this data and would simply store it. Only the plugin implementation would know how to utilize the metadata on the decrypt once Barbican hands this metadata and the encrypted cypher text back to the plugin to decrypt it.  

If we intend to support more than one plugin type for a given type of secret, then we would probably also need to store info about what plugin was used to encrypt/decrypt the data.


[
11) Would the roles referred to here be the same as that in keystone?
]

They might be, that needs to be fleshed out more over time.

Thanks,
John


-----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