20:04:06 <redrobot> #startmeeting barbican
20:04:07 <openstack> Meeting started Mon Nov 17 20:04:06 2014 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:04:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:04:11 <openstack> The meeting name has been set to 'barbican'
20:04:19 <hyakuhei> o/
20:04:21 <chellygel> \o/
20:04:24 <reaperhulk> o/ \o
20:04:27 <tkelsey> hey all
20:04:38 <chellygel> portal hi-five reaperhulk ?
20:04:42 <redrobot> gotta love Daylight Savings Time :)
20:05:08 <redrobot> As usual the agenda can be found here:
20:05:09 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:05:52 <redrobot> Ok, let's get started
20:05:57 <redrobot> #topic RFC 7030
20:06:11 <redrobot> #link https://tools.ietf.org/html/rfc7030
20:06:32 <redrobot> And here are some notes from alee
20:06:35 <redrobot> #link https://etherpad.openstack.org/p/thoughts_on_certs
20:06:41 <hyakuhei> Anyone know if there's a decent 7030 protocol diagram anywhere?
20:07:10 <dave-mccowan> hello.  i'm the guy who brought up EST at summit.  I think it fits well for the use cases described, but is quite different standard Barbican API.
20:07:24 <redrobot> hi dave-mccowan
20:07:44 <dave-mccowan> Apendix of RFC shows example flows.  All request/response.
20:07:53 <hyakuhei> Yeah, EST fits but it's very different. Do many people use EST at the moment ?
20:08:17 <hyakuhei> s/EST/7030/Certificate requests over secure transport/
20:08:35 <redrobot> so we've mostly agreed that adding a new barbican secret-store plugin that can speak  EST makes sense
20:09:01 <dave-mccowan> Our hope is that current SCEP users will migrate to EST.  It fixes some holes and adds ECDSA support.
20:09:03 <redrobot> the open question was whether this makes sense to use as a front end for Barbican
20:09:32 <hyakuhei> Well SCEP is completely horrible and broken.
20:09:34 <rellerreller> redrobot what do you mean by a new secret-store plugin?
20:09:46 <rellerreller> Do you mean creating a new interface?
20:10:12 <redrobot> rellerreller no, I mean a new implementation of SecretStore that can talk to EST devices/services.
20:10:49 <tkelsey> redrobot: so an additional SecretStore plugin? like the KMIP one?
20:10:57 <dave-mccowan> I could see it either 1) EST as front end for Barbican.  or  2) take all the parameters of EST, and put them in JSON format under the order API as a front end.
20:11:29 <hockeynut> made it :-)
20:11:42 <rellerreller> Would the secret store interface need to be changed to support this?
20:11:55 <redrobot> tkelsey yes
20:12:11 <hyakuhei> Ok, so there's two conversations here. I'd like them separate. One seems to be, should we have a secret store plugin for talking to CA type things that use RFC 7030. The second is one around should we expose 7030 towards client systems that want to request certificates ... ?
20:12:39 <rellerreller> hyakuhei I think that sums it up
20:12:52 <redrobot> hyakuhei +1
20:12:53 <hyakuhei> ok, so lets pick one and talk about it :P
20:13:01 <rellerreller> Should we discuss the exposing of 7030 interface first?
20:13:17 <redrobot> rellerreller sounds good.
20:13:32 <redrobot> #topic Using RFC 7030 as a front end for Barbican
20:14:18 <hyakuhei> Ok, so it seems to me that most of the time you expect clients to use Barbican client, which makes the protocol just a plumbing issue. The caveat is systems like Certmonger that manage certificates. They probably support 7030 and it'd be nice if Barbican exposed that for them
20:14:47 <hyakuhei> I'm not very familiar with 7030 at all but how would we handle AuthN in the case of 7030 at the interface ?
20:14:54 <hyakuhei> IE Keystone.
20:16:01 <redrobot> hyakuhei I think that's one of the open questions.  Whether 7030 can handle multi tenancy?
20:16:09 <redrobot> dave-mccowan could you speak to that?
20:16:10 <hyakuhei> Ok.
20:16:39 <hyakuhei> Also, is there anything other than Certmonger that we expect to use this because Certmonger can be pretty easily extended to support any interface
20:16:50 <hyakuhei> Case in point: We use certmonger with ephemeral CA
20:17:08 <dave-mccowan> The protocol is flexible for different authentication methods.  a keystone auth token could be used as credentials in a certificate enroll request.
20:18:09 <rellerreller> dave-mccowan is that covered by "HTTP-Based Client Authentication"?
20:18:25 <dave-mccowan> rellerreller yes
20:18:38 <rellerreller> I tried reading the spec today but was distracted many times and was only able to skim it.
20:19:32 <rellerreller> dave-mccowan it seems like you could put anything in that section and if backed in can read it then AuthN works.  Is that correct?
20:20:11 <hyakuhei> I like the idea of using certmonger though it should be stressed that Certmonger could be used in either the current or proposed 7030 schemes
20:20:17 <dave-mccowan> rellerreller yes.
20:20:42 <redrobot> I was hoping alee would be joining us... but I guess I can just steal talking points from his notes I linked earlier
20:21:07 <dave-mccowan> for backends, i have plugins (in C) for Dogtag and for "file system based CA".
20:21:20 <redrobot> one of Ade's concerns was that 7030 is very different from what we've already implemented in Barbican
20:21:37 <jaosorior> actually, I very much dig the idea of using certmonger
20:21:51 <hyakuhei> It handles certificate lifecycle relatively well
20:21:55 <jaosorior> hooking up a barbican plugin to it shouldn't be too hard
20:22:09 <hyakuhei> Agreed
20:22:30 <redrobot> One example that Ade gives is that we currently have logic to continuously poll a CA for the certificate until it's issued, then the cert and intermediates are stored in Barbican
20:22:34 <alee> o/
20:22:39 <jaosorior> yay :D
20:22:41 <hyakuhei> :D
20:22:48 <alee> sorry - I got confused on the time.
20:22:59 <alee> thought it was 40 mins from now.
20:23:14 <redrobot> alee no worries, woodster was also expecting it at CST
20:23:15 <woodster_> o/ Ha, same with me
20:23:39 <reaperhulk> Okay, let's restart on this question because I think we've kind of been drifting down paths that may not be important just yet
20:24:00 <hyakuhei> Does it make sense to support 7030 for certificate requests from client systems?
20:24:03 <reaperhulk> RFC 7030 defines a set of endpoints and various semantics for sending CMC data to CAs. CMC is defined in RFC 5272
20:24:25 <reaperhulk> From what I can tell CMC does not have provisions for defining what CA you want to have issue your certificate. The assumption is that you're sending it to something that already knows.
20:24:58 <reaperhulk> alee's thoughts in his etherpad cover this by saying we could potentially pass CMC data as metadata, but I'm interested in others' thoughts as well.
20:25:09 <hyakuhei> Yeah that's an interesting gocha
20:25:38 <hyakuhei> I'm not sure that implementing 7030 buys all that much apart from making it easier for one or two client libraries to use Barbican.
20:25:52 <hyakuhei> Which could just as easily be extended to 'speak' the current scheme
20:26:17 <rellerreller> So we are saying we want to support multiple CAs? That seems to be the assumption but with secret stores we only use one.
20:26:18 <rm_work> yeah, 7030 is very inconsistent with the current API strategy :/
20:26:39 <chellygel> rellerreller, i believe so, yes -- the idea was that the user would have multiple CAs
20:26:42 <hyakuhei> We _absolutely_ want to be able to support multiple CA's at the same time
20:26:45 * rm_work agrees with alee's assessment in general
20:27:06 <chellygel> rellerreller, i user may want an internal CA and an external CA -- or multiple internals... or something of that nature
20:27:27 <hyakuhei> chellygel: +1
20:27:27 <alee> rellerreller, we definitely want to support multiple ca's/   at some poitn , we'll even have the ability to do subca's within the same dogtag instance.
20:27:29 <rellerreller> OK, that is cool with me, but I like to ask the obvious questions sometimes to make sure the requirement is clear :)
20:27:31 <woodster_> I think the CA flavor concept in Ade's blueprint could assist there: https://review.openstack.org/#/c/129048/
20:29:10 <redrobot> I agree with hyakuhei that it doesnt seem that 7030 buys us much in the front end.
20:29:37 <alee> playing devils advocate here, the advantage of implementing rfc 7030 is that we have something that is "standard" - which presumably more and more clients will eventually implement.
20:29:43 <hyakuhei> It's nice to have things that 'just work' but a lot needs to change
20:29:48 <hyakuhei> alee: True
20:29:51 <hyakuhei> but take KMIP
20:30:02 <hyakuhei> currently there are _two_ evaluated complient KMIP servers
20:30:02 <alee> but this is pretty new -- and not a lot of folks have implemented this yet I think
20:30:12 <hyakuhei> and that's been around for a while
20:30:30 <alee> yup
20:31:01 <hyakuhei> So there's possibly a side case to make Certmonger play nicely with Barbican ?
20:31:09 <hyakuhei> As it seems like a useful thing to do
20:31:22 <alee> hyakuhei, I think thats the direction we should go.
20:31:36 <redrobot> hyakuhei yes, there's been interest in certmonger->barbican functionality.
20:32:08 * reaperhulk agrees
20:32:15 <alee> hyakuhei, certmonger already does a lot of things that we would need to add to barbican-client and has been around for awhile now
20:32:37 <alee> things like cert lifecycle management
20:32:49 <reaperhulk> RFC 7030 compliance on the front end would require some API that allows a user to provision that endpoint and specify what CA they want it bound to, etc. Same applies for a KMIP frontend. I think those are nice to haves but low priority
20:33:19 <hyakuhei> alee: Yup, that's what we use it for, managing the whole lifecycle.
20:33:38 <redrobot> reaperhulk +1
20:34:13 <redrobot> I think we're mostly in agreement that 7030 in the front end might be nice at some point, but not for Kilo.
20:34:18 <hyakuhei> +1
20:34:20 <jvrbanac> +1
20:34:32 <tkelsey> seems reasonable
20:34:34 <woodster_> Does anyone disagree that this is lower priority for K at least?
20:34:45 <alee> reaperhulk, its also inconsistent with what we have -- ie. if the cert is pending, the semantics are different
20:35:00 <alee> it does not deal with "orders" etc.  ..
20:35:02 <reaperhulk> yeah, the CMC resubmission stuff
20:35:04 <reaperhulk> agreed
20:35:26 <hyakuhei> I kinda like rsubmission over some shared ID thing
20:35:34 <hyakuhei> but that's another conversation ;)
20:35:36 <dave-mccowan> to clarify, is there a different certificate front end that would be targeted for Kilo?
20:36:10 <redrobot> dave-mccowan yes, we'll continue to flesh out the Orders api for "certificate" type orders.
20:37:00 <dave-mccowan> redrobot cool.  i'd like to volunteer to help with that this cycle.
20:37:23 <redrobot> #agreed RFC 7030 as a Barbican front end would be nice, but low priority for Kilo
20:37:32 <redrobot> I think we can move on to the next question?
20:37:41 <hyakuhei> Backend support?
20:37:57 <redrobot> #topic RFC 7030 as a new certificate backend.
20:38:03 <redrobot> hyakuhei yes.
20:38:04 <woodster_> dave-mccowan, in particular, we'd like to finalize what is going into the 'meta' field for certificate orders. So Ade's possible approach for using CMCRequest would be somethign to consider: https://etherpad.openstack.org/p/thoughts_on_certs
20:38:30 <hyakuhei> woodster_: Is this going back to the first question?
20:38:38 <alee> woodster_, +1 yes -- I'd like to talk about that as well next.
20:38:46 <woodster_> yep, sorry, bled over into the next topic
20:38:58 <redrobot> alee I'll add that to the agenda.
20:39:44 <hyakuhei> ok. what are we talking about now then? \
20:40:01 <redrobot> hyakuhei 7030 as a CertificatePlugin
20:40:08 <hyakuhei> Ok
20:40:25 <woodster_> So client -> barbican -> 7030 service, correct?
20:40:27 <hyakuhei> So are there any CA endpoints that support it today (obvious question)
20:40:49 <alee> redrobot, its an interesting idea - but on the whole, I'm not sure how useful.  rfc7030 is a specification for an RA
20:41:06 <alee> and thats exactly what barbican would be.
20:41:44 <alee> its more like client -> barbican -> 7030 RA -> CA
20:42:05 <hyakuhei> Sure but functionally a client just sees 7030 -> CA/RA
20:42:19 <hyakuhei> because they throw a CMC in and either get a Cert back or a nack
20:42:38 <alee> hyakuhei, thats only if we support 7030 on the front end
20:42:58 <hyakuhei> hmm.
20:43:07 <woodster_> hyakuhei, the closest with the current barbican API would be to throw that CMC as part of the order request
20:43:13 <alee> otherwise, they see something like POST /orders {meta including cmc)
20:43:16 <woodster_> ...in the meta data
20:43:26 <hyakuhei> Ok, I confused things there by saying CMC
20:43:44 <alee> and they get back an order_id
20:43:49 <hyakuhei> My point was, Barbican gets some order through the orders interface, and either eventally gives the client back a cert or it doesnt
20:44:02 <hyakuhei> with some polling / order_id etc in the middle
20:44:19 <alee> right - done by barbican
20:44:24 <alee> not the client
20:44:36 <alee> (well - some by the client potentially)
20:44:46 <hyakuhei> At this point I'm pretty sure we're saying the same thing in different ways so I'll ssh
20:45:04 <redrobot> alee I think what hyakuhei meant to say is that Barbican would be a client to some 7030 service, and not care whether it was an RA/ or CA
20:45:14 <hyakuhei> yeah
20:45:32 <alee> redrobot, yes but a 7030 service is an RA -- not a CA
20:46:01 <alee> redrobot, anyways I have  no objection to such a plugin -- I just dont think it will be useful.
20:46:28 <hyakuhei> I still don't follow alee but +1 to the overall 'not really needed' point
20:46:38 <hyakuhei> Though I guess if someone wants to write one it wont hurt
20:47:35 <redrobot> Yeah, I wasn't proposing that we do this work in Kilo, but I did want to get an answer on whether such a plugin would be helpful to someone.
20:47:42 <woodster_> alee, so you are saying the cert request could be handled by a 7030 service, but the retrieval and storage of the generated cert would involve talking with the CA out-of-band wrt to 7030, correct?
20:47:49 <redrobot> And whether we would want to merge it, if someone was to do the work.
20:48:33 <hyakuhei> redrobot: if someone was invested enough in solving some $problem to build a barbican plugin I should imagine $problem is worth solving and should be merged.
20:48:34 <alee> woodster_, I'm just sayuing that 7030 defines the interface for an RA.  That RA would need to talk to a CA
20:48:53 <reaperhulk> I think that probably covers 7030 effectively and we've only got 12 minutes left so should we move to castellan?
20:49:02 <woodster_> yeah, it seems no one is snapping at the opportunity to write such a plugin, or has an existing service they'd like to integrate with Barbican :)
20:49:05 <hyakuhei> +1
20:49:10 <redrobot> ok, moving on.
20:49:20 <redrobot> #topic Generic KeyManger Interface
20:49:21 <alee> reaperhulk, , redrobot I'd like to talk about using cmc request in metadata
20:49:31 <reaperhulk> rellerreller probably has some opinions here :D
20:49:32 <redrobot> alee key manager was next on the agenda
20:49:43 <alee> but we can defer till the after-meeting
20:50:02 <rellerreller> Yes, I'm curious if the new library has been created yet.
20:50:08 <alee> wegian?
20:50:08 <redrobot> Every Monday morning I think this is going to be a short meeting... but it never happens.
20:50:23 <redrobot> castellian seemed to be the least hated name
20:50:24 <hyakuhei> Just a note, after meeting sucks for us UK guys (current meeting finishes at 9pm)
20:50:39 <tkelsey> hyakuhei: +1 lol
20:50:41 <rellerreller> Our goal is to support the new library and integrate it into Cinder and Nova to support our Cinder volume encryption feature.
20:50:43 <redrobot> hyakuhei yikes, that's rough.
20:50:59 <hyakuhei> The scrifices we make ;)
20:51:14 <alee> hyakuhei, sorry , mate ..
20:51:17 <hockeynut> but you guys have Top Gear
20:51:29 <hyakuhei> True that, all things in balance I guess
20:51:36 <hockeynut> yep
20:51:39 <redrobot> rellerreller I think we're just waiting to nail down a name, then I can create the repo, etc.
20:52:06 <hyakuhei> rellerreller: How can we help with adoption?
20:52:09 <rellerreller> redrobot That sounds good. I have a developer that is chomping at the bit to get started.
20:52:17 <woodster_> should we create an etherpad with names that folks can vote on?
20:52:36 <redrobot> woodster_ last time that didn't get us anywhere... ;)
20:52:46 <rellerreller> The biggest help will be getting Cinder and Nova to accept the new library code.
20:52:48 <redrobot> Anyone absolutlely hate Castellian?
20:52:50 <woodster_> it worked for voting on design topics
20:52:57 <reaperhulk> redrobot aren't you adding an i in there
20:52:59 <alee> castellan?
20:53:00 <woodster_> llavo? (sp)
20:53:10 <rellerreller> I don't expect much pushback from Cinder since they already have the code. Nova may be trickier. We only have about 90% of the code accepted there.
20:53:13 <reaperhulk> I support Castellan as not being an objectionable name.
20:53:24 <woodster_> No ducks (sorry Nate)...castellan works for me
20:53:24 <hyakuhei> rellerreller: I can help a lot with Cinder, I'll talk to some people. Though I think BArbican broke some gates again I think
20:53:29 <rm_work> err, so could I push to include CertManager in addition to KeyManager?
20:53:32 <jvrbanac> reaperhulk, +1
20:53:43 <rm_work> something like https://review.openstack.org/#/c/131889/
20:53:46 <reaperhulk> rm_work: nope. One topic at a time.
20:53:49 <rm_work> I modeled that off KeyMgr from Cinder
20:53:56 <rm_work> reaperhulk: it's the same topic :P
20:54:05 <rellerreller> hyakuhei Yes there was an issue. We need to stabilize the API. It has changed a few times and that causes tests to fail.
20:54:10 <reaperhulk> Not really given that you're attempting to expand the scope.
20:54:18 <woodster_> Castellan +1
20:54:20 <reaperhulk> I'm not necessarily opposed but we have enough problems staying on topic :)
20:54:20 <redrobot> rm_work do you expect to write alternative certificate issuers ?
20:54:29 <alee> rm_work, I'm wondering if using Certmonger obviates the need for CertManager
20:54:32 <rm_work> redrobot: well, i do have one now
20:54:52 <hockeynut> Castellan + 1 for me too
20:55:00 <rm_work> alee: I guess that's a point, though I could argue for Certmonger AS an implementation of the interface
20:55:13 <rellerreller> Castellan +1 for me and Yeti +2
20:55:35 <alee> Castellan +1 Yeti +1
20:55:36 <hyakuhei> ooh, Yeti, that's an option!? :)
20:56:27 <woodster_> yeti was derived from yett (http://en.wikipedia.org/wiki/Yett) I recall
20:56:28 <rellerreller> I think it's an option, but I don't know if it will be vetoed or not
20:56:38 <chellygel> Castellan +1
20:57:01 <redrobot> we're running out of time for today... and I'm seeing a lot of +1s for Castellan
20:57:05 <chellygel> + jraim liked it too
20:57:05 <hyakuhei> I vote for trusting you guys to just make a smart choice
20:57:29 <jvrbanac> no pressure
20:57:31 <jvrbanac> :D
20:57:32 <redrobot> #todo redrobot to add openstack/castellan repo
20:57:37 <jaosorior> guessing it will stay as castellan
20:57:38 <rm_work> it's a boardgame: http://www.sjgames.com/castellan/ but other than that, I think ok
20:57:47 <rellerreller> I'm good with whatever. I would like to have closure, so we can create the library.
20:57:54 <hyakuhei> way too many smart people sat around to chat this long over the name for a library
20:58:20 <hyakuhei> Castellan sounds fine to me :)
20:58:21 <redrobot> hyakuhei and this is the second time we try to pick one... we spent a couple of hours talking it over in Paris >_>
20:58:30 <hyakuhei> wow
20:58:53 <rm_work> names are hard :/
20:58:57 <woodster_> Like a bunch of architects deciding on just the right class names :)
20:59:12 <redrobot> top dollars at work
20:59:26 <jaosorior> well... I do spend a lot of time naming my variables and functions...
20:59:28 <rm_work> but anyway, just be aware that I will be talking about pushing the scope just a tad to include the interface Neutron/LBaaS needs for Certs, not just Keys -- so expect that discussion to happen
20:59:57 <redrobot> ok, guys, I suppose we can jump back to #openstack-barbican for post-meeting discussion.  I'll recap next meeting for our UK friends.
20:59:57 <rm_work> whether now or later :)
21:00:15 <redrobot> #endmeeting