Open Stack

On 5/3/13 1:20 PM, "Simo Sorce" <simo at redhat.com> wrote:


>On Fri, 2013-05-03 at 17:50 +0000, Jarret Raim wrote:
>
>> The people using our APIs will be devs. I tend to fall on the side of
>> allowing the app the power and expecting the user to make the correct
>> choices. Having a key expire and orphan data is a valid use case as
>>well.
>> My thought on the expires feature is that once expired, the key is not
>> served at all, encryption of decryption. The key is dead. It may be a
>>flag
>> on whether we allow recovery of expired keys or just delete them as soon
>> as they expire.
>
>What about backups ?

Are you speaking about the backups that Barbican performs? I think this
would be up to the provider. At RAX, I'm thinking of using HA replication
rather than explicit backups, but that's yet to be decided. If the
provider wanted to do hard backups, then the key could be manually
recovered, but as it is expired, the API wouldn't serve it.

My thought here is that the expiration date is a hard datetime. It is not
required to be set, but if it is, they key should essentially
self-destruct once the time has passed. I think it should be up to the
provider what 'self-destructed' means. It could be totally deleted and
unrecoverable, marked as deleted and recoverable via an alternate process
or only existing on backups and recoverable via a manual process.
Something like that.

>
>> We might be able to mitigate this by allowing a per-secret setting on
>> whether we should store a history of key changes. Trades off security
>>for
>> some safety. 
>
>What is the security issue ?

That the key is still recoverable when it has been expired. Again, this
might be provider specific, but if they goal is to completely destroy a
key on expiration, then having a transparent history means that a customer
would need another way to hard delete a key.

>
>> >[
>> >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.
>> 
>> Barbican will be capable of creating a wide variety of keying material.
>> The order abstraction allows us to treat all create requests the same,
>> whether or not they require a longer processing workflow. I think it is
>> also cleaner to not clutter the secret schema with a bunch of
>>provisioning
>> information, hence the concept of storing all provisioning information
>>in
>> an Order schema, that is linked to the secret.
>> 
>> So the current plan is that all key creations would hit the /orders
>> resource to submit an order. They would then poll the order resource
>>until
>> the status is COMPLETE. At that point, the orders resource will have a
>>uri
>> to a valid secret resource that can be retrieved.
>> 
>> If people don't like this idea - speak up now :)
>
>What about supporting messaging and have notifications sent out via
>queue as an alternative to polling ?

The polling methodology is pretty ReSTful so we'll probably support that
first. However, Barican will generate an event stream. We could expose
that in some way if it is valuable.


Jarret