20:00:14 <redrobot> #startmeeting barbican
20:00:14 <openstack> Meeting started Mon Nov 24 20:00:14 2014 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:18 <openstack> The meeting name has been set to 'barbican'
20:00:36 <redrobot> #topic Roll Call
20:00:43 <tkelsey> o/
20:00:47 <rm_work> o/
20:00:48 <dave-mccowan> o/
20:00:51 <hyakuhei> o/
20:00:53 <atiwari> o/
20:00:53 <jaosorior> o/
20:00:54 <alee_> o/
20:00:59 <chellygel> ¯\_(ツ)_/¯
20:01:03 <bknudson> hi
20:01:03 <elmiko> hi, visiting from sahara land, hoping to soak up some knowledge =)
20:01:13 <rellerreller> o/
20:01:18 <jvrbanac> o/
20:01:21 <redrobot> elmiko welcome!
20:01:24 <reaperhulk> o/
20:01:25 <jaosorior> bknudson: yo
20:01:30 <woodster_> o/
20:01:32 <redrobot> woohoo!  lots of barbicaneers here today
20:01:39 <reaperhulk> how many of us are actually supposed to be on vacation?
20:01:49 <chellygel> 1,2,3 not it
20:01:57 <rm_work> USE YOUR ETO FOR ETO (╯°□°）╯︵ ┻━┻
20:02:07 <hyakuhei> whats "vacation" ?
20:02:08 <redrobot> rm_work lol
20:02:17 <redrobot> as usual the agenda can be found here:
20:02:19 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:02:21 <chellygel> ┬─┬ノ( º _ ºノ)  chill out dude
20:02:30 <jaosorior> lol, dafuq
20:02:33 <rm_work> :P
20:03:02 <redrobot> Weve got a couple of things on the agenda for today
20:03:02 <hyakuhei> Sorry, I thought this was the 7030 meeting...
20:03:14 <redrobot> #topic Validation for Typed Container data (Certificates, etc)
20:03:22 <redrobot> rm_work you wanted to talk about this?
20:03:33 <rm_work> So, do we think this is a feasible thing to move onto the Barbican side?
20:03:38 <redrobot> hyakuhei we talked about it last week
20:03:47 <rm_work> There is some work associated with this (ie, processing time on the API nodes)
20:04:19 <rm_work> But I think that on a user creation of a CertificateContainer and the like, we should have validators to make sure the data is actually... correct for that container type
20:04:27 <rm_work> What do other people think?
20:04:44 <hyakuhei> Checking there's a key and a cert and possibly a passphrase? that sort of thing?
20:04:48 <rm_work> yeah
20:04:59 <hyakuhei> and checking that theyre functionally correct?
20:05:02 <rm_work> yes
20:05:05 <rm_work> and match each other
20:05:06 <hyakuhei> ie right key for cert?
20:05:08 <hyakuhei> ok cool
20:05:08 <rm_work> yep
20:05:16 <tkelsey> sounds reasonable to me
20:05:17 <rm_work> and the cert isn't actually a recipe for a quiche
20:05:24 <rm_work> a SECRET recipe
20:05:27 <tkelsey> lol
20:05:38 <hyakuhei> Hmm, that gets harder
20:05:44 <hyakuhei> I mean, validating ASN.1
20:05:53 <hyakuhei> and checking some fields are present maybe?
20:06:03 <hyakuhei> but you can abuse X509 in so many ways :D
20:06:04 <rm_work> not sure how deep we want to get
20:06:18 <rellerreller> When you certificates do we just mean x.509 or other types of certs too?
20:06:32 <rm_work> what we're doing for Octavia is just attempting to load up the cert as an x509 object with pyOpenSSL and using the passphrase passed to us
20:06:49 <rm_work> and if it loads, success! then we make sure the PK is for the cert
20:07:03 <atiwari> rm_work, while creating container we just provide reference to the cet, passwd etc...
20:07:05 <rellerreller> I agree with hyakuhei with ASN.1 validation
20:07:07 <atiwari> cert
20:07:08 <rm_work> but initially, I don't think we could do anything more than very basic checks like that
20:07:08 <hyakuhei> Seems like a reasonable firt step
20:07:19 <rm_work> atiwari: yeah, so that's one of the complications
20:07:21 <hyakuhei> Get the plumbing right and we can work on clever checks later ?
20:07:25 <rellerreller> rm_work this sounds similar to the content type work that I have been working on
20:07:27 <rm_work> we'd have to actually retrieve the secret data
20:07:43 <rm_work> since as atiwari points out, we don't have it directly
20:07:49 <atiwari> rm_work, then what to validate. Actual reference?
20:07:50 <rm_work> are there security concerns there?
20:08:30 <rm_work> would it be possible to do it by doing some pre-parsing on secret data and filling in some meta fields, so we could do some validation without actually examining the secret payload?
20:08:39 <rm_work> I don't actually know, I am speculating
20:08:47 <alee_> rm_work, so I understand - when would these validations be triggered?  when the secret is added to a certificate container?
20:08:54 <hyakuhei> pre-parsing ie on the client end?
20:08:57 <rm_work> alee_: yeah, for Container creation
20:09:10 <rm_work> hyakuhei: might have to be server, to be consistent
20:09:16 <rm_work> since not everyone will use the python client
20:09:24 <rm_work> which is a performance concern
20:09:41 <hyakuhei> Sure, I was just looking for clarification
20:09:43 <rm_work> I wanted this topic brought up so we could figure out what problems this would have and if it's even feasible :)
20:10:11 <atiwari> rm_work, are you thinking of pulling the secret and check is that is x509 cert or not? something like that?
20:10:13 <rm_work> hyakuhei: but yes, essentially just the basic plumbing would be a great start
20:10:25 <rm_work> atiwari: that is the most obvious way, yeah
20:10:27 <alee_> rm_work, so you add a certificate container, then you add a private key ref, then you add a public key ref?  and when you add the public key, the checks get triggered?
20:10:32 <rm_work> not sure if that is a performance/security concern
20:10:52 <rm_work> alee_: err, the CertContainer creation is one operation
20:11:00 <woodster_> hmmm...given that secrets are created first, maybe we'd want the metadata to be specific/validated at that level, and then when put into container just check the secret metadata is as expected?
20:11:02 <rm_work> I'm talking about server-side here
20:11:02 <redrobot> I'm not sure we want to be in the business of decrypting secrets during container creation.
20:11:12 <rm_work> redrobot: right, that is concerning
20:11:17 <redrobot> woodster_  +1
20:11:18 <reaperhulk> woodster_: metadata of that type leaks information about the secret
20:11:23 <rm_work> woodster_: yes, that was what I was proposing above
20:11:27 <atiwari> alee_, I think process is other way. first you add cert, keys and then create container
20:11:33 <rm_work> but reaperhulk is also correct :P
20:12:12 <rm_work> yeah, CertContainer creation is: 1) All secrets created and stored. 2) Container created with refs to all required secrets.
20:12:27 <woodster_> reaperhulk, are you arguing for no enforced/validated metadata on the secret as now? Then when put into a typed container, isn't that info still being leaked?
20:12:50 <atiwari> rm_work, is there any BP or use case defined anywhere? just to understand the details.
20:12:54 <rm_work> are we talking about Typed Secrets now?
20:12:58 <rm_work> CertSecret?
20:13:05 <woodster_> or are we just talking about reference validation here...that the secrets reside within the same barbican endpoint?
20:13:18 <rm_work> woodster_: well, I am talking about functional validation
20:13:49 <rm_work> atiwari: so for Octavia / LBaaS, we need to know that when a user gives us a ref to a Barbican CertificateContainer, that we will have a valid set of data
20:14:05 <rm_work> so we don't accept it and then pull the cert and end up trying to start up HAProxy with a quiche recipe
20:14:21 <atiwari> rm_work, OK so you are taking about an existing container?
20:14:22 <woodster_> well, if that functional validation isn't keyed to some metadata about the secret, then your only choice is container validation...i.e. you said this secret was a public key, let's verify that before adding to this container
20:14:29 <rm_work> or present a cert that isn't the correct cert for the PK we're using
20:15:00 <redrobot> rm_work so what would be the benefit of having Barbican do this server side, vs Octavia validating the bytes it retrieves from Barbican?
20:15:07 <rm_work> woodster_: right, which would require decryption of secrets at container creation time, which as redrobot said could be a security and performance issue
20:15:39 <rm_work> redrobot: so, we CAN do it on our side. I wanted to gauge the feasibility of doing it Barbican side
20:15:54 <rm_work> as I see this kind of check being duplicated in almost every use case
20:16:11 <rm_work> if we don't think it can be done... then that sucks, but it's not the end of the world
20:16:15 <alee_> rm_work, I can see trying to do some kind of validation when the cert container is created - because you have the relevant references ... but if you're going to do something like check if something encrypted by hte private key can be decrypted by the public,
20:16:34 <alee_> then you're talking about decrypting the secrets within the barbican server
20:16:46 <rm_work> alee_: yeah, that is the kind of check we're doing on our side... and yes, I can see the dilemma
20:17:01 <atiwari> woodster_, how about adding an extension on container "/container/<id>/validate" and we will do the run time validation ?
20:17:23 <alee_> rm_work, I'd rather decrypt on the client.  The client after all has access to the secret
20:17:24 <atiwari> Lbaas can call this before using the contianer
20:17:37 <jaosorior> rm_work: really wouldn't dig decrypting the secrets within the server :/
20:17:42 <rm_work> I'd worry about DDoS but that could be throttled I think
20:17:46 <rm_work> jaosorior: yeah I know
20:18:06 <jaosorior> why didn't you wanna do it in the client side again?
20:18:08 <rm_work> alee_: ok, so just build that validation into the python client?
20:18:21 <woodster_> atiwari, or maybe have a validate order so we can do this stuff asynchronously....
20:18:22 <redrobot> rm_work thats what I was about to suggest
20:18:23 <rm_work> jaosorior: well, it depends on what you mean by client side
20:18:42 <jaosorior> well, it would make more sense in python-barbicanclient
20:18:44 <alee_> rm_work, I think it needs to happen either in the client --- or in the backends where the secret is stored
20:18:46 <redrobot> maybe having validation methods in the client would work?  Secret().is_certificate
20:18:47 <rm_work> actually, that would work to prevent code duplication
20:18:56 <rm_work> yeah
20:19:00 <rm_work> I think that's feasible
20:19:01 <jaosorior> if someone is not using the client, then I guess they'll have to validate themselves in their codebase
20:19:04 <rm_work> yep
20:19:16 <rm_work> I think that's the best option
20:19:20 <atiwari> woodster_, but I think Lbaas need it synchronously I think.
20:19:42 <rm_work> yeah, I think doing it in python-barbicanclient is probably the best option
20:19:44 <alee_> rm_work, if the backend plugin has the capability to encrypt something and decrypt something , then you could do it there.
20:19:49 <reaperhulk> Okay, so my understanding of why it was interesting to potentially have this done on the server side was that as currently designed octavia has to pull down the cert + key and do the check itself, then the data is fetched again by another system later. With a server side check it would be possible to make it so octavia itself never sees the decrypted secret.
20:19:56 <reaperhulk> rm_work, is that accurate?
20:19:57 <rm_work> on the read-side rather that as a pre-req for writing
20:20:07 <woodster_> then client side is best...it also has access to the private key used to gen a cert CSR too
20:20:19 <rm_work> reaperhulk: yes
20:20:24 <rm_work> that is the deeper problem description
20:20:42 <rm_work> but I don't think we're going to solve that
20:20:58 <reaperhulk> it's useful for people here to know the context of why you ideally want it :)
20:21:26 <rm_work> so what reaperhulk mentioned was another motivation for this -- if our API can *trust* that the contents of a CertContainer is valid, we don't even need to look at it -- and we can wrap it end-to-end and never see it
20:21:38 <rm_work> as is, we have to fetch the secret data just to validate it and throw it away
20:21:56 <woodster_> ...which is what a client side check would do
20:22:02 <rm_work> right :/
20:22:19 <alee_> rm_work, is the cert/key generated on the client - or the server?
20:22:36 <rm_work> alee_: cert/key is input by the user
20:22:40 <atiwari> alee_, I think client
20:22:44 <rm_work> outside of our workflow
20:22:46 <woodster_> if everyone uses barbican to gen their certs, no worries! :)
20:22:51 <rm_work> woodster_: right
20:22:52 <rm_work> :P
20:22:57 <atiwari> user is providing everything
20:23:01 <alee_> and then -- the client generates the container , right?
20:23:05 <rm_work> yes
20:23:10 <rm_work> the End User
20:23:13 <rm_work> generates the container
20:23:22 <rm_work> (client is a generic term)
20:23:22 <alee_> rm_work, so I see no reason that the client does not validate the key pair right then and there.
20:23:33 <rm_work> we can't trust the End User
20:23:57 <rm_work> then again, if they put in bad data, it's their own fault if their LB goes into Error
20:23:57 <alee_> you're trusting them to provide a key/cert ..
20:24:19 <rm_work> the hope is that we can warn them specifically though and prevent stupidity from causing an issue
20:24:27 <alee_> why not validate even before contacting barbican to create the container?
20:24:40 <rm_work> alee_: we don't have control over that
20:24:47 <alee_> if the check fails, then tell them "you're an idiot"
20:24:57 <chellygel> (^only if this is the real message plz)
20:25:08 <rm_work> The CertificateContainer will exist before our system even enters the picture
20:25:22 <rm_work> the End User will have created it on their own
20:25:32 <rm_work> via... Maybe the python client? maybe Horizon?
20:25:39 <rm_work> We don't know
20:25:43 <reaperhulk> rm_work: I think alee_'s question is why do you need to validate it before it gets to the end. Is that an optimization that really matters? Why not let it try to load in haproxy and handle the error in that (presumably highly rare) edge case?
20:25:52 <alee_> rm_work, ok - then validate before sending the key/cert to be stored.
20:26:05 <rm_work> alee_: ... we don't send it to be stored
20:26:08 <rm_work> the End User does
20:26:16 <rm_work> or do you mean stored on HAProxy?
20:26:42 <rm_work> reaperhulk: we could just say "fuck it", yeah
20:26:54 <rm_work> I'm not entirely opposed to that option
20:26:58 <reaperhulk> Is that really fuck it? Either way you get an error and have to handle it
20:27:03 <reaperhulk> You just have to pick where you want to handle it
20:27:09 <rm_work> we could probably wrap this up -- it looks like the answer is that this can't be done server-side
20:27:18 <atiwari> alee_, container is created by lb end use with cert and keys. I think LB need capability to validate is the content is valid or not.
20:27:20 <reaperhulk> probably not for now, but I'm still glad you added it to the agenda :)
20:27:20 <redrobot> rm_work +1
20:27:26 <rm_work> but that adding methods to the python client would provide some good code if people want to use it
20:27:39 <woodster_> 1) user creates cert container 2) user tells LBaaS to create a LB with said container 3) LBaaS validates container via barbican client and tells user if it stinks 4) LBaaS saves container ID if valid
20:27:54 <rm_work> correct ^^ woodster_
20:28:08 <redrobot> #agreed We won't do validation at Container creation for now
20:28:12 <redrobot> ok, moving on
20:28:18 <rm_work> my next topic! :P
20:28:29 <redrobot> #topic Castellan scope: include CertMgr / ContainerMgr support?
20:28:46 <rm_work> I posted a comment on the CR to this end
20:28:59 <rm_work> I would like to see this added to the project scope sooner than later
20:29:02 <rellerreller> Which CR?
20:29:10 <rm_work> https://review.openstack.org/#/c/136140/
20:29:16 <rm_work> the one you commented on :P
20:29:29 <redrobot> rm_work thanks, I was digging for that link
20:29:30 <rellerreller> haha Got it!
20:29:53 <rm_work> So, I have already modified the Cinder KeyMgr interface for use on Octavia
20:29:57 <rm_work> and Neutron-LBaaS
20:30:13 <rm_work> which is a perfect example of why it needs to be done somewhere central (I've already had to copy/paste it once)
20:30:25 <rellerreller> +1
20:30:47 <rellerreller> What changes did you need to make?
20:30:53 <rm_work> and since that interface CAME FROM KeyMgr, it should be easy enough to integrate
20:31:09 <rm_work> it's very similar -- Cert instead of Key, CertManager instead of KeyManager
20:31:13 <rm_work> different methods...
20:31:16 <rm_work> but otherwise
20:31:23 <rm_work> it operates very similarly
20:31:34 <rm_work> actual code work is incredibly minimal
20:31:50 <rellerreller> I would suggest modifying it to make a Certificate a type of key or change the keymanager to a SecretManager
20:31:56 <rm_work> and I'm more than happy to contribute if it's included in the project scope
20:32:07 <woodster_> does anyone object to adding a CertManager interface here?
20:32:08 <rellerreller> Where keys/secrets are symmetric, asymmetric, certificates
20:32:10 <rm_work> rellerreller: well, the issue is that it's not a Secret Manager
20:32:13 <rm_work> it's a Container Manager
20:32:26 <rm_work> which is the main way in which it differs
20:32:36 <rm_work> KeyMgr only deals with individual secrets
20:32:41 <rm_work> not Containers of any kind
20:32:52 <rm_work> there was discussion of making it more generic than Certs somehow
20:32:59 <rm_work> since there are also RSAContainers
20:33:01 <alee_> rm_work, we chatted about this a bit - and I think get_cert, store_cert, delete_cert should be replaced by container management api calls.
20:33:19 <rm_work> alee_: that is an option
20:33:53 <rm_work> though if we remove too much of the Cert specific code
20:34:02 <rm_work> it becomes significantly less useful
20:34:21 <rellerreller> My concern would be having two different interfaces. Are you proposing having a KeyManager and a ContainerManager?
20:34:29 <atiwari> rm_work, do we really need store cert through CertManager?
20:34:29 <rm_work> well
20:35:02 <atiwari> I think for Lbaas get_cert is enough?
20:35:10 <rm_work> well, sure
20:35:15 <rm_work> but it should be complete
20:35:16 <rellerreller> My concern with two different interfaces is that ContainerManager is likely highly tied to KeyManager.
20:35:33 <rm_work> rellerreller: so, it comes down to "what is the backend doing"
20:35:36 <rm_work> since this is an interface
20:35:48 <rellerreller> It seems like if we want a container concept then add it to KeyManager interface
20:35:55 <rm_work> rellerreller: that would work too
20:36:12 <rm_work> I only forked this completely because it was out-of-project from KeyMgr
20:36:33 <rellerreller> I think that would be safer. Otherwise someone will deploy a KeyManager and ContainerManager that have no idea about each other.
20:36:34 <atiwari> rellerreller, +1
20:36:48 <alee_> rm_work, I agree that this is a topic that needs to be fleshed out -- but I think we're talking about two things 1) adding container management to KeyManager and 2) adding cert stuff to a CertManager
20:36:53 <woodster_> would most deployments use the same backend for both key manager and cert manager?
20:37:03 <rm_work> woodster_: I would assume so
20:37:28 <rm_work> So I assume if we provide a lot of interfaces, they could all be implemented without any real code duplication
20:37:38 <rm_work> by the same provider
20:37:42 <alee_> I think container management is relatively uncontroversial.   certmanager needs some more thought.
20:37:53 <rm_work> yeah, I just don't want to see the specifics get dropped
20:38:06 <rellerreller> Part of this too is what is a key. I would say a certificate would be another object it would manage.
20:38:09 <rm_work> I would prefer to see some extra classes with more specific purpose
20:38:19 <rm_work> than trying to genericize too much
20:38:42 <alee_> rm_work, I think we need a blueprint we can all bash ..
20:38:46 <rm_work> yes
20:38:47 <rellerreller> +1
20:38:48 <jaosorior> rm_work: +1
20:39:12 <redrobot> #action rm_work to write blueprint for Certificate management in Castellan
20:39:18 <rm_work> so, for now, we can agree that we need container support, and the basic project scope can be fixed to include that? i will be happy with that for now
20:39:24 <rm_work> lol, aaaaand I just signed myself up for that
20:39:38 <redrobot> rm_work :)
20:39:42 <rm_work> ok
20:39:43 <alee_> rm_work, yup :)
20:39:44 <woodster_> one method is all you need: do_something(something_code, *args, **kwargs)
20:39:54 <rm_work> sweet, thanks woodster_
20:39:56 <ekarlso-> q what's castellan ?
20:39:59 <rm_work> I'm all set now :P
20:40:17 <alee_> sorry guys - need to drop - back online later today .. but out for rest of the week ..
20:40:29 <redrobot> ekarlso- it's the working name for a separate repo to hold a generic key manager interface
20:40:30 <alee_> happy t-day!
20:40:33 <rellerreller> ekarlso- it's the new library that has the KeyManager interface
20:40:42 <woodster_> alee, take care
20:40:46 <ekarlso-> ok :)
20:40:48 <redrobot> alee_ have fun!  eat lots of turkey!
20:40:51 <elmiko> alee_: have fun =)
20:40:52 <atiwari> alee_, have fun
20:41:01 * rm_work waves at alee_
20:41:19 <rm_work> next topic redrobot?
20:41:25 <redrobot> #topic Content type
20:41:32 <redrobot> not sure who added this one?  rellerreller ?
20:41:39 <rellerreller> That was me
20:41:49 <rellerreller> So for those unfamiliar with the content type problem here is the gist of it.
20:41:58 <rellerreller> A user uploads a secret to Barbican in format X. Another user downloads the key for usage but expects the key to be in another format. How do we handle different formats and what formats do we support? How can we change that a secret of type X is really a secret of type X?
20:42:06 <rellerreller> This problem comes up with public keys. Some people are expecting PEM and others DER.
20:42:28 <rellerreller> This has caused us a lot of confusion.
20:42:30 <alee_> oh thank god -- escaping before content types .. :)
20:42:44 <redrobot> alee_ lol
20:42:47 <rellerreller> The first part of this is how to represent keys and certificates.
20:43:04 <rm_work> so is deep inspection and built-in automagic conversion routines out of the question? :P
20:43:21 <rellerreller> rm_work that is something that I would like and am working on
20:43:27 <woodster_> only if that take work on the API nodes to do it :)
20:43:47 <rm_work> well, API nodes scale to whatever, right? :)
20:43:48 <rellerreller> We need to define types so that when we are passed a public or private key then we can validate that it is one of those things
20:44:01 <rm_work> rellerreller: HEY. this is a tie-in to topic #1 >_>
20:44:18 <rellerreller> I have been looking at RFCs for days now trying to find how to represent keys.
20:44:30 <rellerreller> rm_work I think this will help you out a lot
20:44:42 <rm_work> so, Typed Secrets?
20:44:49 <woodster_> rm_work, agreed.  I think that is leakage reaperhulk was concerned about?
20:44:59 <rm_work> sounds like, yes
20:45:00 <bknudson> http://pki-tutorial.readthedocs.org/en/latest/mime.html
20:45:03 <rellerreller> I am leaning toward Base64 encoding of ASN.1 objects that are DER encoded.
20:45:03 <woodster_> is typing different than metadata then?
20:45:17 <rm_work> still leaks data
20:45:26 <rellerreller> woodster_ typing?
20:45:35 <rm_work> "Oh this is a PrivateKeySecret, yummy"
20:45:43 <woodster_> yeah, I'd prefer to have one standard type rather than allowing multiple ones
20:46:03 <rellerreller> The RFC, https://tools.ietf.org/html/rfc5912#section-6, has some ASN.1 representations of public keys
20:46:04 <woodster_> rellerreller, typing, as in Typed Secret
20:46:24 * redrobot needs to brush up on ASN1
20:46:36 <woodster_> ...instead of relying on the metadata for a secret
20:46:36 <reaperhulk> famous last words
20:47:11 <redrobot> last time I looked at content-types I was a bit confused on how to represent Base64
20:47:22 <rellerreller> No metadata for secret. First cut I plan to make all secrets of a type have the same represenation. Then later we can add translation to different types
20:47:27 <redrobot> technically Base64 encoding is a Transport-Encoding not a Content-Type
20:47:30 <woodster_> reaperhulk, would having a 'type' sort of attribute to direct what type a secret is a no no?
20:47:59 <rm_work> rellerreller: you mean we decide that all Certs are PEM, so if we get passed anything not PEM, we detect and convert to PEM for storage?
20:48:17 <woodster_> ...or reject it outright
20:48:19 <rellerreller> Just wondering what people think of Base64 encoding of ASN.1 with DER encoding.
20:48:20 <reaperhulk> woodster_: I would be okay with that
20:48:45 <redrobot> rm_work I would think that we'd want to define our own content types?  "application/barbican+asn1der"
20:48:55 <reaperhulk> rellerreller: that's pretty much the definition of PEM although the underlying DER representation would ideally be PKCS8 for asymmetric keys
20:48:58 <rm_work> redrobot: that seems redundant :/
20:49:02 <atiwari> rellerreller, I think that will cause problem in case of RSA container with password protected private keys
20:49:05 <rellerreller> rm_work We would reject any object that is not encoded to the exact encoding for that type.
20:49:20 <rm_work> rellerreller: ok, so we ONLY accept PEM / whatever
20:49:23 <atiwari> rellerreller, as mentioned in bug #link https://bugs.launchpad.net/barbican/+bug/1365187
20:49:25 <uvirtbot> Launchpad bug 1365187 in barbican "Accept header application/octet-stream is not honored while getting Asymmetric secrets" [Undecided,In progress]
20:49:28 <rellerreller> rm_work so if we decide certs will be in DER format then all certs must be in DER format and PEM certs will be rejected
20:49:48 <rm_work> yeah, k
20:49:58 <rm_work> atiwari: depends on how the validation is done
20:50:01 <rellerreller> atiwari How so?
20:50:08 <rm_work> if it's done by attempting to load it up, then yes that'd cause problems
20:50:27 <rm_work> if it's done just by looking at structure and not validating functionally, then it'd be OK
20:50:36 <atiwari> rellerreller, please take a look in the bug
20:50:38 <rm_work> or if that were a fallback -- doesn't functionally validate, but it LOOKS ok
20:50:48 <rm_work> though yeah, hard to convert that
20:51:05 <atiwari> issue is we are storing in PEM serialized format
20:51:34 <rellerreller> atiwari the issue is that people are storing things in whatever format they are given, and we have no idea what that is
20:51:44 <woodster_> rellerreller, is that a 'natural' format generated by ssl related tooling, or would folks need to use barbican client (yet again) to do the conversion easily?
20:52:18 <woodster_> ....a little concerned about AJAX-y web pages using barbican API directly
20:52:21 <rellerreller> DER encoding of ASN.1 seems to be the standard
20:52:35 <rm_work> I kinda thought PEM was the standard, but I may live in a bubble
20:52:47 <reaperhulk> ...okay, everyone halt for a minute :)
20:53:00 <rm_work> LBaaS / Octavia was planning to assume/require PEM :P
20:53:01 <rellerreller> PEM is Base64 of DER with a header and footer
20:53:04 <reaperhulk> When it comes to asymmetric keys inconsistency is the order of the day
20:53:15 <reaperhulk> as rellerreller said, PEM is just DER in base64 with delimiters
20:53:19 <atiwari> rellerreller, IMO we have to restrict the format depending on type of secret ans associated properties .
20:53:24 <reaperhulk> however, DER can be multiple formats inside it
20:53:41 <rellerreller> I chose DER because of inclusion in X.509. That RFC says how public keys are embedded in certificates.
20:53:58 <reaperhulk> DER is merely the distinguished encoding rules for ASN.1 and there are several ASN.1 structures
20:54:05 <reaperhulk> X.509 certs have only one (thankfully!)
20:54:08 <reaperhulk> but the private keys do not :)
20:54:10 <rm_work> lol thanks for the clarification reaperhulk -- though now I am confused about some conversations I have had recently >_>
20:54:44 <rellerreller> reaperhulk That was one of my problems is how to represent private keys
20:54:55 <rm_work> pkcs8?
20:55:05 <reaperhulk> Yeah we talked a bit about this in Paris. I would prefer a normalization to PKCS8 as it is the closest thing to a real standard that exists
20:55:06 <rellerreller> The RFC only defines public keys. I cannot find ASN.1 modules for private keys except for RSA.
20:55:26 <woodster_> we need a new unifying standard dammit...how hard can that be? :)
20:55:43 <reaperhulk> Yeah, we've run into the same problem in pyca/cryptography... we should take this outside this meeting rellerreller but we may have some useful code for you
20:55:51 <rm_work> 75% of private keys I see are PKCS8 I think :/
20:55:51 <woodster_> maybe we need an etherpad to capture some the typical formats folks use with some examples?
20:55:52 <rellerreller> But PKCS8 is only for RSA?
20:56:12 <hyakuhei> woodster_: +1
20:56:34 <rellerreller> I can start etherpad on this
20:56:49 <rellerreller> I can make the etherpad the beginning of my blueprint.
20:56:57 <reaperhulk> rellerreller: You can definitely generate a PKCS8 for ECDSA/DSA keys
20:57:07 <rellerreller> This is turning out to be a lot more difficult than what I anticipated.
20:57:32 <reaperhulk> https://github.com/pyca/cryptography/pull/1390 <-- pure python parser for PEM keys and a serious PITA
20:57:38 <redrobot> rellerreller heh.. isn't that always the case. :)
20:57:48 <rellerreller> reapherhulk Thanks. There are a lot of new RFCs that I am trying to become expert with and that is not easy for me.
20:58:10 <reaperhulk> That PR also has comments noting what RFC some of the ASN.1 structures came from
20:58:13 <reaperhulk> so that might be helpful :)
20:58:27 <rellerreller> reaperhulk that would be fantastic :)
20:58:38 <woodster_> #link https://etherpad.openstack.org/p/barbican-formats-discussion
20:58:41 <rellerreller> Google searching for this has been terrible
20:58:58 <redrobot> Almost out of time y'all
20:59:10 <redrobot> thanks for the etherpad woodster_
20:59:16 <woodster_> well, if we could come up with reasonable typical formats and stick with those, that might do the trick?
21:00:00 <redrobot> we can continue discussion back at #openstack-barbican
21:00:04 <redrobot> thanks for coming everyone
21:00:05 <redrobot> #endmeeting