20:00:42 <redrobot> #startmeeting barbican
20:00:43 <openstack> Meeting started Mon Aug 10 20:00:42 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:46 <openstack> The meeting name has been set to 'barbican'
20:00:55 <redrobot> #topic Roll Call
20:01:01 <rellerreller> o/
20:01:03 <chellygel> ヽ(⌐■_■)ノ♪♬
20:01:04 <jvrbanac> o/
20:01:08 <dave-mccowan> \o/
20:01:09 <hockeynut> o/
20:01:10 <silos1> o/
20:01:18 <arunkant> o/
20:01:29 <elmiko> (ﾉ´ヮ´)ﾉ*:･ﾟ✧
20:01:32 <jhfeng> o/
20:01:37 <chellygel> elmiko, lmao <3
20:01:39 <igueths> o/
20:01:48 <pkazmir> o/
20:01:49 <elmiko> chellygel, totally inspired by you =)
20:02:13 <redrobot> lol
20:02:17 <pkazmir> heh
20:02:25 <redrobot> awesome, lots of barbicaneers here today
20:02:41 <redrobot> #topic Review Action Items from last meeting
20:02:42 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-08-03-20.00.html
20:03:06 <redrobot> looks like that redrobot guy had a lot to do... and didn't do any of it...
20:03:25 <redrobot> in my defense we did have a mid-cycle since last week
20:03:35 <woodster_> o/
20:03:45 <redrobot> so I'll be doing those things this week
20:03:51 <redrobot> redrobot to finish prioritizing liberty-2 bugs, and also check them for kilo status
20:03:54 <redrobot> #action redrobot to finish prioritizing liberty-2 bugs, and also check them for kilo status
20:04:01 <redrobot> #action redrobot to fix the stable/kilo gate failures during mid-cycle
20:04:27 <redrobot> ^^ regarding the broken gate, I'll actually be looking into that right after the meeting
20:04:32 <pkazmir> Do we have any new action items to add based on the midcycle?
20:04:45 <redrobot> #action redrobot and alee to backport the DogTag gate fixes into stable/kilo after redrobot fixes the gate
20:04:54 <redrobot> pkazmir good question
20:05:15 <redrobot> pkazmir I'll cover action items from the mid-cycle next
20:05:20 <alee> o/
20:05:20 <pkazmir> k
20:05:34 <redrobot> ok, moving on to the actual agenda
20:05:58 <redrobot> which we don't have anything on this time around... so I'll be making up topics as we go
20:06:05 <redrobot> #topic Mid-Cycle Sprint Recap
20:06:16 <redrobot> We had our mid cycle last week
20:06:33 <redrobot> many thanks again to the JHAPL folks!
20:06:37 <redrobot> it was a great success
20:06:41 <redrobot> #link https://etherpad.openstack.org/p/barbican-liberty-midcycle
20:06:43 <pkazmir> +1000
20:07:09 <rellerreller> Glad everyone enjoyed it :)
20:07:11 <redrobot> we have a lot of action items that came out of the discussions.  The've all been captured in the etherpad
20:07:38 <hockeynut> awesome job rellerreller and kfarr - especially thanks for arranging cool weather for us Texans!
20:07:48 <elmiko> impressive etherpad, well done all
20:08:04 <redrobot> I'll be reviewing the etherpad in the next few days and emailing everyone who signed up for action items, so you don't have to dig through the whole thing to figure out what you signed up for.
20:08:11 <woodster_> 346520
20:08:29 <redrobot> elmiko we had an awesome note-taker
20:08:41 <alee> rellerreller, +1000 for pluto tour .its going to hard to top that ..
20:08:50 <chellygel> ^
20:08:52 <elmiko> redrobot, well, get that person an extra helping of "hell yeah" ;)
20:09:06 <redrobot> elmiko hehe, will do!
20:09:48 <redrobot> As far as this cycle is concerned, we did not add any blueprint exceptions, so all pending blueprints should be moved to a new M directory
20:10:03 * redrobot tries to remember what M is called...?
20:10:15 <silos1> Mitaka??
20:11:20 <redrobot> silos1 I think you may be right...
20:11:51 <redrobot> on the Castellan front, we reviewed some of the pending CRs and will be doing just a little more work on those before we land them
20:12:07 <kfarr> Working on them now!
20:12:07 <redrobot> rellerreller i think we're going to use bytes instead of bytearrays?
20:12:16 <rellerreller> redrobot yes
20:12:51 <rellerreller> Removing get_format and changing get_encoded to take an optional format parameter
20:13:03 <kfarr> I don't think format needs to be removed?
20:13:29 <redrobot> rellerreller kfarr  correct... I think it's still valuable to keep a format property around to know what the current format of the secret is
20:13:41 <rellerreller> If can call get_encoded to return in different formats then I do not think it is needed.
20:14:03 <kfarr> but format is things like "PKCS#8" and "X.509"
20:14:20 <kfarr> and get_encoded will take parameters like "DER" vs "PEM"
20:14:27 <rellerreller> Right those would be passed to get_encoded.
20:14:28 <kfarr> or am I misunderstanding :( :(
20:14:49 <rellerreller> Always returning DER because API says returns bytes
20:15:15 <redrobot> hmm.... I think kfarr makes a good point...
20:15:33 <redrobot> I think maybe to unblock these, we can keep format for now, and then add the optional parameter later
20:15:54 <redrobot> for now get_encoded wouldn't take any parameters and return the DER of whatever format the secret is in
20:15:59 <kfarr> OK :)
20:16:13 <redrobot> we can then discuss whether format and encoding need to be two separate things
20:16:17 <redrobot> ie,
20:16:27 <redrobot> get_encoded(format='pkcs8', encoding='der')
20:16:52 <woodster_> just glad this isn't a content-types discussion
20:16:52 <redrobot> rellerreller sound good to you?
20:17:18 <redrobot> woodster_ only mildly related... once we nail this we'd have ammo for exactly which content types we need ;)
20:17:26 <rellerreller> OK, so keep get_format and get_encoded does not take any arguments. I'm ok with that.
20:17:43 <redrobot> rellerreller well, rename get_format to just format, but yes
20:17:55 <rellerreller> OK, sounds good to me
20:18:14 <kfarr> That means https://review.openstack.org/#/c/191884/11 is already good to go!
20:18:23 <redrobot> #agreed move forward with format and no arguments to get_encoded in current castellan CRs
20:18:37 <redrobot> kfarr woot!  I'll review it after the meeting.
20:19:36 <redrobot> another important topic to come out of the mid-cycle is the need to simply deployment
20:19:48 <redrobot> and the eventual split of barbican-kms and barbican-cms
20:20:17 <redrobot> the problem now is that someone who wants to deploy Barbican has to figure out both the secure storage part, as well as flesh out a Certificate Authority story
20:20:51 <redrobot> as we look forward to Federation of Barbican secrets, then forcing everyone to stand up CA to deploy Barbican seems to be very burdensome
20:20:58 <redrobot> especially if all you want is to federate secrets
20:21:42 <redrobot> so we'll start having v2 conversations in the next summit, to separate the api for KMS from the api to do Cert management.
20:23:08 <redrobot> any questions, or other highlights from the midcycle worth mentioning?
20:24:08 <alee> redrobot, is there going to be a blueprint/spec for the v2 specification?
20:24:18 <rellerreller> Barbican federation is on the horizon
20:24:32 <alee> redrobot, or are we just leaving it to etherpads for now?
20:24:43 <redrobot> alee yes, jvrbanac took the action item to put up a spec to the spec repo
20:24:44 <rm_work> redrobot: if cert generation was included in the Castellan interface, the split would be easy <_<
20:24:57 <rm_work> redrobot: because you could just switch from using a barbican impl to a "whatever else" impl
20:24:57 <elmiko> lol
20:25:18 <redrobot> rm_work I think the idea is for Castellan to only provide KMS features
20:25:23 * rm_work is still a little annoyed at not even getting so much as a ping when that discussion happened
20:25:52 <alee> redrobot, jvrbanac - I'm assuming that migration will be a part of that spec
20:26:18 <rm_work> redrobot: would you help me set up the infrastructure (repo, pypi, etc) for castellan-certs ?
20:26:52 <rm_work> redrobot: it's probably going to have to happen, at this point i really just don't have experience with setting that stuff up and it's the major blocker for me as i'm low on time
20:27:23 <redrobot> rm_work we can talk about that as a topic later this meeting if you'd like.
20:27:28 <rm_work> kk
20:27:53 <redrobot> alee yeah, migration, or rather v1 deprecation plans would have to be part of the spec
20:28:32 <jvrbanac> redrobot, we didn't decide on who would do the spec yet
20:28:44 <redrobot> jvrbanac I do believe Lisa signed you up for that
20:29:19 <redrobot> jvrbanac I'll double check my notes though.
20:29:59 <jvrbanac> redrobot, it was to start an etherpad
20:30:29 <redrobot> jvrbanac we did have a conversation about an etherpad being way too messy for this process.... I think it would be best to have a spec
20:30:39 <alee> redrobot, jvrbanac it would be awfully nice to have something to chew on by the time the summit comes around - some of these conversations are more easily accomplished face to face.
20:31:03 <alee> assuming of course that most folks will be at the summit -- which is perhaps not a good thing to assume
20:31:40 <redrobot> jvrbanac though now that I think of it, it may just have been a conversation between me and Lisa....  so yeah, a Spec would be much nicer I think.
20:34:37 <redrobot> ok, sounds like we don't have any more highlights and/or questions about the mid-cycle
20:34:41 <redrobot> moving on
20:34:45 <redrobot> #topic Castellan for certs
20:35:09 <rm_work> So, I have said this before, and I'll say it again -- I feel like I'm taking crazy pills here
20:35:27 <rm_work> the "lack of use cases" statement is astoundingly ignorant
20:35:28 <woodster_> Step 1 is admitting you have a problem :)
20:35:33 <woodster_> jk!!!
20:35:35 <redrobot> lol
20:35:36 <rm_work> and if i seem a little frustrated, it's because i am a little frustrated
20:35:45 <rm_work> sorry, very frustrated
20:35:58 <rm_work> i am thinking maybe i made this into too much of a joke or something earlier
20:36:20 <redrobot> so, fundamentally, Castellan is providing an interface for secret storage so that a project is not tied to Barbican and can use something else instead.
20:36:30 <rm_work> yes
20:36:36 <redrobot> so, for secret storage
20:36:46 <rm_work> it was SUPPOSED to be "Secret and Certificate storage"
20:36:47 <rm_work> which
20:36:47 <redrobot> that something else could be a KMIP device, or a PKCS#11 device.
20:36:54 <woodster_> rm_work: it does seem like the stovepiped code for your use case should find a home someplace
20:37:17 <rm_work> had i been more vigilant when we were making this spec to begin with, would have noticed the wording was changed from what we originally discussed verbally
20:37:22 <redrobot> well, as woodster_ would say "The Devil is in the details"
20:37:25 <rm_work> but that's old news
20:37:47 <redrobot> the thing is you don't just want to store a cert
20:37:53 <rm_work> and i have proven several times, i thought, that i could store whatever i want, including cert constructs, in whatever device i was presented
20:38:25 <redrobot> you want to store a cert in addition to it's private key and public ca cert, intermediates and possibly a passphrase as a single bundle
20:38:38 <rm_work> there's also nothing that says that every implementation has to exist for every interface
20:38:44 <rm_work> i think maybe that is a misunderstanding
20:38:54 <rm_work> obviously there wouldn't be an anchor driver for secret storage...
20:39:05 <rm_work> just like maybe there wouldn't be a barbican driver for cert generation
20:39:38 <rm_work> though they could make use of each other internally (as I have gone over on whiteboards with woodster_ previously)
20:39:41 <redrobot> then what's the benefit of a lowest common denominator interface, if there's no guarantee that what you put behind it will actually do all the things it needs to do?
20:39:58 <rm_work> they weren't designed to be the same thing
20:40:18 <rm_work> Castellan would have options for which impl would be used for each piece
20:40:40 <rm_work> if you ever looked at the existing code that I proposed for castellan-certs, it already did that for generation vs. storage
20:40:47 <elmiko> why can't castellan have a castellan.cert_manager akin to castellan.key_manager? the api_class would be different for both modules?
20:40:59 <rm_work> exactly this ^^
20:41:17 <elmiko> (also enjoys crazy pills)
20:41:19 <elmiko> ;)
20:41:21 <rm_work> there is a cert_manager_impl defined, and a key_manager_impl, and a cert_generator_impl
20:41:30 <rm_work> you can mix and match
20:41:46 <rm_work> and they can use each other ALSO at the abstract level
20:41:49 <kfarr> What's the difference between cert_manager_impl and key_manager_impl ?
20:42:11 <redrobot> I think that this discussion boils down to this question:
20:42:17 <rm_work> cert_manager_impl could use certmonger which could turn back around and use key_manager_impl
20:42:24 <rm_work> if it wanted to
20:42:42 <rm_work> but probably cert_manager_impl would *use* key_manager_impl
20:42:43 <redrobot> why do you want to store a cert bundle as a single thing, instead of using castellan.key_manager to store the different pieces?
20:43:37 <redrobot> I understand the barbican use case that an OpenStack user can upload a cert-container and just pass a single reference to lbass, instead of 3 (or 4) references to the separate things
20:43:51 <rm_work> well, my original plan was to use cert_generator_impl and key_manager_impl and include the cert functions in there, but as you pointed out, there was pushback to that
20:44:11 <redrobot> there's push back to bundling a certificate
20:44:27 <redrobot> I think we all agreed that a cert, by itself, could be one of the managed objects in castellan
20:44:37 <rm_work> so you disagree at a very high level that Openstack should not have the concept of a Certificate bundle?
20:44:56 <rm_work> is that what's really at issue?
20:45:20 <rm_work> if that's the problem, then we disagree *fundamentally*
20:45:24 <redrobot> that's the argument against putting a bundle in castellan... because the only system we know that can bundle certs like that is Barbican
20:45:25 <rm_work> and this is a bigger problem than I thought :/
20:45:33 <rm_work> redrobot: ANY SYSTEM CAN BUNDLE CERTS
20:45:40 <rm_work> i don't know how many hundreds of times i have to explain that
20:45:56 <rm_work> I could bundle certs in pure KMIP
20:46:00 <rm_work> I could bundle certs in LDAP
20:46:24 <kfarr> rm_work, how would you bundle certs in KMIP?
20:46:59 <rm_work> there are a couple of options
20:47:04 <woodster_> I've been thinking the cert manager would support storing a bundled cert into key storage, perhaps without the key storage knowing (or caring) it was storing such a bundle
20:47:11 <rm_work> ^^ this
20:47:40 <rm_work> the naive approach is to literally tack them on to each other in a predefined order and store them all together
20:48:05 <woodster_> I've been thinking this functionality would be more of a support/utility feature set in addition to castellan
20:48:07 <rm_work> another naive approach is to store them all as seperate entities and then store a "container secret" with references to all of the other ones, using JSON or something
20:48:23 <rm_work> and then the reference to that is the "cert bundle"
20:48:42 <rm_work> or PKCS12 if KMIP supports complex structures (though I don't think it does?)
20:49:17 <kfarr> I don't think it does in 1.2
20:49:19 <rm_work> "A KMIP server stores and controls Managed Objects such as Symmetric and Asymmetric keys, Certificates, and user defined objects."
20:49:24 <rm_work> the key here being "user defined objects"
20:50:03 <rm_work> if I can store whatever I want, then it is *trivial* to store a cert bundle
20:50:33 <arunkant> rm_work, is castellan cert manager supposed to generate certs or just provide cert storage parts? Is it expected to integrate with barbican, considering its not synchronous flow?
20:50:46 <rm_work> arunkant: i was proposing TWO interfaces, cert_manager and cert_generator
20:51:27 <rm_work> it could integrate with barbican or not, but it wouldn't matter, as cert_generator would utilize cert_manager for storage, and cert_manager could utilize key_manager for storage if it wanted to
20:51:45 <rm_work> or it could be done all independently... totally up to the implementation
20:51:50 <arunkant> rm_work, okay..so cert_generator will talk to Barbican then for cert generation?
20:52:00 <rm_work> if you used that implementation
20:52:10 <rm_work> or it could talk to Anchor, or certmonger, or dogtag directly
20:52:53 <rm_work> the only issue is that I will fully admit this ventures into the territory of "becoming a cert manager akin to what barbican was doing in the first place"
20:52:54 <woodster_> rm_work: just curious, is the code that has been copy/pasta-ed into the various projects changed much from the original castellan CR you had up?
20:53:03 <arunkant> rm_work, but that impl will be quite different from certmonger as barbican's async behavior
20:53:05 <rm_work> it has evolved a little bit
20:53:16 <rm_work> arunkant: yeah, so that is one issue -- is it sync or async
20:53:26 <rm_work> and is sync even feasible for anything but anchor
20:53:52 <redrobot> probably not... any real CA is going to have some process for an RA to approve/deny cert requests.
20:54:09 <rm_work> woodster_: the two repos the code exists in now have actually diverged a bit, which is not great -- that's another motivator for me to get it centralized ASAP
20:54:43 <rm_work> redrobot: cert_generator by far poses the greatest issue, and it's possible that cert_generator might just be whatever new project Barbican splits cert_generation into
20:55:04 <rm_work> cert_manager though seems like a braindead simple decision to include though
20:55:17 <redrobot> we're running out of time for today
20:55:20 <rm_work> s/though//
20:55:24 <redrobot> and I don't think rellerreller is still around
20:55:34 <woodster_> well, async can be brute-force turned into a sync. Dogtag directly could support sync as well.
20:55:57 <rm_work> i think everyone is paralyzed in fear that including a cert interface would somehow jeapardize the integrity of the existing key interface, and i just don't think that's the case
20:56:02 <redrobot> so I don't want to make a decision now...  rm_work will you be available to continue this as the first topic next week?
20:56:04 <woodster_> so would a separate project to hold the cert stuff answer the need here?
20:56:05 <rm_work> woodster_: yeah i was going to mention that but it's ugly
20:56:10 <rm_work> redrobot: yes probably
20:56:24 <rm_work> woodster_: ^^ the async->sync thing
20:56:36 <redrobot> rm_work k, let's punt to next week though and get feedback from rellerreller about a possible cert_manager in a separate namespace.
20:56:41 <rm_work> that actually IS the current solution -- polling, in the case of Barbican
20:56:43 <kfarr> rm_work, do you have this written up somewhere?
20:56:51 <rm_work> kfarr: i have code implemented >_>
20:56:57 <woodster_> do we need (dare I say it) an etherpad for this? :)
20:57:08 <rm_work> that is in use by two projects already
20:57:13 <rm_work> and has been for about 8 months
20:57:22 <kfarr> key manager, cert manager, cert generator?
20:57:26 <rm_work> the latter two
20:57:33 <rm_work> which are modeled directly from cinder's key manager
20:57:42 <rm_work> with the explicit intention of coexisting
20:57:48 <pkazmir> (Don't pull a Woody!)
20:57:59 <woodster_> pkazmir: ha!
20:58:28 <rm_work> things have changed a bit, and a lot of my motivation to see all your CRs land for Castellan was so I could finally get to work updating them
20:58:42 <rm_work> and actually make something that could be submitted to the current Castellan landscape
20:58:52 <rm_work> kfarr: ^^
20:58:56 <alee> rm_work, I understand what  you are trying to do - we also need to consider how this affects plans for migration to v2
20:59:09 <rm_work> alee: i think it couldn't possible hinder migration
20:59:22 <rm_work> and in fact it seems that it would actually open up easy avenues for migration
20:59:27 <woodster_> alee: I'd think it is just which endpoints you hit under the hood (for the KMS/CMS servers that is)
20:59:27 <redrobot> rm_work let's plan on getting kfarr's crs landed this week so you can have a CR up for discussion next week.
20:59:32 <rm_work> redrobot: kk
20:59:42 <dave-mccowan> Please review this quota support CR: https://review.openstack.org/#/c/205894/   it's the foundation for the rest of the quotas code, so I'd like to get it stable ASAP to make sure the full blueprint is implemented in Liberty.
20:59:45 <redrobot> alright guys, we're out of time here
20:59:48 <redrobot> thanks for coming!
20:59:49 <rm_work> if the discussion is monday, that'll be cutting it close if we don't merge those SOON :P
20:59:54 <alee> woodster_, yes and no -- in v2 we're talking about eliminating cert containers
21:00:02 <redrobot> #endmeeting