Open Stack

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 ?

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

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


Simo.

-- 
Simo Sorce * Red Hat, Inc * New York