20:01:44 <redrobot> #startmeeting barbican 20:01:44 <openstack> Meeting started Mon May 5 20:01:44 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:47 <openstack> The meeting name has been set to 'barbican' 20:01:58 <Swami> hi all 20:02:09 <redrobot> hi Swami! 20:02:09 <malini> Greetings 20:02:19 <atiwari> Hi All 20:02:21 <hgedikli> hi 20:02:25 <bdpayne> o/ 20:02:28 <lisaclark1> o/ 20:02:31 <jraim> o/ 20:02:38 <reaperhulk> reporting for duty 20:02:49 <redrobot> reaperhulk need more Vespene gas 20:02:50 <alee> o/ 20:02:56 <arunkant> o/ 20:03:01 <redrobot> as usual the Barbican meeting agenda can be found here: 20:03:01 <kfarr> o/ 20:03:03 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:03:08 <reaperhulk> I'm only mining minerals 20:03:35 <redrobot> And it looks like we don't have a pre-set agenda for today, so I'm just going to wing it. 20:04:02 <atiwari> redrobot, there are some agenda :) 20:04:05 <Swami> redrobot: I added an additional agenda to check the readiness to consume by advanced services. 20:04:46 <redrobot> derp, sorry guys, I totally skipped past that 20:05:49 <hockeynut> o/ 20:05:50 <redrobot> Ok, let's go in order of the wiki then 20:06:23 <redrobot> #topic Extended plugin for more key types 20:06:56 <redrobot> I think this CR has made a lot of progress since last week 20:07:05 <redrobot> I still want to go through and re-review. 20:07:17 <redrobot> I was concerned about the supports(...) logic in the dev plugin 20:07:27 <redrobot> but I haven't had a chance to look at the latest patches 20:07:30 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:07:49 <redrobot> #link https://review.openstack.org/#/c/82189/ 20:08:00 * redrobot is not as prepared as he should be 20:08:08 <atiwari> redrobot, please add your concerns if any. I have tried to address multipel around support 20:08:23 <redrobot> atiwari will do 20:08:29 <redrobot> anyone else have any comments on that patch? 20:08:46 <malini> I have a few questions: 20:08:48 <reaperhulk> I +1'd it today reflecting my general feeling that is mostly good, but since it touches the core of the system I'd love more eyes on it (ASAP) 20:09:05 <malini> with hmac etc .. will the user provide a passphrase to hamc-ify 20:09:29 <malini> else what is the point in generating a random number or string and hmac-ifying? 20:09:52 <malini> shall we apply a salt and save the salt or secret with the hmac 20:10:00 <malini> and salt is random but stored once selected 20:10:19 <atiwari> malini, can you please add your concern in the cr 20:10:20 <atiwari> ? 20:10:42 <malini> yes, but raised it here in case I have missed some context that others have 20:11:07 <atiwari> basically hmac keya are needed to generate secret key access key pairs 20:11:33 <atiwari> and used to generate API access signature 20:11:49 <atiwari> with different algo hmacshaxxx ... 20:13:03 <atiwari> do that make sense 20:13:04 <atiwari> ? 20:13:06 <malini> I know hmac used for signatures, also it is a technique used to capture "passwords" for authentication without leaking the password 20:13:29 <atiwari> it is not for password 20:13:45 <reaperhulk> Generic HMAC support is not really specified yet in barbican. The items in SYMMETRIC_ALGORITHMS are really only a list of allowable types that underlying plugins can support. Plugins still have to add their own support for this type, which would only be for generation or storage at this time. 20:13:56 <malini> just asking if when hmac used, are we getting user input in terms of a passphrase .. the thing that we shall hmac 20:14:18 <atiwari> in swift there is concept of temp url 20:14:42 <atiwari> these hmac will be used by end users to generate those temp url 20:14:48 <atiwari> that is one use of it 20:15:17 <reaperhulk> atiwari: those uses are in the future though, correct? At this time even with your CR barbican can't do anything with "hmac" other than generate/store/retrieve keys that it may consider hmac keys. 20:15:21 <malini> reaperhulk and atiwari -- thanks -- my question answered 20:15:40 <atiwari> reaperhulk correct 20:16:03 <atiwari> barbican is just responsible for generate/store/retrieve 20:16:13 <reaperhulk> okay, glad we cleared that up :) 20:16:28 <atiwari> good 20:17:21 <redrobot> ok, looks like we just need more eyes on that review to keep it moving along. 20:17:38 <redrobot> let's move on to the next topic 20:17:42 <atiwari> redrobot sounds OK 20:18:03 <redrobot> #topic Target support for policy enforcement 20:18:13 <redrobot> #link https://review.openstack.org/#/c/81310/ 20:18:22 <redrobot> I think woodster__ had some concerns about this one. 20:18:49 <arunkant> I have addressed those concerns and waiting for feedback on those comments 20:18:56 <redrobot> but it looks like some of them have been addressed 20:19:04 <atiwari> yep 20:19:06 <redrobot> arunkant got it 20:19:27 <redrobot> I think we're on the same boat of needing more eyes on this CR as well? 20:19:36 <woodster__> arunkant: I can take a look at the latest changes. 20:20:06 <atiwari> redrobot I think you skipped one topic :) 20:20:20 <redrobot> atiwari coming back to the API changes as one topic next :) 20:20:28 <atiwari> ok 20:20:36 <arunkant> great woodster__ 20:20:53 <woodster__> I do think everyone should weigh in on this CR though 20:20:53 <redrobot> any more comments on this CR while we're here? 20:21:59 <atiwari> redrobot I did a review sometime back I will look at it again 20:22:06 <redrobot> atiwari awesome, thanks 20:22:12 <redrobot> ok, let's move along 20:22:13 <atiwari> np 20:22:27 <redrobot> #topic API changes 20:22:33 <redrobot> #link https://review.openstack.org/#/c/88463/ 20:22:39 <redrobot> #link https://review.openstack.org/#/c/90613/ 20:23:10 <redrobot> I do like that we're using Gerrit for reviewing this stuff... I think we definitely need to make some time to add a repo just for this type of reviews though 20:23:34 <atiwari> +2 redrobot 20:23:35 <redrobot> that way we can vote, and merge the API change once we all agree on one 20:23:48 <atiwari> that will be awesome 20:23:55 <reaperhulk> agreed 20:23:55 <malini> the openstack blueprints have all moved to gerrit these days 20:24:33 <jraim> I'd like to avoid a repo just for API changes, I'd prefer moving to all blueprints being in Gerrit with any api changes detailed in one of them 20:24:49 <jraim> Maybe we can nail down exactly how that will look at the summit? 20:25:46 <atiwari> Thanks jraim , lets hash out this in summit 20:26:07 <Swami> Do you have any sessions in the summit 20:26:32 <redrobot> #agreed We will nail down a blueprint Gerrit process at Atlanta Summit 20:26:38 <alee> atiwari, 90613 has "outdated" in the description? is that correct -- or is this cr still valid? 20:26:48 <atiwari> redrobot +1 20:27:15 <atiwari> #link https://review.openstack.org/#/c/90613/? 20:27:22 <atiwari> alee ^ 20:27:42 <atiwari> it is valid for certificate generation API 20:28:01 <alee> atiwari, ah never mind -- it depends on an outdated lueprint .. 20:28:07 <redrobot> atiwari yeah, looks like it depends on an outdated CR. Maybe it needs to be rebased? This is something that we'll have to figure out as part of the Atlanta Blueprint Gerrit discussion. 20:28:09 <alee> my confusions 20:28:21 <Swami> Is this link broken, I could not open the link 20:28:31 <jraim> Swami: we have two official sessions. The gerrit one will probably just be a table discussion in the ATC lounge 20:28:46 <atiwari> redrobot https://review.openstack.org/#/c/88463/ is the one before that one 20:29:11 <Swami> jraim: thanks 20:29:23 <atiwari> and this is needed for me to start API part of key generation 20:29:46 <atiwari> I am not much concerned about #link https://review.openstack.org/#/c/90613/ 20:30:25 <atiwari> lets skip https://review.openstack.org/#/c/90613/ for now 20:32:42 <redrobot> atiwari I'll have to lookt at 88463 in more detail, but at a glance it looks pretty good. 20:33:18 <atiwari> great, I will be waiting for some blessings on it. 20:33:20 <atiwari> thanks 20:33:22 <redrobot> anyone have opinions on using "key" vs "symmetric"? 20:33:41 <reaperhulk> redrobot: I'll need to look at the context to have a real opinion on that ;) 20:34:08 <redrobot> reaperhulk cool, we'll keep those CRs moving then. Hopefully we'll have a repo to land them into next week. 20:34:18 <atiwari> +1 20:34:32 <redrobot> ok, moving on 20:34:36 <atiwari> yep 20:34:59 <redrobot> #topic Barbican Certificate/Key generation status for Advanced Services Common Requirements 20:35:11 <Swami> hi redrobot. 20:35:19 <redrobot> hi Swami, was this you that added the topic? 20:35:31 <Swami> Yes just wanted to give some insight on where I am coming from 20:35:36 <Swami> redrobot: yes 20:35:41 <redrobot> Swami go ahead 20:35:56 <Swami> We are currently working on the Neutron Advanced Services framework. 20:36:27 <Swami> Our Advanced services such as VPN and LBaaS wanted to store and retrieve the certificates for their use. 20:37:04 <Swami> We had a discussion with the Neutron PTL and we were asked to use the Barbican infrastructure for all certificate and keys store. 20:37:24 <Swami> So that is the reason I will be following, barbican. 20:37:57 <Swami> I did go through the Wiki, pretty much I understood the API and how the keys are stored and retrieved. 20:38:15 <Swami> How does it work, when a Service wanted to use it on behalf of a tenant. 20:38:29 <alee> Swami, what kind of certificates are these? ssl server certs? user certs? signing certs? 20:38:44 <jraim> Swami: so the general thought would be either (a) service token or (b) impersonation token 20:39:07 <jraim> (b) should work now. I don't think we've really thought about (a) yet 20:39:15 <Swami> alee: Yes these would be ssl certificates and self signed certificates 20:39:18 <jraim> but it could be handled with the policy stuff I think? 20:39:27 <Swami> Or even a CA singed certificate. 20:40:11 <Swami> Yes we need to sync up with your team to figure out the roadmap and how we can integrate it right now. 20:40:37 <jraim> Swami: do you have an opinion on whether you would like a service token or impersonation token? 20:40:43 <woodster__> swami: it migth be good to detail a scenario you are envisioning here 20:40:45 <jraim> does keystone doing impersonations? Or is that just rax-auth 20:41:16 <redrobot> jraim I'm thinking that's a rax-auth feature 20:41:21 <Swami> I think in this case it would be both, if i understand it correctly both Service token and impersonation token. 20:41:53 <Swami> A tenant is configuring a secure VPN tunnel, so he wanted to use a certificate for authentication or use any PSK for authentication. 20:42:01 <atiwari> keystone does not support impersonations but there is concept of trust 20:42:09 <Swami> These keys say for example it will be stored by the barbican service. 20:42:15 <atiwari> one can give trust to someone 20:42:47 <woodster__> swami: Is this related to this question on the openstack-dev neutron lbass list?: Is there anyway (or any plans to) allow a user to register a secret as 20:42:48 <woodster__> being used by another service so that barbican will disallow deleting 20:42:49 <woodster__> (or make it so that its harder to delete, and make the user aware its 20:42:49 <woodster__> being used by what services)? 20:42:55 <Swami> Then when the VPN service is created, then we need to provide either the "URL" of the barbican's tenant's certificate for the driver to pull the certificate on behalf of then tenant. 20:43:01 <woodster__> (sorry formatting borked there…) 20:44:10 <Swami> woodster: I need to check this back with the Advanced services team, since the framework is being re-worked right. If this is basic reqirement then I can take it to the that team. 20:44:20 <Swami> I will update it next week on this. 20:44:48 <Swami> We probably should also have a meeting in Atlanta face-to-face to discuss how barbican can tie with the services requirements. 20:46:39 <redrobot> #action swami to meet with Barbican team during Atlanta summit to discuss further 20:46:55 <Swami> +1 agreed 20:47:04 <redrobot> cool 20:47:21 <redrobot> Ok, we got one more topic on the agenda 20:47:37 <redrobot> #topic Add key-wrapping to encrypt/decrypt 20:47:47 <redrobot> alee you want to take this one? 20:48:03 <alee> yeah - has anyone other than reaperhulk had a chance to review this? 20:48:28 <alee> ( I wrote it today so I wont be surprised if no one else has) 20:48:56 <atiwari> alee not yet, I will look after the meeting 20:49:08 <alee> but basically its what we have been talking about on and off for awhile -- ie. changes on the barbican server to enable wrapping 20:49:08 <woodster__> is there a CR out there? 20:49:24 <reaperhulk> woodster__: https://blueprints.launchpad.net/barbican/+spec/add-wrapping-key-to-barbican-server 20:49:25 <reaperhulk> #link https://blueprints.launchpad.net/barbican/+spec/add-wrapping-key-to-barbican-server 20:49:30 <alee> woodster__, not yet -- just a blueprint 20:49:37 <reaperhulk> It links to the dogtag wiki so it doesn't hurt your eyes to read it 20:49:58 <alee> woodster__, I did not create a CR because there are some design decisions 20:50:20 <woodster__> alee: got it, thanks 20:50:30 <alee> woodster__, basically - for secret storage - option 1 vs option 2 20:50:48 <alee> woodster__, and for retrieval - GET vs POST 20:51:17 <atiwari> alee can you please start etherpad/api proposal ? 20:51:34 <alee> sure 20:51:49 <malini> what happened to that proposal where we wanted to control access to a key not just by tenant but by user-id and role 20:52:01 <alee> reaperhulk and I have discussed a few things on this -- and I'll put that on the proposal 20:52:15 <atiwari> malini , we are working on it 20:52:31 <atiwari> arun-kant has posed first cr in the same kine 20:52:34 <wyllys> i like the wrapping proposal - buy why 3DES and not AES? 20:53:17 <atiwari> s/kine/line 20:53:20 <alee> wyllys, we can do AES -- its just because the DRM requiresw 3DES for now. We'll fix that. 20:53:29 <wyllys> ok 20:53:38 <alee> and allow you to specify the algorithm 20:53:47 <wyllys> every time i read DRM, I think of digital rights mgmt. ugh. 20:54:14 <alee> wyllys, sorry - some brainiac in marketing come up with that .. 20:54:21 <redrobot> wyllys me too >_< 20:54:32 <alee> I think it precedes digital rightsa mgmt though .. 20:54:44 <alee> maybe we can sue microsoft .. 20:54:47 <reaperhulk> KRA was unacceptable :D 20:55:01 <wyllys> its got very negative connotations now. especially when discussing crypto and keys. 20:55:41 <alee> yeah - internally we always say KRA. 20:55:47 <wyllys> cool 20:56:10 <redrobot> alrighty guys, looks like we're down to the last few minutes here 20:56:38 <alee> anyways, if I can get some eyes on this in the next day or two, I can whip up a cr by the summit 20:56:58 <redrobot> alee will do 20:57:23 <woodster__> Just an FYI that we'll be sending out links to plugin design/concept wikis this week…hopefully will help with design work in Atlanta 20:57:24 <atiwari> all just for FYI, I am putting together API change proposal to remove tenant from uri and support for hard delete and cascade delete. Will need some discussion in summit 20:57:32 <redrobot> Ok, guys. Remember there won't be an IRC meeting next week. (I think?) 20:57:38 <redrobot> #topic Summit 20:58:09 <atiwari> redrobot ^ 20:58:35 <redrobot> #link https://wiki.openstack.org/wiki/Barbican#Discussions_.2F_Etherpads 20:58:47 <redrobot> take a look at those ^^ before the summit if y'all get a chance 20:59:22 <redrobot> Remember, no IRC meeting next week (I think?). See you guys in Atlanta! 20:59:31 <atiwari> redrobot sure 21:00:03 <redrobot> Thanks for coming, everyone! 21:00:06 <redrobot> #endmeeting