20:02:15 <redrobot> #startmeeting barbican 20:02:16 <openstack> Meeting started Mon Apr 7 20:02:15 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:19 <openstack> The meeting name has been set to 'barbican' 20:03:05 <redrobot> as usual the agenda can be found here: 20:03:08 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:03:32 <redrobot> is malini here? 20:04:22 <redrobot> looks like malini is out this week. We'll follow up on the OpenStack Security guide next week. 20:04:29 <hockeynut> o/ 20:04:34 <lisaclark> o/ 20:04:58 <woodster1> o/ 20:05:21 <jraim> o/ 20:05:23 <redrobot> ok, so first up, let's talk about plugin changes 20:05:41 <redrobot> #topic Crypto Plugin changes 20:05:45 <atiwari> sure 20:05:56 <alee_> yup 20:06:28 * redrobot is hunting for urls 20:06:32 <atiwari> we had some discussion last week regarding interface contracts and method signature 20:06:52 <atiwari> #link https://review.openstack.org/#/c/82189/6/barbican/crypto/plugin.py 20:06:56 <redrobot> #link alee_ 's changes https://review.openstack.org/#/c/84329/ 20:07:37 <alee_> it looks like there are two changes out there right now for the plugin -- one to support drm and one to support asymmetric keys 20:08:02 <atiwari> yes, mine is at #link https://review.openstack.org/#/c/82189/6 20:08:03 <redrobot> right, I think so far we're wanting to land the DRM change, and then discuss the asymmetric approach 20:08:55 <alee_> so has anyone had a chance to review the DRM changes? 20:09:22 <redrobot> I apologize, but I've had this one on the backburner myself. 20:09:46 <atiwari> I did it last week and mentioned that we are making changes in same land 20:09:49 <redrobot> one question that was outstanding for you, alee_ is why the DRM plugin needs the UUID for the secret? 20:10:12 <alee_> I know reaperhulk has looked at it -- any comments/ changes needed? 20:10:32 <alee_> redrobot, the drm needs an id to label the secret 20:10:49 <alee_> redrobot, we decided that that id would be the uuid 20:11:14 <redrobot> alee_ there were some concerns here about the extra load this will add to the DB 20:11:23 <redrobot> reaperhulk, woodster1 do you guys want to weigh in on it? 20:11:29 <woodster1> alee: could the DRM plugin generate a unique identifier for the secret on its own? 20:12:04 <alee_> the drm does in fact generate its own id - which would be unique for the drm - and so we could just pass in some random string 20:12:29 <alee_> basically then you would not really be using the client key id 20:12:40 <woodster1> alee: I was a little concerned about having barbican details leaking into the plugin contract 20:13:16 <alee_> woodster1, the idea is that the client (which in this case is barbican) provides some label for the secret stored 20:13:36 <alee_> it doesn't have to be the uuid for the secret - but that seems to make sense. 20:13:38 <reaperhulk> well, uuids aren't particularly specific details, but we don't get a uuid until we save the object so we don't actually have that available to pass to the plugin without significant changes (and those changes would increase the DB load quite a bit) 20:14:15 <woodster1> alee: I was hoping that the DRM could create a unique id/handle that would be stored in barbican, and then passed back to barbican when a decrypt is needed. 20:14:58 <alee_> woodster1, it does in fact do that -- and that is in fact stored for the decruypt 20:14:58 <redrobot> iirc, this would be a use case for the kek_meta binding with the plugin? 20:15:56 <alee_> woodster1, I can create a random string in the plugin to use for the client key id - in which case the secret need not be created until afterwards 20:15:56 <woodster1> I believe kek_metadata is scoped at the tenant level now rather than per-secret 20:16:28 <woodster1> alee: I think that might be cleaner overall…then the plugin is more self sufficient and isolated from barbican proper 20:16:30 <redrobot> woodster1, i see... 20:16:36 <alee_> I'm not sure I understand why this is significantly more load on the db .. the change is just to add the secret earlier in the function 20:16:58 <jraim> alee_: I think one concern is what happens when the plugin's generation fails? 20:17:03 <jraim> now we have to remove the secret 20:17:22 <jraim> it would be nice to ensure the plugin behaves before barbican stores the data 20:17:28 <woodster1> the first call would create the record and cut the ID/UUID, a second call would then be needed to update the record after generation…so two transactions instead of one 20:18:29 <alee_> woodster1, ok - I can generate a random string in the plugin for the client key id then. 20:19:06 <alee_> and then we need not create the secret until later 20:19:21 <redrobot> #agreed alee_ will update DRM plugin changes to generate a UUID instead of saving the secret before calling the plugin 20:20:23 <redrobot> cool, any other points on alee_ 's CR that we want to talk about? 20:20:46 <alee_> so then do we still want to pass the required generation parameters in some dto object? 20:21:00 <alee_> or leave them as they are as separate parameters? 20:21:35 <woodster1> do you think more parameters are needed? 20:22:03 <alee_> for generation currently no. 20:22:04 <atiwari> I think dto wd be better 20:22:10 <woodster1> if we need several passed in, then a dto could make sense 20:22:12 <atiwari> for future extension 20:22:22 <alee_> I agree with atiwari for future extension 20:22:55 <alee_> of course atiwari - I created the dto from the secret that was created. 20:23:13 <alee_> which is no longer being created .. 20:23:17 <alee_> (yet) 20:23:54 <atiwari> ok 20:24:12 <woodster1> we should know all the generation params prior to the generate call, so a new generate_dto might be ok, similar to that secret_dto? 20:24:16 <alee_> woodster1, I'm thinking also of the decrypt() case. At some point we are going to want to pass in parameters like a wrapping key tyhat is generated on the client 20:24:31 <alee_> exactly 20:25:01 <alee_> I think we probably need a generate_dto and decrypt_dto 20:25:23 <woodster1> dto's cleanly separate concerns and clean up params, so that sounds fine to me 20:25:44 <atiwari> how about use of kwargs ? 20:27:03 <redrobot> atiwari kwargs instead of a DTO? 20:27:20 <atiwari> yes, just throwing another option 20:27:30 <atiwari> but I am also ok with DTO 20:27:42 <redrobot> atiwari I think it would give the plugin a bit more work 20:27:51 <alee_> atiwari, I think a dto makes things more defined. 20:28:03 <atiwari> correct 20:28:25 <alee_> just offhand - I'd vote for dto. 20:28:39 <atiwari> me too with DTO 20:28:41 <woodster1> sounds good…I'd say give that a try then 20:29:02 <redrobot> #agreed we should use DTOs for create, generate, and decrypt 20:29:34 <redrobot> #info DTO = Data Transfer Object 20:29:36 <alee_> ok - any other concerns about my cr? 20:30:21 <atiwari> can we move to next topic? 20:30:32 <alee_> I'll make the changes and resubmit tomorrow. 20:30:39 <redrobot> sounds good 20:30:50 <redrobot> let's move on to atiwari's plugin changes 20:31:07 <atiwari> ok 20:31:22 <atiwari> wondering have you guys take a look? 20:31:25 <redrobot> I think the first thing we should talk about is whether we want separate methods for symmetric/asymmetric calls? 20:31:29 <atiwari> #link https://review.openstack.org/#/c/82189/6 20:32:00 <redrobot> I think reaperhulk has a feedback on this one 20:32:01 <atiwari> in my opinion yes, because return type is different 20:32:29 <atiwari> or ve can device a new generic DTO for return 20:33:02 <malini> +1 different methods 20:33:08 <atiwari> redrobot, reaperhulk's comment I tried to fix 20:33:19 <atiwari> and waiting for more review on this 20:33:31 <alee_> I'd argue for separate methods because they are very different functionalities 20:33:38 <rellerreller> +1 different methods 20:33:59 <alee_> for instance, right now drm doesn't expose generating an asymmetric key 20:34:12 <atiwari> alee_ are with different methods? 20:34:12 <alee_> (it will later .. but it doesn't now) 20:34:27 <redrobot> I think that we could also argue that the plugin manager would orchestrate generating the different asymmetric parts, before packing it into a Container 20:34:49 <reaperhulk> redrobot, that's an interesting idea 20:35:03 <reaperhulk> That part of the logic is probably identical across all plugins, so it might make sense to hoist it up 20:35:22 <alee_> redrobot, not sure I understand what you're suggesting? 20:35:37 <atiwari> redrobot, I think for separation of concern we should use separate method with different return s 20:35:51 <atiwari> and bind in container in upper layer 20:36:15 <woodster1> I'd definitely agree that the plugin should not be creating Containers, but rather the components of it to be put into a Container by the plugin manager later 20:36:37 <redrobot> alee_ currently, the plugin manager just calls generate with whatever params for symmetric. the idea would be that the plugin manager would call generate a few times with different params to generate the public key, private key, and possibly a passphrase. 20:36:40 <atiwari> woodster1 +1 20:36:47 <atiwari> that is my plan 20:37:26 <woodster1> I think some of the concern here is that orders, SSL cert generation/management, containers, and asymmetric key gen have overlapping design concerns 20:38:36 <atiwari> I think containers are just a envelop 20:38:43 <woodster1> the crypto plugin level is someone low level in nature right now. The order/container/ssl-cert flows seem higher level orchestration concepts. That's why a design session to discuss this would be very good to do. 20:39:25 <redrobot> agreed, I think this is going to require a design session during the Summit 20:39:38 <atiwari> woodster1, as per our discussion at #link https://blueprints.launchpad.net/barbican/+spec/api-orders-add-more-types 20:40:00 <reaperhulk> sorry guys, gotta run for a bit. redrobot & woodster1 know more about the general design here than I do though so you're in good hands 20:40:10 <atiwari> we thought that will be begin with symmetric and asymmetric 20:40:38 <alee_> redrobot, I'm a little confused - can you generate a public key separate from the private key? 20:41:09 <atiwari> alee_ no I think 20:41:21 <redrobot> alee_ you could generate the private key from the secret key 20:41:26 <atiwari> that is why it has to be atomic 20:41:34 <malini> no, private&public born at the same time 20:41:47 <atiwari> malini +1 20:42:12 <alee_> then I'm a little confused about the idea of calling generate to create the private key, then calling generate to generate the public key, then putting it all together .. 20:42:33 <atiwari> me too, it has to be atomic calls 20:42:34 <rellerreller> I'm confused by that as well 20:43:30 <redrobot> the public key can be derived from the private key. doing it all at once is probably more efficient, but I do like the idea of generate() only returning single encrypted datums 20:43:45 <malini> alee_, perhaps redrobot mis-wrote there, after private-public born, then certify the public aspect, perhaps attach a passphrase to the private to further protect it 20:44:07 <redrobot> it's a bummer reaperhulk left already, since he's our in-house crypto expert 20:44:34 <malini> :-D 20:44:42 <atiwari> redrobot I think he is ok with separate atomic methods 20:44:55 <atiwari> as per lat week chat 20:44:56 <rellerreller> Are there any other specs or libraries that generate public/private key pairs in two operations? 20:45:24 <redrobot> rellerreller none that I'm aware of... I'm just brainstorming over here :) 20:45:40 <rellerreller> It might be better for developers to have one method for assymetric bc that's what they're used to 20:45:44 <redrobot> this would be just for the plugin_manager to plugin interaction 20:46:01 <redrobot> rellerreller yeah, that's definitely a good argument. 20:46:07 <atiwari> rellerreller +1 20:46:12 <alee_> redrobot, I think you're trying to shoe horn what is essentially a single operation generating a public/private key PAIR -- into a single datum 20:46:36 <alee_> it makes more sense to me for the plugin to simply return a tuple of the public, private keys 20:46:56 <alee_> and that probably means separate methods 20:46:57 <atiwari> +1 that will be simple too 20:47:04 <rellerreller> +1 20:47:12 <malini> malini +1 20:47:18 <alee_> generateSymmetiric(), generateAsymmetric() 20:47:28 <atiwari> I am ok with names 20:47:36 <woodster1> it seems a separate asymmetric method does make sense, returning a tuple perhaps that is then stored as a Container by the extention manager 20:47:36 <alee_> and the top layer can combine as needed 20:48:02 <atiwari> yep 20:48:20 <redrobot> I'm ok with that. 20:48:36 <atiwari> agreed :) 20:48:38 <atiwari> ? 20:48:39 <malini> alee_ +1 20:49:42 <malini> another advantage is with generateSymmetric() there is no aysnchronous stuff, the call response would be key, and key-id, and can be used promptly 20:49:45 <redrobot> #agreed Asymmetric Keys should be generated in a new method generate_symmetric() 20:50:06 <atiwari> OK, then I will redo these method 20:50:07 <malini> redrobot -- typo there 20:50:30 <atiwari> question, should I redo with DTO too? 20:50:38 <atiwari> I think yes? 20:50:51 <alee_> I think yes 20:50:53 <redrobot> atiwari keep an eye on alee_ 's changes. I think we'll want to reuse the DTOs from his CR 20:51:03 <atiwari> ok 20:51:23 <alee_> atiwari, I should have my revised changes in by tommorow. 20:51:34 <atiwari> sure 20:51:38 <redrobot> ok, guys we're running out of time here, I don't think we have time to cover any more agenda points 20:51:53 <redrobot> any last thoughts on Crypto Plugin changes before we call the meeting? 20:52:04 <atiwari> I am OK 20:52:05 <alee_> has anyone had a chance to look at my follow on cr? 20:52:19 <alee_> https://review.openstack.org/#/c/85137/ 20:52:29 <redrobot> malini do'h >_< 20:52:34 <atiwari> not me, I will do 20:52:45 <alee_> I'm guessing not because it depends on the previous one. 20:53:20 <alee_> but I'd like to discuss that one once the first one goes in 20:53:21 <redrobot> I haven't had a chance 20:53:38 * redrobot is way behind on reviews 20:53:51 <woodster1> quick read of it looks good to me (after the dto changes in the dep CR of course) 20:54:12 <alee_> woodster1, cool 20:54:12 <woodster1> not sure about the jenkins fails 20:54:30 <alee_> lets put it on the agenda for next week then 20:54:41 <alee_> woodster1, yeah I'll fix those 20:54:50 <woodster1> I'm curious if tox locally fails too 20:55:07 <woodster1> oh yeah, unused imports, easy to fix 20:55:38 <alee_> woodster1, testing though will involve actually creating a drm 20:55:40 <woodster1> the dev stack fail is probably more tricky to diagnose, so we might need to assist with that one 20:56:21 <redrobot> devstack gate was broken for everyone last week, so we may just need to re-kick that CR 20:56:45 <alee_> yup I'll rekick when I fix the unused imports 20:56:54 <alee_> (and change the dtos etc) 20:57:49 <redrobot> ok guys, we're out of time for this week. We'll revisit the other agenda items next week. In the meantime, try to get some reviews in when you can. 20:57:57 <redrobot> thanks everyone! 20:57:59 <atiwari> redrobot, there are more items in agenda can we talk in barbican room 20:58:01 <atiwari> ? 20:58:04 <woodster1> wow that went by fast 20:58:18 <redrobot> atiwari yeah, jump over to #openstack-barbican 20:58:25 <atiwari> ok 20:58:28 <redrobot> #endmeeting