Open Stack

Thanks for the input Nate.  Some comments below please:

[
> We propose changing from 'orders' to 'requests'...so to request that Barbican
> create a new secret (or start a process to generate a secret) clients would
> issue a 'request'. This seems more natural, and a bit less overused than
> 'orders'.

I think request sounds more overused than orders. I was not that thrilled with
orders, but I do like it more than request. What about something like
secretfactory, secretgenerator, or something else along those lines? I'm not
too picky either way with whatever you pick.
]

This interface will also be used to start the automated SSL cert generation process in the not too far off future. This will kick off a process that involves interacting with the CA to eventually generate an SSL cert, that will be stored in Barbican as a secret.  

This SSL cert generation process can be a long-running async process, so we were looking for terms that implied the secret generation would not necessary happen quickly, and instead have a state machine that could be long lived.  So 'order' probably fits this mode of operation the best. 

When I think of a 'factory' I'm expecting an instance to be created right then and there, which doesn't seem to fit the long-running nature of some secret creation processes.  

'Request' is seem between these two modes to me, and maybe overused as you point out, esp. in the context of http interactions. 

So it seems 'orders' is more appropriate here.  Thoughts though?



[
> The next step would be to provide the actual plain-text to encrypt/store in
> Barbican, via a follow up PUT call to the new secret, with the Accept header
> set to the mime-type above (say application/pem). This data would then be
> encrypted and stored by Barbican. To address Malini's concern about wrecking
> systems already using a key to encrypt their data, we may only allow one such
> PUT request to happen per secret.

I would like to see the put operation be one step. Making it two operations
seems a bit forced and introduces more overhead, IMHO. Now the key manager server
must wait for another web request for the actual key. What about time outs, or
if the second operation never happens. You are then in a weird state.
]

Well, the secret record would be created, but it would have no associated encrypted secret information associated with it.  An attempt to use it would fail quickly/obviously, but fail nonetheless.  


[
I would specify the type, and include the bytes for it. Then you can do it all
in one step. For instance, specify application/aes-256-cbc as mime type and
then include the bytes for the key. The server then stores the bytes, and it
can assume the bytes are in the format specified. Or do a check to make sure
they are formatted correctly to make it more secure.
]

What we were struggling with was allow for a variety of forms a secret might be formatted in...plain text, base64, straight binary (BLOB), etc.  Pure text based forms like plain and base64 could be accommodated via the current JSON request approach, whereby the text based secret is provided in the optional 'plain_text' field.  So if provided, that secret could be created in one step.  

If the user did want to provide a binary form, then the two-step POST(json)/PUT(binary) approach would work.

So maybe both modes are worth supporting?  

At any rate, it is definitely a good idea to verify formatting, or that the secret is in the 'algorithm' type that is specified. 

Thanks,
John

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