Wednesday, 2015-01-21

*** lisaclark1 has quit IRC00:01
*** crc32 has quit IRC00:05
woodster_rm_work, you still there?00:05
*** ayoung has joined #openstack-barbican00:09
*** jaosorior has quit IRC00:13
*** ayoung has quit IRC00:18
jamielennoxfrom a python 3 perspective in barbicanclient is the _get_raw which is used from things like payload supposed to return text or bytes?00:24
jamielennoxthings like secret payload00:24
jamielennoxassume bytes?00:24
reaperhulkdefinitely should be bytes00:24
reaperhulkif it's not that's a total bug since we'd be applying an encoding :o00:25
rm_youwoodster_: i am *here*00:25
jamielennoxreaperhulk: assumed so, just something that popped up00:25
rm_youjamielennox: yeah, it's supposedly bytes, I think00:25
rm_youthough that depends on the encoding we set00:26
jamielennoxit's something that using a mock gets to completely ignore00:26
rm_youit's supposed to allow us to specify an encoding, really (the basic .get() doesn't, IIRC?)00:26
rm_youit was something like that00:26
jamielennoxget assumes json and json needs an encoding00:26
rm_youyeah thats it00:26
woodster_rm_you, I added a response to your question...I still think that LBaaS user should have the right roles to access secrets, but need to see what other folks think00:27
rm_youwoodster_: but, access what secrets? its own? why would ability to access its own secrets have any relation to its ability to accessother people's?00:27
*** ryanpetrello has quit IRC00:27
woodster_rm_you, I mean secrets that another user has created and then said lbaas user is allowed to decrypt that secret. Are you thinking roles shouldn't matter if you aren't the project that created a secret? Seems like a priv escalation to me?00:29
rm_youso, keystone roles ARE specific to project00:30
woodster_rm_you, how much does impact the client lib in your opinion? I'm thinking a significant change00:30
rm_youso effectively I have no roles for Barbican for the other user's secret00:30
rm_youit's just that they told barbican to let me see them anyway00:31
woodster_rm_you, so I'm thinking that the lbaas user should be assigned the correct barbican roles to access secrets in barbican.00:31
rm_youwoodster_: again, whose? roles are project specific00:31
rm_youyou can't have a role that isn't tied to a project, AFAIK00:32
woodster_rm_you, you would assign the correct barbican role to the lbaas user-to-lbaas-project association00:32
woodster_rm_you, so in lbaas's policy definition in keystone00:32
rm_youso the logic would go "do you have access to your own secrets?" "yes" "did user A grant read-access to you for this secret?" "yes" "ok here is a secret"00:33
rm_youthe first part seems redundant to me00:33
rm_youand i don't see how not having it would be escalation00:33
rm_youUser A says "User B has access to my Secret"00:33
rm_youwhy do we care if User B has access to "secrets in general" (which again, isn't really what it'd be -- it'd be access to "their own secrets")00:34
woodster_rm_you, well, something like 'does your role match the operation you are trying to do?' if yes, then access secret by its UUID...does it have a white list? If no, then project ids have to match (as now). If yes, then am I on that white list? If no, reject.00:34
rm_youbut again, that's not a sane reading of keystone's role system, IMO00:35
rm_youat least as far as I understand it00:35
woodster_rm_you, I'm trying to resolve the current project-based approach with the white list approach, which is optional on secrets/containers.00:35
*** SheenaG11 has quit IRC00:36
woodster_rm_you, yeah, it might be good to get some Keystone dev weigh in on that CR.00:36
rm_youtrying to think of a good metaphor00:37
rm_youbecause i operate best with metaphors :P00:37
rm_youOk so, imagine a bank with a safety deposit box area00:37
rm_you... sec, i am still fleshing this out, should have waited a bit more on the first line <_<00:38
*** kgriffs is now known as kgriffs|afk00:38
rm_youso ignore what i said earlier. Barbican is a Bank.00:39
rm_youYour nephew Bill gives you access to his bank account via some method (Power of Attorney, possibly)00:40
openstackgerritVenkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources
rm_youYou go to the bank and say "I would like to look at Bill's balance."00:40
rm_youThe bank doesn't first ask you "do you have an account here?" nor if you did, "Can you put in the pin to your own account?"00:41
rm_youthey check the operation at hand, which is "do you have access to Bill's account", which is "yes"00:41
rm_youwhether you have your own account doesn't matter00:41
rm_yousimilar to this situation, there is no "I have access to *accounts in general*", because access to accounts is on a per account basis00:48
woodster_rm_you, well in the case whether you have an account or not is not important either. What matters is the roles that were setup for your user on your account. An admin had to be told you can be granted this role to do xyz in this other service. So its an extra level of security, like going to a CA to verify a cert.00:48
rm_youok, but keystone doesn't work that way00:48
rm_youit's all "can do xyz in this other service FOR THIS ACCOUNT"00:49
rm_youthat's the only language keystone knows, if I understand correctly00:49
rm_youthere is no such thing as a non-project associated role00:49
rm_youthat's why there's a "service" project, so they can fake it, but that's exactly what we were trying to avoid00:49
woodster_rm_you, I'm saying to barbican it doesn't matter what account you have for the policy.json RBAC just looks at the roles right now any way00:49
jamielennoxso i'm looking through the tests in python 3, the test secret data is a text object and the mocking happens such that it never tries to json serialize it00:49
rm_youyeah but what is the point of that00:50
jamielennoxif i were to pass it as bytes it would attempt to put that into a json serialize structure and ti would fail00:50
rm_youjamielennox: that's... odd00:50
*** ryanpetrello has joined #openstack-barbican00:50
woodster_jamielennox, well barbican supports a text and binary secret type...I wonder if that is a text-only secret?00:51
jamielennoxand as it so happens if i use oslo.serialization or whatever then it does work - it just turns it into an array of integers (bytes representation)00:51
woodster_rm_you, I think you are asking what is the point of roles in RBAC?00:51
rm_youwoodster_: no, the point of roles in RBAC is to grant permanent access to specific things on a specific project :)00:51
jamielennoxi'm looking at as used
rm_youexcept we have to work outside of the RBAC system entirely, because it is not granular enough00:52
woodster_rm_you, it is really so a 3rd party (system admin) can grant/revoke your ability to do thing in another system. If we don't respect that in barbican, then this 3rd pary check/balance breaks00:52
rm_youI mean, if it comes down to it, we can grant to our account whatever you are saying you want us to have00:52
rm_youbut it's pretty meaningless in keystone terms00:52
rm_youwoodster_: well, I could have 90 different "BARBICAN_READ" roles00:53
rm_youwhich one do you check? just one?00:53
jamielennoxregardless of the 'payload_content_type' and 'payload_content_encoding' it's still sent to the server in a json structure which bytes don't support00:53
jamielennox(i can wait for you guys to finish)00:53
rm_youwe're ignoring the project the roles are associated with in this example00:53
rm_youso really it's just "does the user have at least one"?00:54
rm_youroles are a mapping between projects and users00:54
woodster_rm_you, if I'm user XYZ, I should stay XYZ forever (until I'm removed). However, my roles might change over time. Maybe I'm an observer in barbican starting out, but I change job assigments to admin latter. Maybe later still I leave to a different team that doesn't require any access, then all barbican roles are removed. My access to secrets, even00:54
woodster_whitelisted for my user XYZ should not be a constant yeah decrypt away IMHO. However, if that is the expectation of folks, I can change, it just seems very odd to me.00:54
rm_youwoodster_: but an observer/admin for what project?00:55
woodster_rm_you, for barbican00:55
rm_you... no00:55
rm_youit's like00:55
woodster_jamielennox, that sounds like an issue you are finding there00:55
rm_youwhere "BARBICAN:Admin" is the role00:55
rm_youit's a linkage00:56
woodster_jamielennox, if the secret is a binary (application/octet-stream) type it would have to be base64 encoded to before passing into json00:56
jamielennoxwoodster_: i've found a bunch of similar python 3 bugs when i remove all the mocks the clients have00:56
*** lisaclark1 has joined #openstack-barbican00:56
rm_youjamielennox: what is sent to the SERVER is always json, what *comes back* is bytes00:56
*** lisaclark1 has quit IRC00:57
jamielennoxwoodster_: what's the default there? how should you check?00:57
*** lisaclark1 has joined #openstack-barbican00:57
rm_yousounds like you're trying to send bytes to the server?00:57
woodster_rm_you, so user XYZ has an assoc to project ABC, and can have barbican:admin, barbican:observer, etc. in that association...and that can change over time00:57
jamielennoxrm_you: right, but in which case i would assume that my secret payload is bytes in my application as well00:57
jamielennoxrm_you: if the secret_payload that is returned from the server is bytes then i would assume so00:58
jamielennoxas a somewhat stupid example i expect00:58
rm_youjamielennox: the secret payload is base64 encoded and sent to the server in that form, but always stuck into the json message00:58
woodster_jamielennox, take a look at these examples:
rm_youwell, possibly not base64 encoded if the type is "text"?00:58
rm_youso I am not sure00:58
jamielennoxack base64 barbicanclient/ gives no results00:59
woodster_jamielennox, so there are modes where you pass binary streams to and from barbican, but most of the time it is a json exchange00:59
jamielennoxso ignoring my wrong Syntax but i would want to be able to00:59
jamielennoxs = Secret.get('id')00:59
jamielennoxt = Secret.create(payload=s.payload, payload_content_type=s.payload_content-tpye)01:00
rm_you"payload": "gF6+lLoF3ohA9aPRpt+6bQ=="01:00
rm_youyou're expected to have base64 encoded your own binary data01:00
rm_youit seems01:00
rm_youjamielennox: ^^01:00
rm_youwhen it comes back, it comes back in the same form01:01
rm_you_get_raw() doesn't return binary then, it returns a String, just not one that is valid json01:01
jamielennoxfrom a user perspective it's weird that i have to encode something on the create, but i get it back as bytes on the fetch01:01
rm_youjamielennox: you'll get back the same base64 encoded string01:02
rm_youso if I said you actually get legit bytes back earlier, I was incorrect01:02
rm_yousorry for the confusion, i'm in the middle of another pretty draining debate here :P01:02
woodster_jamielennox, yeah it might make more sense from the API perspective...that one-step secret store allows you to upload a binary secret via JSON because of the base64 encode, but barbican notes the secret is a binary one, so when it is retrieved, it wants to send it back as a binary secret (we don't support conversion back to base64 currently).01:03
jamielennoxoh - it's fine from an API perspective01:04
woodster_jamielennox. fwiw, this blueprint is attempting to address this issue:
rm_youwoodster_: so sure, your relationship with Barbican for a specific project can change over time... but you might have a relationship with 5 projects all changing over time, and *none of it* should matter if User Bill says you can access his secret explicitly01:04
jamielennoxi'm more thinking of a client user you could handle that for them01:04
woodster_jamielennox, yeah it seems like this sort of confusion could be handled on the client side. The trick is that if the original secret is stamped as application/octet-stream, then it can only be retrieved that way, even if you originally had it as a base64 string. I.e. the get call would need to be able to take in a 'text/plain' sort of content to force the01:05
woodster_conversion to occur01:05
rm_youwoodster_: whatever happened to the OTHER CR that would make this less insane01:06
rm_youwhy hasn't that merged yet01:06
woodster_rm_you, well, I think that is the fundamental question to answer. I think barbican role should always matter, but yourself and probably others would disagree. I think widening this conversation is essential though, otherwise this CR will never land :)01:07
woodster_jamielennox, are you thinking along the lines of improving the client library, or some of the testing around it?01:07
jamielennoxwoodster_: well for the moment i guess it's a bug in testing01:08
jamielennoxor maybe not, it's testing that you pass a string to the secret payload01:08
woodster_rm_you, jamielennox, well that CR speaks to a unique URI to decrypt secrets, which makes the policy more explicit around that call. We'd still have the same issue of whether to convert to text or leave as binary though. I think blueprint with its strong secret type to format concept is really the best way to go...less01:10
woodster_ambiguity. If I counted up all the hours we've spent trying to describe the current approach, it would be several weeks I'm sure. :)01:10
rm_youIMO both would be best :P01:11
woodster_rm_work, jamielennox, I'm heading out now, but will be on later this evening. rm_work, I added the big question to the RBAC comments just now. jamielennox, feel free to get on IRC tomorrow/later if you have other thoughts on the testing there.01:17
jamielennoxwoodster_: thanks, i'll see if i just maintain the string assumption if the tests will work01:18
woodster_jamielennox, please let the list know if that isn't the case...means we probably need to address that soon01:19
rm_youjamielennox: i really think they should01:20
rm_youi went through another couple of your reviews today but i may have forgotten to submit my comments on the second one before i went home <_<01:20
*** ryanpetrello_ has joined #openstack-barbican01:25
*** ryanpetrello has quit IRC01:25
*** ryanpetrello_ is now known as ryanpetrello01:25
*** alee has joined #openstack-barbican01:27
jamielennoxrm_you: so is a problem and makes a similar assumption i did01:40
rm_youmakes the assumption the payload is of the default type (octet-stream, base64 encoded)01:41
rm_youI think01:41
rm_youIIRC I wrote that test01:42
rm_youyep, i wrote that test <_<01:42
jamielennoxso that is returning a text type01:42
jamielennoxdamnit what am i trying to say here, keep getting dragged between different conversations01:42
rm_youheh, been happening to me all day01:44
rm_youALL DAY.01:44
jamielennoxok so that line 19401:46
jamielennoxin python 301:46
jamielennoxthat will return a string, where in reality you want it to return bytes01:47
rm_youerr well no01:47
rm_youit'll return a string01:47
rm_youwhich will be a base64 encoded secret01:47
rm_youin -> barbican -> out01:47
rm_youshould all be the same format at the moment01:47
rm_youit doesn't convert or anything01:47
rm_youstring in -> string out01:47
rm_youtelling it you're storing an octet-stream is really more of a hint to what's inside the string, not related to what it actually takes in or spits out :(01:48
rm_youwhich is a bit confusing probably01:48
jamielennoxso is wrong?01:48
rm_youthat's right01:49
jamielennoxbecause .content implies the bytes and .text looks at the encoding and converts to a text string01:49
rm_youwell, the content is a string01:49
rm_younot actually byte format01:49
rm_youit *works*01:49
rm_youwhich tells you something, at least01:49
jamielennoxyea, this becomes a problem in python 3 where bytes != text string01:49
rm_youwhat tries to make it one or the other?01:50
jamielennoxfor which part01:50
jamielennoxresp.content == bytes, resp.text == text01:50
jamielennoxso maybe this was reaperhulk wrong earlier, that you do want to return a text string of base64 encoded data and not the raw bytes of the secret01:51
rm_youok then maybe yes it could be wrong01:51
rm_youi am thinking of it as "they are the same thing"01:51
rm_youmaybe it needs to be resp.text for py3301:51
reaperhulkNever doubt my ability to be wrong01:52
jamielennoxreaperhulk: never did01:52
*** zz_dimtruck is now known as dimtruck01:52
rm_youreaperhulk: so, barbican does just return strings, right?01:52
rm_youreaperhulk: even if it's octet-stream, it's returning a base64 STRING01:52
rm_youit's just a type-hint for the contents of the string01:52
reaperhulkWe can return raw binary on a get01:53
rm_youi would need to test this manually from py301:53
jamielennoxso when does the secrets.payload return base64 text vs the raw secret bytes?01:53
rm_youat the moment, the barbican server won't make any changes to the data you send it01:54
rm_youso if you send it a base64 string and the content type "octet-stream", then it'll store the string with that content-type in its metadata (it doesn't actually parse the payload)01:55
rm_youthen when you ask for it back, you ask for the payload by content-type, but it still just returns whatever you passed in, bit-for-bit01:55
rm_you(that is going to change with the content-types work being done now, re: the CR linked earlier)01:55
rm_youreaperhulk: correct me if i'm wrong here01:55
jamielennoxok, so currently on python 3 you would have to assume that this is all text01:55
jamielennoxbecause if you were to pass bytes to the create function then the json serialization would fail01:56
rm_youi believe so01:56
reaperhulkrm_you: do a two step store (post/put) and you can store a binary payload. I believe you can also do it in one step by providing it base64 encoded with the right content types.01:56
jamielennoxunfortunately that means we should string decode the raw data on response01:56
reaperhulkwoodster_ would know better than me though01:56
reaperhulkI don't look at the Barbican api very often. Mostly just the crypto parts01:57
rm_youI am not actually working *on Barbican*, I'm LBaaS :P01:57
rm_youso I keep leaving the Barbican world for a few weeks, coming back, and trying to remember all these specific interactions <_<01:58
rm_youit takes me a bit to recall everything01:58
rm_youredrobot would also probably be able to answer01:58
jamielennoxit's not an easy answer - this migration problem is the primary reason py3 has struggled02:00
rm_youwhere are you, BTW? is it still work hours in your timezone? :P02:01
*** sigmavirus24 is now known as sigmavirus24_awa02:03
jamielennoxrm_you: brisbane, australia - so started up again - which means you should probably have finished by now02:08
rm_youyeah i've been eating dinner while typing :P02:08
*** sigmavirus24_awa is now known as sigmavirus2402:28
*** ryanpetrello has quit IRC02:29
*** sigmavirus24 is now known as sigmavirus24_awa02:44
*** woodster_ has quit IRC03:32
*** woodster_ has joined #openstack-barbican03:44
*** woodster_ has quit IRC03:52
*** ryanpetrello has joined #openstack-barbican03:59
*** woodster_ has joined #openstack-barbican04:11
*** ryanpetrello has quit IRC04:15
*** lisaclark1 has quit IRC04:54
*** dimtruck is now known as zz_dimtruck04:56
*** woodster_ has quit IRC05:20
*** jaosorior has joined #openstack-barbican06:05
jaosoriorjamielennox: ping06:06
*** jamielennox is now known as jamielennox|away06:25
*** bdpayne has quit IRC06:54
*** chlong has quit IRC07:46
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Refactor order validation
*** jamielennox|away is now known as jamielennox12:01
*** chlong has joined #openstack-barbican12:03
openstackgerritMerged openstack/python-barbicanclient: Replace httpretty with requests_mock
*** ryanpetrello has joined #openstack-barbican13:10
*** zz_dimtruck is now known as dimtruck13:11
*** jamielennox is now known as jamielennox|away13:21
*** darrenmoffat has quit IRC13:35
*** darrenmoffat has joined #openstack-barbican13:36
*** elmiko has quit IRC13:41
*** elmiko has joined #openstack-barbican13:47
*** sigmavirus24_awa is now known as sigmavirus2413:48
*** samueldmq-away has quit IRC13:55
*** lisaclark1 has joined #openstack-barbican14:03
*** samueldmq-away has joined #openstack-barbican14:06
*** lisaclark1 has quit IRC14:24
*** woodster_ has joined #openstack-barbican14:26
*** lisaclark1 has joined #openstack-barbican14:30
jaosoriorwoodster_: ping14:39
woodster_jaosorior: good morning14:41
jaosoriorgood morning sir14:42
jaosoriorhow's it going over there?14:42
jaosoriorI replied to your comment in this CR and also made this CR since I thought refactoring would be worth being separate from the bug fix14:43
jaosoriorwhat so you think?14:43
woodster_jaosorior: that looks good, thanks!14:48
*** lisaclark1 has quit IRC14:49
openstackgerritTim Kelsey proposed openstack/barbican-specs: Adding spec for Barbican MKEK Model.
openstackgerritTim Kelsey proposed openstack/barbican-specs: Adding spec for Barbican MKEK Model.
*** lisaclark1 has joined #openstack-barbican14:55
*** paul_glass has joined #openstack-barbican15:12
*** lisaclark1 has quit IRC15:19
*** ayoung has joined #openstack-barbican15:21
*** rellerreller has joined #openstack-barbican15:27
*** tkelsey has joined #openstack-barbican15:28
*** lisaclark1 has joined #openstack-barbican15:29
aleerm_work, ping15:30
*** SheenaG1 has joined #openstack-barbican15:30
openstackgerritSteve Heyman proposed openstack/barbican: ** DO NOT MERGE **
*** atiwari has joined #openstack-barbican15:39
*** dave-mccowan has joined #openstack-barbican16:00
SheenaG1rellerreller: you around this AM?16:10
dave-mccowanalee, ping16:11
rellerrellerSheenaG1 what's up?16:11
aleedave-mccowan, pong16:11
SheenaG1rellerreller: I know I'm out of the loop for asking, but where is the Nova/Cinder patch?  Did it land?16:11
rellerrellerSheenaG1 Which patch are you talking about?16:12
dave-mccowani working on the validators now.  using some standard libraries would obviously be the best way to go.  is there a process for choosing libraries to add, such as for ldap or ssl with methods for parsing the fields?16:13
aleedave-mccowan, I would make sure that whatever you use is in the global requirements16:15
*** atiwari has quit IRC16:15
SheenaG1rellerreller: no idea on the number, did you guys have multiple outstanding?16:15
*** atiwari has joined #openstack-barbican16:15
SheenaG1rellerreller: for whatever reason, I thought there was one patch that enabled Nova to talk to an encrypted Cinder block16:15
rellerrellerSheenaG1 We have pushed several things to Cinder and Nova.16:15
SheenaG1rellerreller: sweet - so if I wanted to have an encrypted Cinder block that transparently talked to Nova and stored the encryption keys in Barbican, is that possible?16:16
rellerrellerOne of the things we had accepted was the KeyManager interface16:16
aleedave-mccowan, it might make sense for you to propose a library and discuss it here.  certainly reaperhulk will have some preferences no doubt16:16
rellerrellerSheenaG1 Yes you can16:17
aleereaperhulk, ping16:17
SheenaG1rellerreller: hot damn.  That's excellent news.16:17
SheenaG1alee: reaperhulk is in all day meetings today and tomorrow16:17
rellerrellerSheenaG1 jcoffman had a presentation at the last couple of summits on that16:17
aleeSheenaG1, ok thanks16:17
SheenaG1rellerreller: would have been nice to be there....  grumble grumble.16:18
rellerrellerSheenaG1 Here is a link to one of joel's talks --
SheenaG1rellerreller: thanks sir16:19
rellerrellerSheenaG1 I hear ya. It is not easy to get funding to attend those events :(16:19
SheenaG1rellerreller: no, it's not - at least my devs got to attend!16:19
rellerrellerThere is another presentation he gave that is a demo. Let me try to find that real quick.16:19
rm_workalee: delayed pong16:21
rellerrellerSheenaG1 check out this presentation as well,
aleerm_work, hey - so you going to get some time to work on per-secret stuff?16:21
rm_workalee: i will find out tomorrow16:21
rm_worksprint planning meeting16:21
dave-mccowanalee, reaperhulk: For certificate orders, we need some methods to parse and validate parameters like asn1 and distinguished names.  Crypto.Util and ldap.dn are two used by keystone.  Any objections to pulling those into Barbican?16:21
rellerrellerSheenaG1 That should give you the details on how it works, and a demo of it working. If you have any questions let us know. We can help with whatever.16:22
aleerm_work, ok - let me know if you need anything to bolster your case.16:22
rm_workit depends on what else comes down the pipe16:22
alee(as always)16:22
SheenaG1rellerreller: thanks again sir!16:22
rm_workIt is *required* to be working for our use-case, so I should have some decent ammo16:22
SheenaG1rm_work: I think *required* is debatable, but I certainly don't mind you implementing it...16:23
rm_workSheenaG1: welllll16:23
rm_workif it isn't implemented, we'd need god-mode in Barbican16:23
rm_workif you think that's a legit option then it's "optional"16:24
rm_worki hope that doesn't happen :)16:25
SheenaG1rm_work: agreed - certainly preferable not to16:26
*** atiwari has quit IRC16:29
openstackgerritVenkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources
aleedave-mccowan, I have no objections to those16:38
woodster_rellerreller, I didn't think the cinder/nova patches had landed yet for some reason, but they did afterall?16:38
aleedave-mccowan, just confirm that its on the global requirements list16:38
aleewoodster_, you in the same meeting with reaperhulk ?16:39
rellerrellerwoodster_ That stuff has been in there for a long time.16:39
reaperhulkDave-mccowan: I'm in meetings today but why are you needing to directly validate asn.1? Also, the next release of cryptography will do DN parsing16:40
aleereaperhulk, I want to generate a csr -- what should I use?16:40
aleereaperhulk, or will that be in the next version of cryptography?16:41
aleereaperhulk, dave-mccowan wants to validate requests coming in to confirm that they are valid cmc requests --16:42
reaperhulkIt all sucks right now. I would love it to be in the next cryptography release but probably not. Maybe pyopenssl right now16:42
reaperhulkPyasn1 may be a good option for that if you can define the shape of a request declaratively16:42
aleereaperhulk, that they include for instance subjectdn and key usage attributes16:43
aleedave-mccowan, ^^16:43
woodster_rellerreller, ha, sorry I'm trying to recall from Paris discussions and thought I heard that they hadn't landed yet for some reason16:44
aleedave-mccowan, pyopenssl and pyasn1 work for you?16:44
openstackgerritSteve Heyman proposed openstack/barbican: ** DO NOT MERGE **
rellerrellerwoodster_ We are always trying to add more features. Like we have been working on ephemeral encryption for a long time and that has been difficult to get in. We do have support for the LVM backend of ephemeral encryption but would like to support all types.16:46
woodster_rellerreller, yeah I need to dig deeper on these integration efforts with barbican, not so much heads down in the coding :)16:57
woodster_alee, is are you generating the csr for the stored-key order mode?16:58
aleewoodster_, yes16:58
woodster_alee, nice!16:58
aleewoodster_, hoping to get to that patch this week.  but the identifying ca patches are taking a little longer than I expected.16:59
woodster_alee, rm_work, rellereller, reaperhulk, btw, after discussion with rm_work yesterday on the per-secret RBAC, I added a cover comment question that would be good to answer if folks have the time:
aleewoodster_, feel free to take a look at the ones out there though :)17:00
rm_worki'll look after loonch17:00
woodster_alee, my union only allows me to look at 2 CRs per day, sorry!17:02
*** rellerreller has quit IRC17:03
aleewoodster_, interesting question -- I'm not sure I have any strong feeling either way yet -- I'll wait to see what others indicate.17:03
aleejvrbanac and redrobot might have opinions on this.17:03
redrobotalee ohai!17:03
aleewoodster_, just for you, I can squash all the CRs into one nice big one :)17:04
aleeohai -- figured you might have an opinion on woodster_ question above17:04
woodster_alee, death by Uber CR!!17:07
openstackgerritBrianna Poulos proposed openstack/castellan: Copy cinder.keymgr to castellan
*** atiwari has joined #openstack-barbican17:14
*** samueldmq-away is now known as samueldmq17:19
openstackgerritVenkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources
*** jkf has joined #openstack-barbican17:25
aleewoodster_, ping17:26
aleewoodster_, I have an implementation question.  When we go issue a cert request, we will go through some logic to determine which ca we will send the request to.17:28
woodster_alee, yep17:28
aleewoodster_, and as a plugin might support multiple ca's, we need to communicate the selected ca to the plugin in the issue_certificate_request() call17:29
aleewoodster_, now -- there are a couple ways of doing this ..17:29
alee1. add an argument plugin_ca_id=None to the issue_cert_request() call17:29
woodster_alee, I'd say that is needed for all the cert plugin calls btw17:29
*** tkelsey has quit IRC17:30
alee2) add the plugin_ca_id to the order_metadata17:30
alee2 has the advantage of not having to change the interface, but it means adding some metadata that was not in the original request17:30
alee1 means an interface change17:31
alee(which is not so bad as its in the backend)17:31
woodster_alee, doesn't the client have to specify which ca to use in their request?17:31
aleewoodster_, they can - but they dont have to17:31
woodster_alee, ah got it, so the project and so forth defaults can kick in17:32
aleeand the ca_id they specify is not the same as the plugin_ca_id17:32
*** lisaclark2 has joined #openstack-barbican17:32
*** lisaclark2 has quit IRC17:32
woodster_alee, yeah I'd say 1) is better as it is determined internal to barbican and should be segregated from client provided information17:32
aleewoodster_, ok agreed17:33
woodster_alee, I'd want to avoid any possiblity of that modified meta being mistaken for what the client provided17:33
*** lisaclark2 has joined #openstack-barbican17:33
*** lisaclark2 has quit IRC17:33
aleeyup - we'll just have to make sure all ca plugin implementers fix their plugins17:33
*** lisaclark2 has joined #openstack-barbican17:34
aleewhich right now should be pretty easy :/17:34
*** SheenaG1 has quit IRC17:34
*** lisaclark1 has quit IRC17:34
woodster_alee, I think so17:34
aleewoodster_, in the future though, this would be harder I think17:34
aleewoodster_, what about adding another field like barbican_meta - which would be a dict of barbican added values?17:35
woodster_alee, well, esp. if we have a plugin marketplace up and running like we proposed in Paris17:35
aleerather than just the plugin_ca_id .. that way if we need to make a change like this in future - then we can do so without breaking the interface17:36
dave-mccowanalee,  pyopenssl and pyasn1 should work for me.  i'll give them a try.17:37
aleewoodster_, ?17:38
aleedave-mccowan, cool17:38
woodster_alee, that could be a good thing to do though I could see some folks complaining about an overly generic interface. I think it makes sense though, like a context object that has system info available in it17:44
aleewoodster_, ok cool - I'll add in the next CR then -- preference on variable name?17:45
woodster_alee that sounds good to me17:45
aleeok thanks17:46
woodster_alee... _meta all the things!17:46
aleewoodster_, in the case of the stored-key implementation, does it make sense to put the csr in the barbican_meta dict, rather than the order_meta -- as it was not part of the original request?17:51
woodster_alee...hmmm...yeah, that makes sense actually.17:51
aleewoodster_, cool - that was bugging me at the back of my mind17:52
woodster_alee, yeah it's hard to think thru all of these details at BP time...the bp should really be pointing you in the right directly, but agile takes over to fill in the details17:53
*** jkf has quit IRC17:56
*** jkf has joined #openstack-barbican17:59
*** atiwari has quit IRC17:59
*** SheenaG1 has joined #openstack-barbican18:00
*** ryanpetrello has quit IRC18:23
*** ryanpetrello_ has joined #openstack-barbican18:23
*** ryanpetrello_ is now known as ryanpetrello18:23
*** ryanpetrello_ has joined #openstack-barbican18:30
*** ryanpetrello has quit IRC18:31
*** ryanpetrello_ is now known as ryanpetrello18:31
*** rellerreller has joined #openstack-barbican18:31
*** ayoung has quit IRC18:40
*** lisaclark2 has quit IRC18:48
openstackgerritSteve Heyman proposed openstack/barbican: ** DO NOT MERGE **
*** lisaclark1 has joined #openstack-barbican18:52
*** lisaclark1 has quit IRC18:52
*** lisaclark1 has joined #openstack-barbican18:59
woodster_alee, I'm looking at a bp to add a reissue cert feature to barbican. Ive been thinking a new order type with a link to the generated certificate. The order processing would then use the original cert's info to cut the reissued cert (resulting in a new container/UUID). But we probably have the same choices as a normal cert order, such as providing a new CSR,19:01
woodster_or having barbican generate it. So maybe better to just allow a normal 'certificate' order to take an optional link to a previous certificate to pull info from it if present?19:01
woodster_SheenaG1, chellygel: ^^^19:02
SheenaG1woodster_: just to be clear, you aren't talking about reusing the original CSR, correct?  Either the customer has to supply a new one or Barbican will generate one on their behalf?19:10
*** jkf has quit IRC19:23
*** jkf has joined #openstack-barbican19:25
woodster_SheenaG1: I believe so. Would there be a use case for reusing the original csr though?19:26
SheenaG1woodster_: not a good one19:26
SheenaG1woodster_: I would rather not re-use the CSR ever, just wanted to make sure that wasn't implied somewhere19:27
woodster_SheenaG1: I've been thinking it is more like a create order/cert process that uses info pulled from the original request19:27
SheenaG1That would definitely be true in CA-land19:28
woodster_SheenaG1: cool so I can detail that approach in the blueprint19:28
SheenaG1woodster_: sounds good to me - in the case of our Symantec CA, the only things that they would really need are a new CSR with the same domain name and access to the e-mail address for the person who originally approved the certificate19:29
SheenaG1Any other metadata used to create the new CSR/PK pair will be ignored19:30
SheenaG1But it doesn't hurt to have it be accurate19:30
chellygelcatching up woodster_19:30
chellygel2 secs19:30
chellygeli dont know why i bothered, since sheena responded :P19:31
chellygelbut that makes sense to me.19:32
SheenaG1You look too.19:32
SheenaG1I catch the dumb all the time.19:32
chellygelim too busy looking at the confetti on my desk!19:32
woodster_chellygel: it is overwhelming!19:47
woodster_chellygel: nice TV too19:47
chellygeli should've made a ake19:48
chellygeli forgot my rack-versary was today]19:48
chellygelake => cake19:48
*** lisaclark1 has quit IRC19:57
woodster_SheenaG1: chellygel so ok to ignore info provided in the reissue that is provided in the previous order?19:58
woodster_...or maybe better to error out if doesn't match?19:59
SheenaG1I would not allow for someone to provide information for a reissue20:00
SheenaG1It has to be info from the old order only20:00
*** crc32 has joined #openstack-barbican20:12
woodster_SheenaG1: alee so only the csr and stored key certificate order modes should be supported then20:16
SheenaG1sorry, not sure what that mean?20:18
SheenaG1Can you dumb it down a bit?20:18
aleewoodster_, sounds reasonable to me.  dogtag has a couple other modes to renew certs, but they are probably not standard for ca's20:19
aleeSheenaG1, I think woodster_ means that we can reissue with the client providing a new csr or with barbican generating a new one.20:20
*** lisaclark1 has joined #openstack-barbican20:21
openstackgerritSteve Heyman proposed openstack/barbican: ** DO NOT MERGE **
aleewoodster_,  in the other modes supported by dogtag, a client can present the cert itself (doing client auth to verify possession of the public key) - the details are then taken from the original csr which is stored by dogtag20:22
aleethis allows an automatically approved self-renewal20:22
aleethat might actually be an option that the dogtag plugin could provide under the covers --20:23
aleeanother mode it accepts is presenting the same csr20:24
openstackgerritVenkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources
SheenaG1Ah, yes - thanks ale20:25
chellygelalee,  why would you accept the same CSR? maybe i misunderstand, but isn't the point to rotate out the private key20:26
chellygelto ensure its 'secure'20:26
aleechellygel, I understand reissuing a cert as being something like renewing a cert for instance.20:27
aleenot in the sense of just providing a brand new request20:27
chellygelif a certificate expires, and you want a reissue -- lets say?20:28
aleerenewing a cert using the same private/public key pair is what many people like to do.20:28
aleechellygel, if you change out the key pair, thats just like generating a brand new request20:29
aleechellygel, for example, you use a pki  key pair to encrypt your email.20:31
aleeif you change out the public/private key pair, you are no longer able to decrypt the email20:31
*** bdpayne has joined #openstack-barbican20:37
*** rellerreller has quit IRC21:20
*** samueldmq is now known as samueldmq-away21:20
woodster_alee, so if one POSTed a certificate order as normal, but included a ref to an existing certificate container via UUID, then I would expect barbican to work with the CA to generate a new certificate, but using info from that original cert/order.21:23
reaperhulkReuse of an existing private key is bad practice on renewal. Several CAs actually detect and reject that sort of behavior (provided you are a previous customer with them of course)21:24
*** lisaclark1 has quit IRC21:28
rm_workreaperhulk: interesting, did not know that21:31
SheenaG1reaperhulk: are you ignoring the GLO or did they let you out to run amok?21:32
reaperhulkIn it right now. Occasionally chatting on phone21:32
*** david-lyle has joined #openstack-barbican21:46
aleereaperhulk, I think thats debatable - sometimes people like to re-issue (as opposed to re-key) because of things like encrypted mail.21:49
aleereaperhulk, naturally, the longer a private key is out there, the more likely it is to be compromised21:49
aleewoodster_, we'd have to figure out how we wanted to design it.  as reaperhulk said, not all ca's may support key reuse.21:52
aleewoodster_, I think having the option to request it is a good idea.21:52
*** dave-mccowan has quit IRC21:53
*** sigmavirus24 has left #openstack-barbican21:55
rm_workhey redrobot or woodster_ or anyone really, do you have a good gerrit dashboard trick to show reviews that are ready for you to look at (not WIP, not V-1) but that you haven't yet commented on?21:59
rm_workor anything else you have found to be useful for that kind of dashboard21:59
*** chlong has quit IRC22:05
*** david-lyle has quit IRC22:11
*** david-lyle has joined #openstack-barbican22:11
*** david-lyle has quit IRC22:15
*** lisaclark1 has joined #openstack-barbican22:16
*** lisaclark1 has quit IRC22:20
*** SheenaG1 has quit IRC22:26
*** lisaclark1 has joined #openstack-barbican22:26
*** lisaclark1 has quit IRC22:29
*** lisaclark1 has joined #openstack-barbican22:29
woodster_rm_work, this view kindof sort of does this:
rm_workproject:stackforge/octavia is:open NOT label:Workflow-1 NOT label:Review>0,user=flux.adam@gmail.com22:34
rm_work^^ that is what I am currently trying to use22:34
*** jaosorior has quit IRC22:34
rm_workbut the last part doesn't actually work22:34
woodster_alee: I see this as well for renewals/reissues:
rm_workit's supposed to cut out reviews I've put at least a +1/+2 on22:35
woodster_rm_work: sounds...verbose. jvrbanac is working with the API to generate that daily list we see...maybe making your own query would be easier? :)22:36
jvrbanacwoodster_, ?22:37
jvrbanacwoodster_, rm_work, are y'all talking about:
woodster_jvrbanac, ^^^ regarding your API work with gerrit to produce the daily list of CRs you email out.22:38
aleewoodster_, that has to do with CA signing certs -- thats a whole different box of wax22:38
aleeball of wax22:38
woodster_alee, oh correct, sorry.22:38
rm_workjvrbanac: interesting22:40
jvrbanacrm_work, so that script is a quick and dirty cli script that pulls the data off of gerrit and sends it to people via mailgun22:41
*** ryanpetrello has quit IRC22:51
aleewoodster_, ping22:53
woodster_alee, hey22:53
aleewoodster_, question about validators ..22:53
aleeso one thing I was thinking about doing was adding  a test to confirm that a client passed in ca_id actually corresponds to a valid ca22:54
aleeand that -- if a project has project_ca's defined, that the ca is one of them22:54
aleeI thought I would do that in the validator22:55
aleebut this means that I need to pass in repos for ca_repo and project_ca_repo22:55
aleewhich is fine in itself I guess , I also need to pass in the project_id for the request22:56
woodster_alee, looking at the red hat docs and projecting to Barbican, it seems that a renewal might be expected to overwrite the cert that is renewed...i.e. the UUID of the cert container wouldn't change, but the expiration date would move out. So it seems a reissue workflow (with new pk/csr) is a better fit for the barbican immutable way of doing things.22:57
aleewoodster_, before I head down the dark tunnel of figuring out how to pass all that stuff in -- does it make sense to do all this in validators?22:57
*** david-lyle has joined #openstack-barbican22:58
woodster_alee, yeah, validators have been static so far22:58
aleeI can do all this outside of validators if it makes sense to do that ..22:58
aleewoodster_, maybe I should do that so that I'm not changing absolutely everything23:00
woodster_alee, I think it does for the time being, though that adds biz logic to the controllers. That isn't a bad place for that to be, but we are talking about a lot of lines of logic, that is still probably better to do in the module, just not associated with a ValidatorBase sub-class, but maybe a first class function that the controller calls23:01
woodster_off to?23:01
woodster_alee, my personal pref is for the controllers to be as brief as possible...just doing synchronous-side orchestration23:02
aleewoodster_, well the advantage of doing the validation then is that the user immediately gets feedback that the parameter they have specified is bad23:03
woodster_alee, putting validation logic in the if you are just passing in models to a function...still seems better and easier to test.23:03
aleerather than checking once the request is in the request queue.23:03
woodster_alee, you are still doing the validation, but just not in the static/type validators (that extend ValidatorBase), but rather validation functions that the controller calls23:03
woodster_alee, and if all of that is in the module, we can revisit that later to see if it makes sense to have the static validators do that instead23:04
aleewoodster_, take a look at right now ..23:05
woodster_so controllers would call the load-body validator thing first, and then call the validators.do_model_validation_thingster(my_model)23:05
woodster_alee, it mainly has class definitions, but is also (at the top) has some first class functions carved out23:06
aleewoodster_, so just to be clear -- there are some functions that I carved out before in validators()23:06
alee_validate_pkcs10_data() <- should stay in static validator?23:07
alee_validate_full_cmc_data() ?23:07
alee_validate_subject_dn_data() >23:08
woodster_alee, that makes sense to me...but if _validate_xxxx is called from outside, you'd just remove that '_'23:08
aleebut what about _validate_certificate_container() ?23:08
aleeseems to me that this one needs to be outside of the static validator then?23:09
woodster_alee, if this module gets too unruly, then you could create a 'validators' sub-package23:09
*** david-lyle has quit IRC23:09
woodster_alee, yeah, I'd say if you need validation that doesn't 'fit' within the no-arg load_body() approach now, you'd want to make a standalone function def for it, but still in the module23:10
aleewoodster_, this module is already pretty unruly and needs to be refactored -- but I'm trying avoid that in this CR.23:10
aleewoodster_, ok - thats what I'll do then23:10
aleeand we can revisit how the validators should look after that.23:10
aleeback to your  question then ..23:11
aleea renewal always results in a new cert being created23:11
aleewith a new serial number23:11
aleeso you'd need a new container ..23:12
woodster_alee, that sounds good.  Just noting also that we did start an effort to make singleton accessors for the repositories, but that was not completed I believe.23:12
aleebut that does not translate into new keys per se23:12
aleeit may be valuable to have the option of reusing the old keys23:13
aleeand just create a new container with references to the old keys and a new cert23:13
*** paul_glass has quit IRC23:14
woodster_alee, chellygel, hmmm. So some choices are to send POST a 'certificate' order with a container_ref attached implying a renewal/reissue. If by itself with no other info, then we have a renewal situation (reuse all of the original cert's info, including it's private key if it was originally a stored key order, etc.)23:16
*** lisaclark1 has quit IRC23:17
woodster_alee, chellygel ...or we could introduce a new order type, like 'certificate_renewal'.23:17
aleewoodster_, thats probably what we's need to do -- a new order type23:19
aleewoodster_, being called to dinner23:19
*** alee is now known as alee_dinner23:19
*** jkf has quit IRC23:22
*** lisaclark1 has joined #openstack-barbican23:23
*** jamielennox|away is now known as jamielennox23:27
*** chlong has joined #openstack-barbican23:34
*** SheenaG1 has joined #openstack-barbican23:40
*** lisaclark1 has quit IRC23:51
*** lisaclark1 has joined #openstack-barbican23:58

Generated by 2.14.0 by Marius Gedminas - find it at!