Open Stack

Thank you Simo for chimming in!

1) key expiration -- if no distinction support will be provided for use, that is encrypt versus decrypt, at the very least the expired key should be archived/backed-up.

2) polling and notifications are both overheads. For ease of use, making the key manager more appealing,  symmetric key create should be a fast-pass (why else do we bother to have fast-pass tags for highway toll boths?)

Malini
-----Original Message-----
From: Simo Sorce [mailto:simo at redhat.com] 
Sent: Friday, May 03, 2013 11:21 AM
To: OpenStack Development Mailing List
Cc: Bhandaru, Malini K
Subject: Re: [openstack-dev] [barbican] Tech approach blueprint updated

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