18:02:53 <dolphm> #startmeeting keystone
18:02:54 <openstack> Meeting started Tue Mar 25 18:02:53 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:57 <openstack> The meeting name has been set to 'keystone'
18:03:04 <dolphm> #topic Reminder: Design summit session proposals open until April 20th
18:03:32 <dolphm> i saw that david chadwick had a request on list for the summit - anyone know if that was captured on summit.openstack.org as well?
18:03:54 <marekd> ayoung: told him to do so.
18:04:12 <marekd> ayoung told him to do so.*
18:04:22 <stevemar> dolphm, i think he's just interested in adding on to federation, my topic should cover it 'future enhancements to federation'
18:04:22 <ayoung> dolphm, what he wants to discuss is in stevemar 's session anyways
18:04:26 <dolphm> marekd: awesome, thanks - i haven't caught up on the mailing list recently
18:04:29 <dolphm> ayoung: cool
18:04:37 <stevemar> ayoung, thanks for that reply btw
18:04:43 <ayoung> NP
18:04:52 <lbragstad> #link http://summit.openstack.org/cfp/details/72
18:05:01 <dolphm> stevemar: s/future enhancements// # it's the design summit, anything else would be rejected :P
18:05:34 <dolphm> #topic icehouse-rc1
18:05:42 * dolphm CONGRATS EVERYONE
18:05:52 <dolphm> our list of release blockers is clear as of this morning:
18:05:54 <dolphm> #link https://launchpad.net/keystone/+milestone/icehouse-rc1
18:06:21 <stevemar> nice
18:06:22 <dolphm> if anyone has any release-critical issues that need to be addressed, target them to icehouse-rc1, stab me, and wave lots of flags
18:06:39 <dolphm> otherwise, we should be cutting RC1 tomorrow morning
18:06:44 <bknudson> when does juno get cut?
18:06:51 <bknudson> i mean when is juno open
18:06:51 <dolphm> bknudson: opened?
18:07:07 <dolphm> bknudson: as soon as we have a milestone-proposed branch for icehouse (which RC1 is created from)
18:07:13 <dolphm> so, tomorrow hopefully
18:07:52 <dolphm> and on a related note...
18:07:57 <dolphm> #topic keystoneclient v0.7.0 release
18:08:05 <morganfainberg> o/
18:08:16 <dolphm> i'm aiming to release keystoneclient 0.7.0 tomorrow morning, along with RC1 (by coincidence)
18:08:23 <gyee> w00t!
18:08:23 <morganfainberg> whoopse :P
18:08:45 <dolphm> we have a wishlist of reviews on the meeting agenda that we wanted to see merged prior to stamping out 0.7.0
18:08:59 <dolphm> as of now, they're all approved except for a couple nice-to-haves
18:09:06 <dolphm> #link https://review.openstack.org/#/c/82527/
18:09:10 <dolphm> #link https://review.openstack.org/#/c/82886/
18:09:13 <ayoung> I really wanted to get compressed tokens in there but getting shut down by Python33 issues
18:09:24 <jamielennox> though if anyone is looking there are always a bunch of nice to haves up for review
18:09:25 <ayoung> region API is a nice to have
18:09:26 <dolphm> ayoung: ack, we'll open juno with a 0.8.0 then :)
18:10:06 <dolphm> jamielennox: feel free to extend the list on the meeting agenda with your top picks
18:10:26 <ayoung> revoke events needs to be resynced as well
18:10:36 <dolphm> i need to clean up the 0.7.0 block list on LP as well, and push things to 0.7.1 / 0.8.0 as appropriate
18:10:47 <jamielennox> cool, i've still got a lot of general client reviews open so if people can spend some time on them this week that would be appreciated as i know we'll all want to get back to server when juno opens
18:11:06 <morganfainberg> jamielennox, on my list of things to do since we're looking good on RC
18:11:24 <dolphm> morganfainberg: ++ everyone should do the same this week
18:11:26 <ayoung> dolphm, On the client side,  I'd be interested in people's opions about including the examples scripts such as : https://review.openstack.org/#/c/82687/
18:11:52 <ayoung> stevemar was working on some oauth ones, and I am doing the same with revocation events
18:11:58 <jamielennox> excellent, i'm around now so ping me with any questions
18:11:58 <bknudson> I'd be interested in feedback on not using md5 -- https://review.openstack.org/#/c/80398/
18:12:19 <dolphm> ayoung: i'd love to have smaller snippets in docs, like a tutorial
18:12:36 <dolphm> ayoung: a bunch of big scripts require maintenance, etc
18:12:36 <ayoung> bknudson, looking
18:12:53 <morganfainberg> dolphm, ++
18:13:08 <bknudson> ayoung: after our discussion on irc I changed the server to return the hash algorithm
18:13:08 <gyee> dolphm, ayoung, is this different from keystone/tools/sample_data.sh?
18:13:09 <morganfainberg> ayoung, i think there is def. value to have the examples, but we should probably either gate on them working or make it docs
18:13:20 <gyee> I mean use case
18:13:24 <morganfainberg> bknudson, i like moving to a better algorithm
18:13:45 <ayoung> gyee, I think it is the same use case
18:14:00 <morganfainberg> ayoung, gating on the scripts working would be my preference if we're including them as good examples.
18:14:03 <bknudson> there are some security standards don't allow md5
18:14:25 <ayoung> bknudson, I'll have to go through the patch in depth, but it looks right on a quick glance
18:14:30 <gyee> bknudson, there are some don't even allow sha1 :)
18:14:34 <jamielennox> bknudson: so is the server returning the algorithm or is it being set by config? i prefer the server set method
18:14:40 <bknudson> ayoung: yes, please look closely!
18:15:26 <bknudson> jamielennox: the server is returning the algorithm in the revocation list
18:15:44 <dolphm> bknudson: that seems hacky :(
18:15:58 <morganfainberg> dolphm, the server should specify the algorithm to the client
18:15:59 <bknudson> dolphm: which is hacky? server includes algorithm or config setting?
18:16:09 <morganfainberg> dolphm, not just a config that needs to be in sync
18:16:15 <dolphm> morganfainberg: as part of the revocation list?
18:16:24 <jamielennox> bknudson: so do we need the CONF.hash_algorithm?
18:16:28 <morganfainberg> dolphm, probably. it's a clear indication of what we used
18:16:30 <bknudson> the algorithm also applies to the tokens.
18:16:36 <gyee> bknudson, I am fine with baking the info into meta data
18:16:40 <morganfainberg> dolphm, there is prior art (look at passwords in ldap, {SSHA}<password>
18:16:54 <dstanek> why does the algorithm matter in the revocation list? aren't we just comparing the token we have to the list of revoked tokens?
18:16:56 <morganfainberg> dolphm, it clearly identifies what the client should expect.
18:16:57 <bknudson> not just the tokens in the revocation list... I mean the cached tokens.
18:16:58 <dolphm> morganfainberg: ack, it's the same challenge with compressed tokens
18:16:58 <ayoung> dolphm, it is not hacky, it is essential.
18:17:16 <jamielennox> dolphm: no i think it is better that we have it in the response than to keep the value in sync in CONF on client/server
18:17:23 <morganfainberg> dolphm, ++ yep and the same argument
18:17:26 <bknudson> dstanek: the revocation list contains token hashes
18:17:29 <ayoung> the MD5 Hash algorithm was based on an assumption that both side used it.  Making it explicit is correct, and it needs to be driven by the server
18:17:54 <dolphm> i'm more concerned about which response the data is being crammed into, and what that affects
18:17:59 <dolphm> or is intended to affect
18:18:09 <dstanek> bknudson: ah i see, and i'm assuming we do that because it's shorter
18:18:14 <bknudson> I've got to admit I like the config option, it was simple to implement.
18:18:25 <bknudson> dstanek: the token hash is a lot shorter than the PKI token!
18:18:36 <lbragstad> ++
18:18:42 <morganfainberg> dstanek, yeah less data to transit usign the hashes
18:19:06 <dolphm> bknudson: the challenge of distributing configuration is a larger problem than just old pki vs new pki or md5 vs sha1
18:19:36 <dolphm> there was a proposal a summit or two ago about a centralized configuration service for things like this
18:19:56 <jamielennox> bknudson: the first use of conf._hash_algorithm there is just for caching purposes - we don't necessarily need that to be the same as the revocation list algorithm
18:19:58 <dolphm> you could GET a configuration on startup, and then listen on the message bus for changes in real time, etc
18:20:00 <bknudson> you can store config in our policy backend.
18:20:05 <morganfainberg> dolphm, being explicit about this stuff to the client also means that non-auth_token clients could understand it
18:20:17 <gyee> morganfainberg, fine point
18:20:37 <gyee> take x.509 certs for example, signing and hash algorithm are part of the cert
18:20:42 <dolphm> morganfainberg: yeah, i like that for sure
18:20:53 <jamielennox> dolphm: i always liked that idea but last time i tried it people suggested sticking with puppet etc
18:21:06 <dolphm> is the next default algorithm sha1?
18:21:08 <morganfainberg> dolphm, in cases like the compressed tokens, the TRL, etc, we should make it not auth_token specific (we control auth_token so we can do cool things with it, but being open to other tools is better)
18:21:25 <dolphm> jamielennox: the proposal i saw was to complement puppet/etc, not replace them
18:21:48 <brich1> dolphm, sha256 is a more durable choice than sha1
18:22:17 <dolphm> brich1: of course, but it might not be the best choice today
18:22:22 <morganfainberg> brich1, i would argue sha1 is sufficient in most cases, but as long as we allow for sha256 (limit data transit where possible unless more durable is needed)
18:22:31 <bknudson> after the comments I got on the keystoneclient hashing, you can use any hash algorithm that hashlib supports
18:22:55 <gyee> morganfainberg, your customers, whom had to deal with industry compliance, will tell you what is sufficient and what's not
18:23:03 <bknudson> hash_ = hashlib.new(mode) -- where mode is the config option (or hash algorithm from revocation list)
18:23:07 <dolphm> brich1: and sha512 is more durable than sha256 :)
18:23:10 <gyee> we don't often get to decide unfortunately
18:23:11 <morganfainberg> gyee, and the default should be best general use-case
18:23:24 <morganfainberg> gyee, as long as the better options are easily supportable, i see no issues
18:23:41 <gyee> morganfainberg, sure, pick a reason default and allow it to be configurable
18:23:41 <morganfainberg> gyee, many deployments don't need the overhead of sha256
18:23:45 <gyee> reasonable
18:23:47 <dolphm> morganfainberg: ++
18:23:58 <morganfainberg> gyee, so i'd say sha1, and we can evaluate the default each release :)
18:24:04 <gyee> that's what bknudson's patch is all about
18:24:14 <brich1> dolphm, sha256 is already required by NIST (as of end of 2013), so US federal customers would be happier with that canonical choice
18:24:23 <morganfainberg> but i would like to see MD5 no longer be the default w/ bknudson's patch going live.
18:24:44 <ayoung> I think bknudson 's approach is correct.   Lets give it asolid review after the meeting.  Shall we move on?
18:24:44 <brich1> morganfainberg, agree that md5 is history
18:24:50 <dolphm> ayoung: ++
18:24:52 <bknudson> thanks!
18:24:57 <ayoung> morganfainberg, md5 dies in Juno
18:25:02 <dolphm> #topic API/Compatibility expectations for auth_token middleware
18:25:05 <morganfainberg> ayoung, +++++++++++
18:25:09 <dolphm> #link https://review.openstack.org/#/c/77748/
18:25:19 <dolphm> (not sure who put this on the agenda? dstanek?)
18:25:27 <jamielennox> so this came out of a public variable change in the above link
18:25:28 <jamielennox> me
18:25:29 <dstanek> jamielennox probably
18:25:33 <morganfainberg> is this the auth_token doesn't have a stable interface?
18:25:38 <morganfainberg> convo
18:25:52 <dolphm> gyee: just saw your comment - that's the first time i've heard of anyone extending auth_token at all
18:25:53 <morganfainberg> erm public
18:25:56 <jamielennox> do we care about people subclassing auth_token middleware and keeping a stable interface for them?
18:25:59 <dolphm> morganfainberg: yes
18:26:01 <ayoung> I think that one is safe
18:26:04 <jamielennox> my impression has always been no
18:26:25 <jamielennox> so long as we maintain the config options and the ENV variables we set the actual implementation of the middleware was fair game
18:26:25 <ayoung> auth_token should not have a stable interface, as it is a wsgi pipeline component
18:26:29 <morganfainberg> I feel like we should break up auth_token into comething more consumable
18:26:31 <jamielennox> but i realize i've never had that clarified
18:26:34 <morganfainberg> but the middleware should be a blackbox
18:26:43 <ayoung> I guess in theory we could be breaking someone that extends it
18:26:55 <gyee> ayoung, meh :)
18:26:56 <dolphm> my suggestion to solve this particular review is to add a @property def request_uri that logs a warning to use self.identity_uri instead
18:26:58 <bknudson> if we're going to have a documented interface then split that out and have keystone auth_token implement it
18:26:59 <jamielennox> ayoung: in theory yes - i don't know anoyone who does
18:27:01 <gyee> that's fine, a small change anyway
18:27:02 <dstanek> yeah, we would be :-)
18:27:19 <dolphm> morganfainberg: ++ delete most of it and replace it with the regular client!
18:27:19 <jamielennox> dolphm: yea this one is easy, it's the principal i'm wondering about
18:27:23 <morganfainberg> gyee, that would let you pull in the bits you need and extend, but not be restricted to what the internals look like
18:27:25 <morganfainberg> dolphm, :)
18:27:25 <dolphm> jamielennox: ++
18:27:35 <gyee> morganfainberg, ++
18:27:37 <ayoung> jamielennox, I think we have to draw the line somewhere.  Internal variables are probably it.  But then again, last time I decided something like this I made thingy at Dreamhost sad.
18:27:39 <dstanek> i brought it up in the review because i didn't know if a policy existed for kc api compat
18:27:43 <gyee> lets tag the public interfaces
18:27:53 <morganfainberg> gyee, __call__
18:27:57 <jamielennox> dolphm: right - i would like to rip auth_token apart and if i'm stuck with a public interface that's going to get way more difficult
18:27:57 <morganfainberg> gyee, the rest are private
18:27:58 <morganfainberg> :P
18:28:53 <morganfainberg> jamielennox, this should be something communicated to the community (not that i think anyone would really have an issue with it)
18:29:06 <gyee> morganfainberg, sure, add _ in front of them
18:29:23 <morganfainberg> jamielennox, just so we're not ripping the carpet out from under anyone
18:29:40 <morganfainberg> jamielennox, but i would like to claim auth_token doesn't have a public interface
18:29:52 <jamielennox> gyee: right, i don't mind going through auth_token and making the whole thing private
18:29:56 <jamielennox> morganfainberg: i agree
18:30:17 <dolphm> the only public interface i've ever considered auth_token to have is A) X-Auth-Token, B) all the environment headers passed down to the consuming service
18:30:24 <morganfainberg> dolphm, ++
18:30:26 <dolphm> and that's fairly well documented in the module's docstr
18:30:48 <ayoung> dolphm, ++
18:30:52 <dolphm> if you're going to start replacing parts of the internals of the module, i'm not sure it's in the community's best interest to support you
18:31:18 <ayoung> dolphm, unless "you" is jamielennox of course
18:31:33 <bknudson> and X-Storage-Token
18:31:40 <dolphm> bknudson: ++
18:31:59 <morganfainberg> lets aim for 0.8 release to switch the interfaces to _ prefixed and communicate this change to the community
18:32:15 <jamielennox> morganfainberg: ++ works for me
18:32:25 <morganfainberg> and clarify the documents as well
18:32:39 <morganfainberg> if someone balks we can work with them to address the concerns
18:32:41 <dolphm> if we find as result that it's common to extend parts of auth_token with alternative behaviors, we can take a more conservative approach moving forward
18:32:47 <jamielennox> morganfainberg: as far as i can see there is nothing on auth_token that would be public
18:32:53 <morganfainberg> dolphm, ++
18:33:08 <bknudson> what would people want to override in auth_token?
18:33:25 <morganfainberg> bknudson, no clue. i don't see a point to it
18:33:26 <bknudson> new headers?
18:33:27 <jamielennox> bknudson: i've never heard of it in practice
18:33:35 <dolphm> gyee: ?
18:33:49 <gyee> bknudson, ssl auth
18:33:58 <gyee> we don't use username/password for the admin token
18:34:05 <morganfainberg> gyee, that seems like something that can be addressed with auth_plugin magic
18:34:05 <gyee> we override it to use 2-way ssl
18:34:09 <dolphm> gyee: is that not relevant to contribute back to the community?
18:34:12 <bknudson> that's a good one... different methods of getting username.
18:34:23 <morganfainberg> gyee, and contributable back up
18:34:26 <gyee> dolphm, yes, I am trying to contribute it back
18:34:47 <dolphm> gyee: in that case, you can contribute it back and we can maintain it for you :) no public interface required
18:34:52 <dstanek> auth_token is just a way for applications to talk to keystone so i would imagine that there are deployments with special needs there
18:34:57 <jamielennox> gyee: that will be fixed with client + auth plugins + the loading from conf stuff
18:34:58 <ayoung> gyee, ssl auth should be in conjunction auth auth_token.  Not to replace it.
18:34:59 <gyee> dolphm, absolutely!
18:35:18 <gyee> ayoung, its the same user
18:35:27 <ayoung> auth_token should be seen as authorization, where as SSL is authentication
18:35:30 <gyee> why go through two stage auth
18:35:43 <ayoung> cert auth should only be used for Keystone itself
18:35:53 <morganfainberg> gyee, this really isn't different than how we handle external auth in keystone.
18:36:04 <dstanek> my thought is that we should have have an explicit policy or name varibles using _ (Python convention) to make this a non-issue
18:36:10 <dolphm> ayoung: it's never made much sense to me to require auth_token to have much in the way of authorization on keystone -- it should only be reading from keystone
18:36:18 <ayoung> dolphm, ++
18:36:19 <dolphm> dstanek: ++
18:36:23 <morganfainberg> dstanek, i think we're getting better about that
18:36:26 <morganfainberg> dstanek, but total agreement ++
18:36:29 <gyee> morganfainberg, we don't want to request a token and then use the it to validate other tokens
18:36:38 <morganfainberg> gyee, no meant functionally
18:36:44 <ayoung> gyee, right.  Agreed.  100 cement.
18:36:53 <morganfainberg> gyee, just where the type of check is done.
18:37:12 <morganfainberg> gyee, it is a similar method, just in auth_token vs keystone :) [impl is obv different]
18:37:28 <dolphm> alrighty, moving on...
18:37:31 <dolphm> #topic Remove Eventlet + new non-httpd wsgi
18:37:32 <dolphm> morganfainberg: o/
18:37:40 <morganfainberg> So had a chat w/ -infra
18:37:53 <morganfainberg> i was told to consider eventlet dead for py33
18:38:05 <morganfainberg> they specifically were asking if we were going to remove eventlet dep or remove py33 check job
18:38:06 <dstanek> yay
18:38:22 <bknudson> every other project is also dropping eventlet?
18:38:23 <morganfainberg> so, the general answer is we should move to wsgiref for basic standalong
18:38:34 <morganfainberg> and trollius for async/eventet/coroutine work
18:38:53 <morganfainberg> bknudson, ideally trollius / tulip is the way forward
18:38:59 <dolphm> trollius in 2.7 == tullip in 3.2 == asyncio in 3.3 (did i get that right?)
18:39:13 <morganfainberg> dolphm, trollius should work for all three afaik
18:39:15 <bknudson> what about 2.6?
18:39:17 <gyee> ++ with dropping eventlet
18:39:28 <morganfainberg> bknudson, trollius = py2 i think
18:39:36 <dolphm> https://pypi.python.org/pypi/trollius Trollius works on Python 2.6-3.4.
18:39:37 <morganfainberg> but in keystone we don't use eventlet (really)
18:39:38 <gyee> actually, ++++++++++++++++++++++++++++++++++++++++++++
18:39:40 <dolphm> quote unquote
18:39:53 <dolphm> morganfainberg: so we should *really* get rid of the dep lol
18:39:57 <morganfainberg> dolphm, ++
18:40:03 <morganfainberg> wsgiref is there for a reason
18:40:11 <dstanek> on that note i have been working on a review based on bknudson's finding - to make our py33 build work
18:40:24 <morganfainberg> both trollius and wsgiref are in the global reqs
18:40:51 <dstanek> won't trollius change the application design to be more callback based?
18:40:56 <bknudson> seems like an easy change early in juno is stop using eventlet & don't worry about the async
18:41:23 <morganfainberg> dstanek, sure, but we don't use the coroutine-like stuff in eventlet
18:41:30 <bknudson> I don't think the monkeypatching got us much anyways since it'd block on sql
18:41:35 <ayoung> 2.6 can die, I think
18:41:38 <jamielennox> i like the dropping of eventlet, lets leave trollius alone until there is more consensus on how to use it
18:41:51 <ayoung> 2.6 was needed for RHEL6, but I think with collections we can get away from that.
18:41:53 <morganfainberg> the basic premise is either remove eventlet or remove py33 check for keystone in the near-term
18:42:07 <morganfainberg> but we can drop eventlet from keystone if we use a different wsgi impl
18:42:09 <bknudson> Let's drop the py33 check for stable/icehouse
18:42:10 <ayoung> Apache HTTPD
18:42:12 <dstanek> what about our use of subprocess?
18:42:26 <morganfainberg> bknudson, no question for I, this is for Juno
18:42:27 <ayoung> dstanek, we'd need a trollius compatable hach
18:42:29 <ayoung> hack
18:42:31 <dolphm> bknudson: stable won't have it, i don't think
18:42:39 <morganfainberg> dolphm, ++ stable shouldn't
18:42:43 <dolphm> it would be non-voting anyway, which is pointless
18:43:08 <bknudson> dstanek: what's wrong with the use of subprocess?
18:43:32 <jamielennox> dstanek: i don't think that pyopenssl has the CMS stuff we need does it?
18:43:57 <dstanek> morganfainberg: in the patch i'm working on we would not need to drop eventlet - certain tests would not run until it was dropped though
18:44:00 <dolphm> there's also pycrypto
18:44:08 <jamielennox> dstanek: i'm longer term hoping that python cryptography will be the way we do that in a library but it will be a while
18:44:09 <dstanek> jamielennox: not as far as i know
18:44:23 <jamielennox> dolphm: i don't think pycrypto does cms, but could be wrong
18:44:33 <ayoung> doesn't yet
18:44:34 <morganfainberg> dstanek, it is still a requirements, if it
18:44:38 <dstanek> bknudson: we use eventlet's patching so that we don't block on subprocess calls (or at least as much)
18:44:41 <morganfainberg> 's in requirements it would fail check
18:44:42 <ayoung> #link https://www.dlitz.net/software/pycrypto/api/current/
18:45:07 <morganfainberg> dstanek, because eventlet can't be installed in py33
18:45:10 <dolphm> as far as i could tell one of either pycrypto or pyopenssl did everything we needed it to, but choked when it came to the arbitrary string manipulation we were doing in the middle
18:45:18 <jamielennox> ayoung: yep that's what i though pycrypto never really dealt with certs
18:45:18 <dstanek> morganfainberg: it won't be in the requirements :-) bknudson found a neat trick that oslo seems to be using
18:45:19 <ayoung> only signature it does is  PKCS#1  which is not CMS
18:45:46 <bknudson> without trollius we'll block on subprocess calls. I assume that we'll have figured out what will work for us by end of juno
18:45:53 <morganfainberg> dstanek, i look forward to seeing it, but i'm skeptical of it not being in requirements
18:46:07 <morganfainberg> dstanek, i think that is going to cause us issues w/ deployments unless we really drop the dep on eventlet
18:46:15 <ayoung> bknudson, Apache HTTPD preform blocking on subprocess calls is OK
18:46:30 <dstanek> bknudson: i don't think tollius help us there which i why i brought it up; it would be nice to just get rid of them anyway
18:46:32 <bknudson> ayoung: but it forks a few keystones?
18:46:52 <dolphm> ayoung: the choice to use CMS is fairly arbitrary right? why not use something that is built into a popular python package?
18:46:58 <ayoung> No
18:47:10 <ayoung> CMS is the closest thing to a standard signature algorithm there is
18:47:16 <jamielennox> dolphm: not really - and there isn't much else
18:48:00 <dolphm> PKCS1 v1.5? RSA + SHA1 signatures
18:48:01 <gyee> CMS is not an algorithm, it is a spec
18:48:06 <dolphm> gyee: correct
18:48:06 <ayoung> OK...I promise to do a blog post enumerating all of the details around CMS.
18:48:25 <gyee> in theory, you can sign anything in any format, just may not be *standard*
18:48:45 <dolphm> or it's a different arbitrary "standard"
18:48:50 <ayoung> PKCS1 is not a very well supported approach.  I was surprised to see it in pycrypto
18:49:13 <ayoung> CMS is S/MIME and pretty much the widest deployed signature approach
18:49:26 <morganfainberg> i know, lets make our own new standard... everyone will switch to it..because..... /xkcd
18:49:39 <gyee> signing basically means, 1) canonicalized the data, 2) hash, 3) encrypt with private key
18:49:51 <dolphm> ayoung: do you have any data to back that up with regard to consumers that we care about?
18:49:53 <ayoung> PKCS #7  Is a standard.
18:50:24 <gyee> xkcd ftw! :D
18:50:44 <ayoung> dolphm, PKCS1 is not a signature standard per-se, it is well: http://en.wikipedia.org/wiki/PKCS_1
18:51:02 <dstanek> what system besides keystone (including kc middlware) cares about the encryption spec?
18:51:07 <jamielennox> i never reallised that pycrypto had pkcs1
18:51:16 <ayoung> http://en.wikipedia.org/wiki/S/MIME
18:51:17 <jamielennox> given that we don't embed the certificates in the token it really is no different
18:51:23 <morganfainberg> dstanek, this is the open standard argument i just made
18:51:28 <dolphm> dstanek: ++
18:51:36 <morganfainberg> dstanek, for hashing algorithm
18:51:43 <bknudson> keystone cms isn't really standard either? it strips off the header/footer -- http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/common/cms.py#n144
18:51:53 <morganfainberg> dstanek, we want to be as open to not using "our method" as possible.
18:51:54 <ayoung> dstanek, yeah...we have end users that kinds of care about this stuff
18:51:59 <dstanek> morganfainberg: but tokens are opaque and only keystone needs to know their details right?
18:52:07 <morganfainberg> dstanek, auth_token needs to know it
18:52:23 <morganfainberg> dstanek, and if auth_token needs to, non-keystoneclient tools might
18:52:31 <dolphm> ayoung: as far as i can tell, you're obfuscating their interests rather than advocating for them
18:52:35 <gyee> dstanek, java clients need to understand it too
18:52:46 <ayoung> bknudson, I could probably make due with straight RSA calls instead of using the CMS call.
18:52:47 <gyee> so yeah, guys like jcloud may want us to use a standard approach
18:53:04 <dolphm> gyee: http://stackoverflow.com/questions/7611383/generating-rsa-keys-in-pkcs1-format-in-java
18:53:08 <ayoung> once we start talking compressed tokens...
18:53:09 <morganfainberg> ayoung, moving to straight RSA calls might be a good alternative
18:53:16 <ayoung> actually, there is more than just that
18:53:25 <ayoung> there is the format of the Data, including where to find the certificate sin side
18:53:26 <dstanek> gyee: that may be a good cenversation to start having then - to see what they really need/want
18:53:30 <jamielennox> ayoung: well it means that we loose the CA
18:53:47 <jamielennox> which given the distribution method may be a problem
18:53:51 <ayoung> yep
18:53:58 <jamielennox> may = will
18:54:02 <ayoung> no, we want to stay with CMS as the basic format
18:54:23 <ayoung> drop the custom base64 butchery
18:54:30 <morganfainberg> ayoung, ++
18:54:36 <jamielennox> ayoung: ++
18:54:38 <ayoung> but we need to be able to tell "who signed this" from the doc itself
18:54:47 <jamielennox> ayoung: straight to DER and then base64 it ourself
18:55:00 <ayoung> jamielennox, with a little zlib in between
18:55:06 <gyee> then what are we gaining from this?
18:55:16 <ayoung> https://review.openstack.org/#/c/71181/24/keystoneclient/common/cms.py
18:55:21 <dolphm> ayoung: the choice to use CMS is still undefended and arbitrary
18:55:34 <dstanek> if we are stuck with cms then someone should dust off their C skills!
18:55:38 <morganfainberg> dolphm, lets use gpg and expect to interact with the gpg binary
18:55:44 <ayoung> dolphm, its like democracy.  The worst option except for all the rest
18:55:53 <morganfainberg> dstanek, M2Crypto yo! i mean...
18:55:55 <gyee> dstanek, extra $$ on the consulting side :)
18:56:19 <jamielennox> i dont see CMS as a problem other than python crypto libraries are crap
18:56:20 <gyee> m2crypto!
18:56:22 <morganfainberg> can we have a new lib: YUNoCrypto
18:56:27 <ayoung> dstanek, I actually have enlisted jdennis as the python-nss maintainer to get better CMS support there
18:56:43 <dstanek> gyee: you're welcome to it
18:56:49 <dolphm> if you use m2crypto and pyopenssl and pycrypto together then you get security++
18:56:50 <ayoung> python-cms?  python-smime?
18:57:05 <morganfainberg> ayoung, probably a good idea, smime
18:57:16 <gyee> dolphm, security++++
18:57:19 <dolphm> jamielennox: and unfortunately our primary consumers are in python
18:57:30 <dolphm> jamielennox: making the arbitrary choice rather poor
18:57:38 <morganfainberg> ayoung, don't like python-cms, it's not really descriptive of waht you're doing, cms is the standard smime is the impl
18:57:39 <ayoung> dolphm, the Python crypto story is not clear at this point
18:57:53 <dstanek> python-cms would be too confusing - not another content management system!
18:58:02 <morganfainberg> dstanek, ++
18:58:03 <ayoung> ++  python-smime then
18:58:12 <morganfainberg> ayoung, i
18:58:15 <gyee> k man, this thing is getting out of hand
18:58:16 <dolphm> ayoung: the python crypto story is that i can't validate tokens in the client due to a lack of library support for the arbitrary choice in standards
18:58:23 <morganfainberg> ve been meaning to dust off c/c++
18:58:25 <ayoung> dolphm, its worse than that
18:58:31 <dolphm> ayoung: but that part is quite clear
18:58:43 * dolphm 2 min
18:58:47 <ayoung> and the choice was not aribitrary.  It is PKCS 7
18:58:53 <morganfainberg> ayoung, maybe we should roll python-smime as under stackforge and get it published
18:59:01 <jamielennox> ayoung: i would prefer that to be in python cryptography - they'll get there
18:59:01 <ayoung> That is the only "signing" standard I know of
18:59:10 <ayoung> jamielennox, ++
18:59:18 <gyee> ayoung, lets start issuing x.509 certs instead of tokens
18:59:27 <ayoung> gyee, no
18:59:31 <dolphm> ayoung: why not?
18:59:33 <ayoung> they serve different needs
18:59:40 <ayoung> certs are authN  tokens AuthZ
18:59:46 <dolphm> yeah, you still need authz
18:59:52 <dolphm> time!
18:59:53 <morganfainberg> jamielennox, the question is, would it be easier to publish a lib and then get it superseded by pycrypto or aim to get it in pycrypto to begin with
19:00:03 <ayoung> there are X509 stnadards for it, but they are no better supported
19:00:08 <ayoung> SAML would make more sense
19:00:12 <morganfainberg> jamielennox, my guess is the former
19:00:23 <morganfainberg> anyway.
19:00:24 <morganfainberg> more to discuss
19:00:25 * dolphm back to #openstack-keystone!
19:00:26 <dolphm> #endmeeting