| *** chlong has quit IRC | 00:01 | |
| *** chlong has joined #openstack-barbican | 00:02 | |
| *** jaosorior has quit IRC | 00:03 | |
| *** chlong has quit IRC | 00:06 | |
| *** lisaclark1 has quit IRC | 00:14 | |
| *** lisaclark1 has joined #openstack-barbican | 00:14 | |
| *** lisaclark1 has quit IRC | 00:19 | |
| *** chlong has joined #openstack-barbican | 00:29 | |
| *** kgriffs is now known as kgriffs|afk | 00:31 | |
| *** dougwig is now known as dougwig_the_rude | 00:41 | |
| *** dougwig_the_rude is now known as dougwig | 00:42 | |
| *** arunkant has quit IRC | 00:53 | |
| *** kebray has quit IRC | 01:17 | |
| *** gyee has quit IRC | 01:36 | |
| *** SheenaG1 has joined #openstack-barbican | 01:48 | |
| *** SheenaG11 has joined #openstack-barbican | 01:50 | |
| *** SheenaG1 has quit IRC | 01:52 | |
| *** lisaclark1 has joined #openstack-barbican | 02:05 | |
| *** ryanpetrello has quit IRC | 02:08 | |
| *** chlong has quit IRC | 02:11 | |
| *** SheenaG11 has quit IRC | 02:20 | |
| *** SheenaG1 has joined #openstack-barbican | 02:28 | |
| *** SheenaG1 has quit IRC | 02:38 | |
| *** ryanpetrello has joined #openstack-barbican | 02:53 | |
| *** kebray has joined #openstack-barbican | 03:18 | |
| *** kebray has quit IRC | 03:19 | |
| *** kebray has joined #openstack-barbican | 03:20 | |
| *** zz_dimtruck is now known as dimtruck | 03:25 | |
| *** kebray has quit IRC | 03:35 | |
| *** ryanpetrello has quit IRC | 03:49 | |
| *** chlong has joined #openstack-barbican | 03:57 | |
| *** kebray has joined #openstack-barbican | 03:59 | |
| *** chlong has quit IRC | 04:02 | |
| *** kebray has quit IRC | 04:17 | |
| *** chlong has joined #openstack-barbican | 04:18 | |
| *** dimtruck is now known as zz_dimtruck | 04:41 | |
| *** david-lyle has quit IRC | 04:50 | |
| *** kebray has joined #openstack-barbican | 05:00 | |
| *** lisaclark1 has quit IRC | 05:20 | |
| *** kebray has quit IRC | 06:21 | |
| *** jamielennox is now known as jamielennox|away | 06:33 | |
| *** woodster_ has quit IRC | 07:10 | |
| *** chlong has quit IRC | 07:47 | |
| *** crc32 has quit IRC | 08:23 | |
| *** hyakuhei has joined #openstack-barbican | 09:22 | |
| *** hyakuhei has quit IRC | 09:42 | |
| openstackgerrit | Merged openstack/barbican: Replace and remove native asserts https://review.openstack.org/145563 | 09:43 |
|---|---|---|
| *** hyakuhei has joined #openstack-barbican | 10:04 | |
| *** hyakuhei has quit IRC | 10:06 | |
| *** chlong has joined #openstack-barbican | 11:43 | |
| *** hyakuhei has joined #openstack-barbican | 12:03 | |
| *** woodster_ has joined #openstack-barbican | 12:29 | |
| *** ryanpetrello has joined #openstack-barbican | 12:54 | |
| *** hyakuhei has quit IRC | 12:59 | |
| *** hyakuhei has joined #openstack-barbican | 13:15 | |
| *** darrenmoffat has quit IRC | 13:16 | |
| *** ryanpetrello has quit IRC | 13:16 | |
| *** darrenmoffat has joined #openstack-barbican | 13:17 | |
| *** ryanpetrello has joined #openstack-barbican | 13:17 | |
| *** alee has quit IRC | 13:33 | |
| *** hyakuhei has quit IRC | 13:43 | |
| *** ryanpetrello has quit IRC | 13:50 | |
| *** hyakuhei has joined #openstack-barbican | 14:14 | |
| *** hyakuhei has quit IRC | 14:15 | |
| *** nkinder has quit IRC | 14:16 | |
| *** hyakuhei has joined #openstack-barbican | 14:21 | |
| *** kgriffs|afk is now known as kgriffs | 14:30 | |
| *** miqui_ has joined #openstack-barbican | 14:41 | |
| *** alee has joined #openstack-barbican | 14:49 | |
| *** kgriffs is now known as kgriffs|afk | 14:58 | |
| *** lisaclark1 has joined #openstack-barbican | 15:03 | |
| *** nkinder has joined #openstack-barbican | 15:04 | |
| *** ryanpetrello has joined #openstack-barbican | 15:11 | |
| *** kgriffs|afk is now known as kgriffs | 15:39 | |
| *** kebray has joined #openstack-barbican | 15:51 | |
| *** lisaclark1 has quit IRC | 15:53 | |
| *** SheenaG1 has joined #openstack-barbican | 15:56 | |
| *** kebray_ has joined #openstack-barbican | 16:04 | |
| *** kebray has quit IRC | 16:05 | |
| *** hyakuhei has left #openstack-barbican | 16:09 | |
| *** lisaclark1 has joined #openstack-barbican | 16:15 | |
| *** lisaclark1 has quit IRC | 16:24 | |
| *** lisaclark1 has joined #openstack-barbican | 16:24 | |
| *** nkinder has quit IRC | 16:24 | |
| rm_work | Woo, I'm back! :) | 16:26 |
| rm_work | So, any updates on Castellan? I left for three weeks right after signing up to do a spec BP for the Certificate Management interface… <_< | 16:27 |
| SheenaG1 | rm_work: who is this? I don't remember you. | 16:28 |
| jvrbanac | rm_work, not yet. CR's accepted! | 16:29 |
| jvrbanac | ;) | 16:29 |
| rm_work | lol | 16:29 |
| SheenaG1 | rm_work: I think I need a cake to remember you better... | 16:29 |
| chellygel | Castellan is such a great name | 16:29 |
| chellygel | :D | 16:29 |
| rm_work | yes :) | 16:29 |
| rm_work | jvrbanac: CR for adding the Castellan repo? | 16:30 |
| rm_work | or for something further? | 16:30 |
| jvrbanac | rm_work, it was merged. https://github.com/openstack/castellan | 16:30 |
| jvrbanac | rm_work, https://review.openstack.org/#/q/project:openstack/castellan,n,z | 16:30 |
| rm_work | cool | 16:31 |
| *** chlong has quit IRC | 16:34 | |
| rm_work | So I guess I'll wait for whoever is doing the primary interface spec, comment on that if I see any problems down the road, then write the cert spec to be complimentary | 16:34 |
| rm_work | Who was going to be writing that spec? Did someone sign up for it? | 16:34 |
| jvrbanac | rm_work, I'm not sure at the moment. | 16:35 |
| rm_work | ok. do we have a target timeline? | 16:35 |
| rm_work | I am guessing not Kilo? | 16:36 |
| jvrbanac | redrobot, ^^ | 16:36 |
| rm_work | is redrobot back? :P | 16:36 |
| *** nkinder has joined #openstack-barbican | 16:38 | |
| *** gyee has joined #openstack-barbican | 16:39 | |
| jvrbanac | rm_work, he is, but I think he's running a couple errands this morning. He should be around a little later | 16:39 |
| rm_work | cool, k | 16:39 |
| rm_work | SheenaG1: http://pastebin.com/raw.php?i=KKkavRWT | 16:42 |
| SheenaG1 | rm_work: thanks for acknowledging my trolling. I can go back to work now. | 16:43 |
| rm_work | <3 | 16:43 |
| chellygel | something something that cake is a lie something | 16:44 |
| openstackgerrit | John Vrbanac proposed openstack/barbican: Moving exception logging in the base behaviors https://review.openstack.org/145835 | 16:46 |
| jvrbanac | alee, redrobot, reaperhulk, rellerreller, hockeynut, could we get a workflow on: https://review.openstack.org/#/c/145591/ ? | 16:51 |
| redrobot | jvrbanac I'll take a look at it | 16:54 |
| jvrbanac | redrobot, thx | 16:54 |
| redrobot | rm_work happy 2015! ... last I heard one of the JHU folks was going to be working on fleshing out the Castellan interface, and also sending patches to Cinder, Glance, etc. | 16:55 |
| rm_work | err, JHU? | 16:56 |
| redrobot | rm_work http://git.openstack.org/cgit/openstack/castellan is live already | 16:56 |
| redrobot | rm_work John's Hopkins University | 16:56 |
| rm_work | ah k. yeah, i saw that :P unfortunately not much there yet | 16:56 |
| redrobot | rm_work I'll add an agenda item to ask rellerreller about it next Monday | 16:57 |
| rm_work | thanks | 16:57 |
| *** kebray_ has quit IRC | 16:58 | |
| *** vb has joined #openstack-barbican | 16:58 | |
| alee | jvrbanac, made comment on cr | 16:58 |
| *** vb has left #openstack-barbican | 16:59 | |
| rm_work | redrobot: I assume that Kilo is unrealistic as a possible timeframe though, right? so I'll have to continue with my temporary work directly in neutron-lbaas so we have something until Castellan is ready? | 16:59 |
| rm_work | ie, if we need an interface by Kilo, I shouldn't hold out for Castellan | 16:59 |
| redrobot | rm_work we still have a couple of months before feature freeze... I don't think the interface will be that much work... maybe it's something we can work on during the mid-cycle meetup. | 17:01 |
| rm_work | k | 17:01 |
| rm_work | where did that end up being? | 17:01 |
| rm_work | SF? | 17:01 |
| *** tkelsey has joined #openstack-barbican | 17:01 | |
| redrobot | rm_work Austin | 17:02 |
| rm_work | oh | 17:02 |
| rm_work | that isn't too bad | 17:02 |
| rm_work | when? | 17:02 |
| *** SheenaG1 has quit IRC | 17:03 | |
| redrobot | rm_work https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint | 17:03 |
| *** bdpayne has joined #openstack-barbican | 17:04 | |
| rm_work | ah, found it https://wiki.openstack.org/wiki/Barbican/Kilo#Kilo_Midcycle_Meetup too | 17:04 |
| *** ChanServ sets mode: +o redrobot | 17:04 | |
| rm_work | i can hopefully make that' | 17:04 |
| rm_work | trying to remember when the neutron-lbaas one is | 17:05 |
| *** lisaclark1 has quit IRC | 17:05 | |
| *** redrobot changes topic to "Barbican Kilo Mid-Cycle Sprint Feb. 16-18, Austin, TX. https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint" | 17:05 | |
| *** kebray has joined #openstack-barbican | 17:06 | |
| redrobot | jvrbanac should that exception be re-raised to bail out? As written it will return None (I think) and blow up elsewhere... | 17:07 |
| *** lisaclark1 has joined #openstack-barbican | 17:07 | |
| jvrbanac | redrobot, no. We don't want to re raise. See line 29 | 17:08 |
| jvrbanac | defaults to a dict | 17:08 |
| jvrbanac | It'll just return an empty dict | 17:08 |
| redrobot | jvrbanac heh.. totally missed that. I think alee did too. :) Ok, sounds good to me. WORFLOWEDED | 17:09 |
| jvrbanac | This will allow the tests to assert correctly instead of bailing | 17:09 |
| *** lisaclark1 has quit IRC | 17:09 | |
| *** lisaclark1 has joined #openstack-barbican | 17:11 | |
| alee | jvrbanac, if the tests assert correctly without bailing, how will we know that there are issues? | 17:13 |
| alee | redrobot, ^^ | 17:13 |
| alee | jvrbanac, I appreciate that this intermittent error is holding things up -- it affected me the other day too - but shouldn | 17:14 |
| alee | shouldn't we be trying to figure whats causing this issue? | 17:15 |
| alee | if you do this - any future issues will be masked. | 17:15 |
| alee | (after all - no one checks the logs if the tests passed) | 17:16 |
| redrobot | alee I presume that the empty dict would make the tests fail anyway, but you do make a good point. | 17:17 |
| *** paul_glass has joined #openstack-barbican | 17:21 | |
| *** paul_glass has quit IRC | 17:23 | |
| *** SheenaG1 has joined #openstack-barbican | 17:25 | |
| openstackgerrit | Merged openstack/barbican: Adding error handling to help debug devstack issue https://review.openstack.org/145591 | 17:28 |
| *** kebray has quit IRC | 17:34 | |
| alee | bdpayne, ping | 17:58 |
| bdpayne | hey | 17:58 |
| alee | bdpayne, were you the one advocating for the cert api generated from an existing stored private/public key pair? | 17:59 |
| bdpayne | roughly, yeah | 17:59 |
| alee | bdpayne, I thought so .. just to be clear, its the "stored-key" option in https://review.openstack.org/#/c/135490/5/specs/kilo/certificate-order-api.rst,cm | 18:00 |
| alee | option 3 .. | 18:00 |
| * bdpayne looks | 18:00 | |
| alee | bdpayne, if it is, I'd like to understand the use case for this -- because implementing this is problematic | 18:01 |
| bdpayne | ok | 18:02 |
| bdpayne | so that is about what I was thinking | 18:02 |
| bdpayne | but there may be other ways to accomplish this too | 18:02 |
| bdpayne | the idea being that you could ask barbican for a new cert | 18:02 |
| bdpayne | the priv key could be stored in barbican already | 18:03 |
| bdpayne | so barbican could just update that certs expiration date | 18:03 |
| bdpayne | this could be useful for an ephemeral pki | 18:03 |
| bdpayne | although there is now a new emphemeral pki project proposed by hp | 18:03 |
| bdpayne | and I haven't had a chance to explore that too much yet | 18:03 |
| bdpayne | it may fill in some of these gaps | 18:03 |
| bdpayne | why is this hard to implement? | 18:04 |
| alee | bdpayne, I see - so this is a renewal thing .. | 18:04 |
| bdpayne | largely, but could be used for intial generation too | 18:04 |
| bdpayne | seems like, either way, a client could do this via multiple operations | 18:05 |
| alee | its hard because in order to generate a csr, barbican core would need to retrieve the private key to sign the csr. | 18:05 |
| bdpayne | but the plus would be to keep the private key inside barbican rather than needing to pull it out to build a csr | 18:05 |
| alee | which means that the private key would be in memory in barbican | 18:05 |
| bdpayne | sure, but it would be doing that for a user anyway, right? | 18:05 |
| bdpayne | wouldn't that need to happen if I, as a user, requested that priv key anyway? | 18:06 |
| alee | not necessarily -- not if there were some transport key wrapping | 18:06 |
| alee | or we did something like encrypt the key with a passphrase | 18:07 |
| bdpayne | I see | 18:07 |
| bdpayne | but then you are just pushing the problem onto the user, right? | 18:07 |
| bdpayne | user gets priv key | 18:07 |
| *** gyee has quit IRC | 18:08 | |
| bdpayne | user decrypts it | 18:08 |
| bdpayne | user then has to deal with it being in memory, etc | 18:08 |
| alee | bdpayne, yes -- well it is his private key .. | 18:08 |
| alee | bdpayne, the normal way of doing things is to have the user generate a public/private key pair | 18:08 |
| bdpayne | so is the expectation with barbican that the secrets are typically encrypted by the user before storage in barbican? | 18:09 |
| bdpayne | for me, that somehow seems to defeat the purpose, but perhaps I'm missing something | 18:09 |
| alee | not necessarily no | 18:09 |
| alee | but if I were security paranoid, I would want to interact with barbican in a way that was guarenteed to be secure | 18:10 |
| bdpayne | so it sounds like the best path here is just to have an external service that manages the key creation and the csr generation | 18:10 |
| bdpayne | so the difference is saying that you expect each user to secure their stuff, versus asking barbican to do it correctly once | 18:11 |
| bdpayne | but I can solve that by putting some middle ware in between barbican and user | 18:11 |
| bdpayne | so I'm ok with that | 18:11 |
| alee | bdpayne, well - right now, we have the ability to generate a pub/priv key in barbican | 18:12 |
| bdpayne | yes | 18:12 |
| bdpayne | and this is what prompted me to think of this use case | 18:12 |
| alee | bdpayne, and I suppose we could do the stored-key thing by asking the plugins to sign the csr | 18:13 |
| alee | (without extracting the private key) | 18:13 |
| alee | bdpayne, I was just trying to understand the use case -- how can the client use the cert without the private key? | 18:14 |
| bdpayne | certainly the priv key will be needed at some point | 18:14 |
| bdpayne | just trying to limit the back and forth | 18:14 |
| bdpayne | but, like I said, this can be solved in middleware too if it doesn't make sense to do it in barbican | 18:15 |
| alee | bdpayne, it can be solved in barbican if we do what I suggest above .. but if the client will need the private key in any case .. | 18:16 |
| bdpayne | another way to view this... the code that needs to use the priv key in operation is likely different than the code that needs to renew the cert | 18:16 |
| bdpayne | so I think we're talking about different clients | 18:16 |
| dstufft | it certainly seems counterproductive to be designing barbican use cases around the idea that people don't trust barbican to store their secrets | 18:16 |
| bdpayne | perhaps I have one client that needs the priv key to renew the cert | 18:16 |
| bdpayne | and another than needs it for running some service | 18:16 |
| bdpayne | I'd rather just have the one that runs the service and have that cert renewal not need to involve yet another piece of code | 18:17 |
| bdpayne | dstufft yeah (and hi!) | 18:17 |
| *** zz_dimtruck is now known as dimtruck | 18:18 | |
| dstufft | bdpayne: heya :D | 18:18 |
| dstufft | if I don't trust barbican to store a secret then it feels like I'm not much better off than just using a regular dumb oject store | 18:18 |
| alee | dstufft, think of it this way. Part of the reason we want people to use barbican is we expect barbican to be a place where we do secrets and encryption right. | 18:18 |
| dstufft | alee: sure, so why would we expect people to encrypt things before they give them to us? | 18:19 |
| alee | we don't expect barbican to be hacked -- but if it was - we'd expect that it would be doing things in such a way as to not expose secrets if it were. | 18:19 |
| alee | and one way of doing that is not exposing secrets unencrypted in memory | 18:20 |
| dstufft | I mean, I'm sure someone out there will encrypt things before sending them to barbican because people do things that I don't completely understand ;) but it feels like that's going to be a fairly edge case | 18:20 |
| alee | dstufft, well .. once I add transport key wrapping to the barbican client, it will be possible to encrypt all secrets by default through barbican | 18:21 |
| alee | (if someone chooses to) | 18:21 |
| dstufft | alee: won't they then have to manage the secret that decrypts the secrets stored in barbican? | 18:22 |
| alee | dstufft, there is a difference between transport key wrapping and secret pre-encryption | 18:23 |
| bdpayne | but this key wrapping will require a client-side secret, right? | 18:23 |
| alee | transport key wrapping means wrapping the secret with a plugin-side secret | 18:24 |
| alee | so it goes through barbican wrapped to the plugin | 18:24 |
| bdpayne | so the plugin knows the secret, and so does the client? | 18:25 |
| alee | secret pre-encryption means using a client-side secret to pre-encrypt the secret | 18:25 |
| dstufft | alee: I'm not sure I grok what the transport key wrapping thing is, but It seems counterproductive. If the clients are participating in it and they need to have a secret, then it seems like that's just adding back in the thing that barbican is supposed to be managing for people, if it's only happening internal to barbican itself then it seems likt it's not actually doing anything | 18:27 |
| bdpayne | so transport key wrapping is like setting up a TLS tunnel between the client and the plugin? | 18:27 |
| alee | bdpayne, dstufft -- ok -- so let me describe transport key wrapping .. | 18:28 |
| alee | at least how it is done in dogtag .. | 18:29 |
| alee | dogtag drm has a public/private key pair for secret transport | 18:29 |
| alee | it provides the public key to barbican | 18:30 |
| alee | the client gets this public key - and uses it to wrap the secret for storage | 18:30 |
| *** lisaclark1 has quit IRC | 18:30 | |
| alee | then - only the drm (the backend where the secret is to be stored) can decrypt the secret and store it. | 18:30 |
| dstufft | how does the client get the secret back out | 18:31 |
| alee | barbican-core never has the secret exposed. | 18:31 |
| alee | ok .. | 18:31 |
| alee | so barbican client generates a session key and wraps it with the transport public key | 18:31 |
| alee | send that to barbican core - which sends that to the plugin | 18:32 |
| alee | plugin decrypts the session key and wraps the secret with it | 18:32 |
| dstufft | so what stops someone who has hacked barbican core from generating the session key and wrapping it with the transport public key | 18:32 |
| *** lisaclark1 has joined #openstack-barbican | 18:32 | |
| alee | only the client can decrypt the secret -- no one else can decrypt it in between | 18:32 |
| *** tkelsey has quit IRC | 18:32 | |
| bdpayne | so, ignoring my feelings on this scheme for a moment, I imaging that the plugin (dogtag in this case) could generate the CSR | 18:33 |
| bdpayne | and that would remove all concerns of barbican-core having the priv key | 18:34 |
| alee | dstufft, well, thats a completely different attack vector -- I'd think you'd be well and truly screwed if someone could do that | 18:34 |
| alee | bdpayne, yes | 18:34 |
| alee | bdpayne, and thats one approach too. | 18:34 |
| alee | bdpayne, or barbican core can create the csr and the plugin could sign it | 18:35 |
| dstufft | alee: so the attack vector you're worried about is someone who can read arbitrary memory but can't send messages to the dogtag instance pretending to be barbican-core? | 18:35 |
| alee | dstufft, yup | 18:35 |
| bdpayne | basically, they can read, but not write memory | 18:35 |
| bdpayne | in my world, if someone could do that, then they could probably do these other things too | 18:36 |
| bdpayne | alas | 18:36 |
| dstufft | that doesn't sound like a very plasuable attack scenario to me? | 18:36 |
| bdpayne | at least we're all on the same page now | 18:36 |
| dstufft | like it seems like a lot of extra complexity for not a whole lot of benefit | 18:37 |
| bdpayne | I do need to go afk for a few, but have I answered your questions alee? | 18:37 |
| alee | I think so -- like I said - we can do the stored-key thing, -- I was just trying to understand what the use case was | 18:37 |
| bdpayne | ok, cool | 18:38 |
| alee | ie. why the client could not generate the csr. | 18:38 |
| * bdpayne --> afk | 18:38 | |
| *** bdpayne has quit IRC | 18:38 | |
| *** lisaclark1 has quit IRC | 18:39 | |
| alee | dstufft, not sure I agree with that -- but in any case, not having unencrypted secrets outside of say - an HSM - is something that is required for things like common criteria certification. | 18:41 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements https://review.openstack.org/145880 | 18:42 |
| dstufft | alee: well, don't the clients have the secrets unencrypted when they want to use them? | 18:42 |
| alee | dstufft, yes -- but its the clients secret - they are responsible for their own security | 18:43 |
| dstufft | alee: but what i'm saying is, is there any way to actually use a secret that's stored in barbican without having it unecnrypted otuside of an HSM? If they are uncrypted on the client side surely that fails common criteria certification right there? | 18:44 |
| alee | dstufft, think of it as separate security concerns -- there is the security of the storage system -- and the security of the client | 18:45 |
| alee | we're concerned with the former, not the latter | 18:46 |
| dstufft | alee: except it's also the security of the storage system because barbican-core can ask dogtag to decrypt any secret at any time | 18:46 |
| alee | yes | 18:47 |
| dstufft | I guess I'm just having a hard time imagining a scenario where someone can read arbitrary memory but can't also write arbitrary memory | 18:49 |
| *** bdpayne has joined #openstack-barbican | 18:53 | |
| alee | yeah - maybe I'm being over-paranoid .. | 18:54 |
| *** jorge_munoz has quit IRC | 18:55 | |
| alee | dstufft, I can put in a switch -- if someone is worried about CC certifcation - they can always disable this mechanism | 18:56 |
| dstufft | alee: IRC may or may not be a good means for fully descibing the scenario too, and I certainly don't want to say that I'm fully groking what you're getting at with it after thinking about it for 45 minutes. So my thoughts are very much off the cuff with the little bit i know about it. I also don't know much about dogtag in general. Is there a blueprint for this at all? | 18:58 |
| alee | dstufft, the transport key stuff ? thats already in the code base -- at least on the server side | 18:59 |
| alee | (as part of juno) | 19:00 |
| dstufft | ah, I must have missed it then | 19:02 |
| * dstufft goes to dig up the code | 19:02 | |
| alee | dstufft, think about it this way too. Why would I want to use an HSM ? Because I'm security paranoid and I don | 19:02 |
| alee | I don't want my private stuff to be exposed in the clear. Thats what an HSM will guarantee. that my secret will never leave the HSM in the clear. | 19:03 |
| alee | now we're talking about writing code in barbican-core that requires manipulating secrets in the clear | 19:04 |
| dstufft | alee: well, except as long as the client can get the secret out there's no guarentee that the secret will never leave the HSM in the clear | 19:04 |
| dstufft | afaik barbican cannot operate as a HSM, (e.g. I can't get OpenSSL on a client to offload cryptographic operations to it), so comparing it to an HSM doesn't seem super useful | 19:06 |
| dstufft | fundamentally barbican has to have the ability to get the secret in the clear unless you store a secret on the client side, generating a session key on the client side doesn't prevent that because barbican itself can just generate a session key | 19:07 |
| *** jorge_munoz has joined #openstack-barbican | 19:08 | |
| *** kebray has joined #openstack-barbican | 19:09 | |
| *** jorge_munoz has quit IRC | 19:09 | |
| alee | ok .. fair enough .. fwiw, transport key wrapping is also there to protect in case ssl from barbican client to barbican is compromised | 19:10 |
| alee | because sometimes people do dumb things .. like terminate ssl connections before they get to barbican | 19:11 |
| alee | but thats another issue .. | 19:11 |
| dstufft | yea :( | 19:12 |
| alee | (or use bad ciphers etc.) | 19:12 |
| dstufft | if people configuring TLS wrong is in scope for things barbican should protect against we'd probably be better off implementing something generic (e.g. not specific to dogtag) that operates on things as part of the ingress/egress insdie of barbican-core before they pass to the plugins themselves. Namely because if that's something we want to protect against we probably want to protect against it in situations where people aren't | 19:14 |
| dstufft | using dogtag as well | 19:14 |
| dstufft | (although I recognize that the scheme would certainly protect against that if someone is using dogtag in that way) | 19:15 |
| alee | dstufft, well the scheme is pretty generic -- its just based on public/private key and an asn.1 structure | 19:16 |
| alee | dstufft, anyways - one thing I was going to think about is adding transport key support to the default barbican plugins -- but thats L at least | 19:18 |
| *** paul_glass has joined #openstack-barbican | 19:20 | |
| dstufft | alee: I'm not saying the scheme itself couldn't be adapted elsewhere, just that as I understand it, it currently relies on using dogtag in a specific configuration for it to be used, and if it's something that barbican should seriously be protecting against then we probably should do it a layer above the plugins (although I don't personally really think "I didn't deploy barbican sanely" is something that's worth adding extra | 19:20 |
| dstufft | mechanisms for) | 19:20 |
| *** kgriffs is now known as kgriffs|afk | 19:22 | |
| alee | ok | 19:22 |
| alee | gotta get lunch .. | 19:23 |
| *** alee is now known as alee_late_lunch | 19:23 | |
| *** paul_glass1 has joined #openstack-barbican | 19:24 | |
| *** paul_glass has quit IRC | 19:27 | |
| *** atiwari has joined #openstack-barbican | 19:28 | |
| *** atiwari1 has joined #openstack-barbican | 19:29 | |
| *** bdpayne has quit IRC | 19:45 | |
| *** bdpayne has joined #openstack-barbican | 19:46 | |
| *** lisaclark1 has joined #openstack-barbican | 19:47 | |
| *** lisaclark1 has joined #openstack-barbican | 19:47 | |
| *** paul_glass1 has quit IRC | 19:48 | |
| *** kgriffs|afk is now known as kgriffs | 19:48 | |
| *** atiwari1 has quit IRC | 19:51 | |
| *** atiwari has quit IRC | 19:51 | |
| *** atiwari has joined #openstack-barbican | 19:52 | |
| *** atiwari1 has joined #openstack-barbican | 19:52 | |
| *** atiwari1 has quit IRC | 19:54 | |
| *** atiwari has quit IRC | 19:54 | |
| *** atiwari has joined #openstack-barbican | 19:54 | |
| *** atiwari has quit IRC | 19:54 | |
| *** atiwari has joined #openstack-barbican | 19:55 | |
| *** kgriffs is now known as kgriffs|afk | 20:03 | |
| *** kgriffs|afk is now known as kgriffs | 20:09 | |
| *** atiwari has quit IRC | 20:13 | |
| *** paul_glass has joined #openstack-barbican | 20:17 | |
| *** paul_glass has quit IRC | 20:22 | |
| *** alee_late_lunch is now known as alee | 20:24 | |
| *** jorge_munoz has joined #openstack-barbican | 20:29 | |
| *** jorge_munoz has joined #openstack-barbican | 20:35 | |
| *** jorge_munoz has quit IRC | 20:44 | |
| *** lisaclark1 has quit IRC | 20:53 | |
| *** david-lyle has joined #openstack-barbican | 20:54 | |
| *** csoukup has joined #openstack-barbican | 20:55 | |
| *** bdpayne has quit IRC | 20:57 | |
| *** bdpayne has joined #openstack-barbican | 20:58 | |
| *** paul_glass has joined #openstack-barbican | 21:12 | |
| *** paul_glass has quit IRC | 21:16 | |
| *** jamielennox|away is now known as jamielennox | 21:24 | |
| *** lisaclark1 has joined #openstack-barbican | 21:29 | |
| *** jorge_munoz has joined #openstack-barbican | 21:34 | |
| *** lisaclark1 has quit IRC | 21:34 | |
| *** nkinder has quit IRC | 21:43 | |
| *** ryanpetrello has quit IRC | 21:53 | |
| *** bdpayne has quit IRC | 21:55 | |
| *** crc32 has joined #openstack-barbican | 22:06 | |
| openstackgerrit | Merged openstack/barbican: Moving exception logging in the base behaviors https://review.openstack.org/145835 | 22:09 |
| *** bdpayne has joined #openstack-barbican | 22:24 | |
| *** alee has quit IRC | 22:24 | |
| *** david-lyle has quit IRC | 22:28 | |
| *** SheenaG1 has quit IRC | 22:29 | |
| *** tkelsey has joined #openstack-barbican | 22:31 | |
| *** tkelsey has quit IRC | 22:35 | |
| *** nkinder has joined #openstack-barbican | 22:37 | |
| *** crc32 has quit IRC | 23:06 | |
| *** csoukup has quit IRC | 23:12 | |
| *** kgriffs is now known as kgriffs|afk | 23:33 | |
| *** kgriffs|afk is now known as kgriffs | 23:37 | |
| *** SheenaG1 has joined #openstack-barbican | 23:38 | |
| *** alee has joined #openstack-barbican | 23:39 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!