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