18:02:10 <dolphm> #startmeeting keystone
18:02:11 <openstack> Meeting started Tue Feb 11 18:02:10 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:15 <openstack> The meeting name has been set to 'keystone'
18:02:22 <morganfainberg> o/
18:02:22 <dolphm> #topic Reminder: Icehouse feature proposal freeze February 18th (features must be in code review)
18:02:22 <morganfainberg> (under the wire!)
18:02:25 <devlaps> o/
18:02:28 <tellesnobrega> o/
18:02:37 <dolphm> we're in *really* good shape for feature freeze, GREAT JOB EVERYONE! :D
18:02:49 <ayoung> dolphm, you probably should add morganfainberg_Z to your notify line to wake him up
18:03:05 <marekd> ayoung: what time does he have now?
18:03:09 <morganfainberg> ayoung, i see pings for all variations on my names
18:03:26 <dolphm> mrgnfeignbern: good to know
18:03:36 <marekd> lol
18:03:39 <ayoung> nice
18:03:41 * morganfainberg adds that now as well
18:03:50 <stevemar> dolphm, Yay!
18:04:03 <dolphm> so we're a week out from feature proposal freeze, with three bp's not "in review" yet -- and i'm not at all worried about any of them at the moment
18:04:05 <dolphm> so let's move on!
18:04:13 <ayoung> dolphm, I snuck in one last item on the agenda.
18:04:13 <stevemar> go team
18:04:19 <dolphm> #topic Spread Domains for other OS services (Nova)
18:04:28 <dolphm> tellesnobrega: i assume this is your topic?
18:04:33 <gyee> \o
18:04:40 <bknudson> how is nova going to use domains?
18:04:50 <tellesnobrega> dolphm: yeap
18:05:01 <dolphm> and this also directly conflicts with hierarchical multitenancy, so i'm interested in what you're thinking
18:05:32 <bknudson> I believe the auth_token middleware sets the domain info in the env
18:05:51 <dolphm> if a domain-scoped token is used
18:05:51 <tiamar> bknudson: it is not in the nova context
18:05:52 <ayoung> HTTP_X_DOMAIN_ID
18:05:53 <henrynash> bknudson: it dies
18:06:01 <dolphm> tiamar: it's in the environment, though
18:06:04 <henrynash> it does, i mean!
18:06:10 <tellesnobrega> nova is just one of the ideas, i was also thinking about glance
18:06:17 <dolphm> tellesnobrega: what's the use case?
18:06:50 <tellesnobrega> for example if we want to have an image that belongs to coca-cola and an image that belongs to pepsi, we dont want them put together
18:07:02 <tellesnobrega> nova is more related to quotas
18:07:07 <ayoung> tellesnobrega, hierarchical multitenacy
18:07:27 <dolphm> tellesnobrega: so, that doesn't require domain-scoped authorization
18:07:29 <ayoung> do something at one level of the tree, and only have it vbisible to subnodes
18:07:47 <tellesnobrega> i see
18:07:54 <bknudson> I'm guessing you can't do anything with a domain-scoped token outside of keystone
18:07:59 <henrynash> ayoung: really?  you mean by having a single top level project in each domain that contains the images?
18:08:05 <tiamar> some other actions may require domain-scoped auth
18:08:13 <ayoung> henrynash, domain *is* the top level project
18:08:14 <tiamar> bknudson, correct
18:08:22 <dolphm> tellesnobrega: but rather user- or project-domain based quota enforcement, which are passed to nova as x-user-domain-id and x-project-domain-id
18:08:26 <ayoung> lets accept two things, one, domains are unnecessary
18:08:34 <ayoung> two  we are not going to b e able to get rid of domains
18:08:41 <dolphm> tiamar: like what?
18:08:42 <lbragstad> the domain (top-level) would contain the most public images
18:08:45 <bknudson> ayoung: how do you have namespaces for users without domains?
18:08:46 <ayoung> ok...its a language thing, not a "best design" thing
18:09:00 <ayoung> bknudson, ah...let me rephrase
18:09:09 <dolphm> tiamar: "may": sure. do we have a specific use case to discuss?
18:09:15 <mrgnfeignbern> ayoung, ++
18:09:26 <ayoung> for assignments, domains are unnecessary, but we won't be able to remove them becvause they are embeddd in the collective brain of our users
18:09:47 <dolphm> lbragstad: that steps into hierarchical multitenancy; it's not a use case for our existing definition of "domains" which do NOT own openstack resources
18:10:11 <tiamar> dolphm: mainly to big deployments of Openstack, where a top level administrator may set things i.e images, quotas to a entire domain and projects a domain owns
18:10:18 <mrgnfeignbern> ayoung, this is related to our conversation yesterday...
18:10:19 <lbragstad> makes sense
18:10:33 <henrynash> ayoung: we need *some* administrative construct that allowes the creation of levels of administration scope
18:10:39 <bknudson> do domains own projects?
18:10:50 <henrynash> bknudosn: today, ues
18:10:54 <ayoung> mrgnfeignbern, so I would say that root, domain, and nested projects are the terms we use.  implementation wise, they can all be the same thing
18:10:55 <henrynash> today, yes
18:10:57 <dolphm> henrynash: hierarchical multitenancy :)
18:11:08 <mrgnfeignbern> ayoung, aye,
18:11:12 <ayoung> root namespaces domains
18:11:16 <tiamar> +1
18:11:17 <ayoung> domains namespace projects
18:11:27 <ayoung> projects namespace subordinate projects
18:11:42 <ayoung> we use different terms for Hysterical Raisins
18:11:46 <tellesnobrega> +1
18:12:31 <gyee> ayoung, you saying domains contains projects and project contains subprojects? just make sure I understand
18:12:33 <dolphm> tiamar: so the use case is distributed domain-wide quota enforcement; what do you need from the keystone community?
18:12:43 <dolphm> tellesnobrega: ^
18:12:44 <ayoung> gyee, that is my view, yes
18:12:52 <henrynash> dolphm: and that's fine…..as long as we have the support for how we define users such that hierarchical multitenacy can be used to infer scope of administration
18:13:25 <dolphm> henrynash: if by "infer" you mean "explicitly define" -- then yes! that's the goal
18:13:26 <tiamar> dolphm: not only that, but a domain administrator that could do anythign with a single token in Nova for example
18:13:35 <gyee> ayoung, I don't have a firm opinion right now, but I hear ya
18:13:38 <henrynash> dolphm: that'll do too !
18:13:39 <tellesnobrega> tiamar: +1
18:13:56 <ayoung> now...a domain is also a concept in identity, so the domain object will have one more, optional field, which is "what IdP do domain users live in"
18:14:11 <dolphm> tiamar: that conflicts with our existing concept of multitenancy; you need hierarchical multitenancy for that, and it's an *entirely* separate discussion
18:14:17 <ayoung> you have to squint a little to see it, but, feh
18:14:26 <dolphm> tiamar: probably best saved for the friday meeting, as it evolves
18:15:02 <tiamar> dolphm: ok. but domain isolation is also necessary for multitenancy in Nova, glance...
18:15:10 <ayoung> tiamar, it will be there
18:15:15 <dolphm> tiamar: explain?
18:15:23 <tiamar> ayoung: how?
18:15:38 <ayoung> tiamar, a domain is a top level project with no named parent.  It will come right off of "root" a majic project-type-thingy
18:15:55 <dolphm> tiamar: nova and glance have no need to care about domains to provide any aspect of multitenancy whatsoever
18:15:59 <tiamar> ayoung: with the nested projects?
18:16:03 <ayoung> tiamar, replace the term domain with project, and say that projects are hierarchical
18:16:23 <ayoung> and that a resource in a parent node is visible to all children
18:16:30 <tellesnobrega> dolphm: if we want to have an image that belongs to a specific domain?
18:16:42 <dolphm> tellesnobrega: that currently makes no sense, as domains do not own resources
18:16:52 <ayoung> tellesnobrega, then it is owned by that domain and visible to all subprojects in that domain
18:17:09 <tiamar> ayoung: yes, but doesn't this replacement requires a lot of code rewrite in keystone? does it affect about policy.v3cloudsample.json? I love this file
18:17:13 <dolphm> tellesnobrega: again, you're providing use cases for hierarchical multitenancy, so i'd suggest bringing up the use case in that meeting / pursuing hierarchical multitenancy first
18:17:20 <ayoung> and if it is owned by dom1->p1->p2  it is visible to dom1->p1->p2->p3
18:17:37 <ayoung> tiamar, it requires code, yes
18:17:52 <ayoung> that is why we are discussing it.  I think we should table until Friday and move on.
18:18:02 <tellesnobrega> dolphm: sure
18:18:10 <tiamar> ayoung: ok
18:18:28 <dolphm> ayoung: i think so too
18:18:32 <dolphm> #topic Fixing multi-domain LDAP support
18:18:34 <dolphm> henrynash: o/
18:18:46 <dolphm> henrynash: i can provide some background here if you'd like
18:18:46 <ayoung> see the above line about the domain table
18:19:20 <dolphm> henrynash: (although i don't have any links in front of me)
18:19:25 <henrynash> ok so the plan for this had been to fix the assignment tables, and then layer a fix for the multi-domain LDAP on top of it (as discussed in San Antonio)
18:19:35 <ayoung> we need to be able to safely generate userids based on LDAP source.
18:19:39 <ayoung> Same problem as Fedration has
18:19:42 <morganfainberg> yesh.
18:19:54 <ayoung> morganfainberg, put away the booze
18:20:17 <dolphm> henrynash: ah, i missed that discussion
18:20:18 <morganfainberg> ayoung, but :(
18:20:21 <henrynash> most of the code for multi-domain LDAP is OK…the bit that isn't is where we try and infer the domain_id (to ayoung's point)
18:20:47 <ayoung> henrynash, I don't know if we need to infer it, so long as the generation is safe
18:20:58 <ayoung> but we do need to have larger fields to incorperate
18:21:12 <henrynash> ayoung: Oh, I agree…but the CURRENT code tries to infer it, which is the bit that is broken
18:21:19 <ayoung> sure
18:21:34 <bknudson> where is the explicit domain id if we don't infer it?
18:21:38 <ayoung> henrynash, so...I think the hack goes, for now, in the LDAP driver id_to_dn
18:21:42 <ayoung> and the reverse
18:21:50 <henrynash> ayoung: agreed
18:21:51 <ayoung> we need to support the existing approach
18:22:02 <ayoung> si if CONF.multi_domain_backends....
18:22:38 <henrynash> dolphm: so basically, I'l like to driver this to closure now the assignment tables are ready for review…in conjunction with ayoung
18:22:58 <dolphm> henrynash: is it realistic to ship icehouse with this fixed?
18:23:17 <henrynash> dolpm: I think so…young"
18:23:21 <ayoung> henrynash, so I had a SQL question
18:23:27 <dolphm> i'd rather not ship another release with documentation for a broken feature
18:23:33 <ayoung> is there something magic about 64 chars long keys?
18:23:36 <henrynash> dolphm: ++
18:23:41 <dolphm> ayoung: no
18:23:44 <morganfainberg> ayoung, no
18:23:51 <ayoung> if we up the key length to...I guess 130 chars, do we have the same support?
18:23:57 <ayoung> Is there some number we need to stay under?
18:23:59 <dolphm> ayoung: up to 255
18:24:01 <ayoung> 512?
18:24:02 <morganfainberg> or varchar255
18:24:03 <ayoung> OK.
18:24:13 <bknudson> len(uuid.uuid4().hex) == 32
18:24:15 <morganfainberg> ayoung, > 255 has implications in mysql
18:24:33 <henrynash> ayoung: so we either do that or we store it in two fields in the new assignment table and we return a composite key from the driver….
18:24:36 <dolphm> bknudson: yeah, i don't know why they were ever 64 to begin with
18:24:38 <ayoung> morganfainberg, and pg and DB2 are OK with <255 as well?
18:24:40 <dolphm> bknudson: essex-ism
18:24:44 <morganfainberg> ayoung, pg will be
18:24:46 <dolphm> ayoung: yep
18:24:48 <morganfainberg> bknudson, db2?^
18:24:55 <dolphm> oh, don't know about db2
18:25:01 <bknudson> I don't think db2 is going to have a problem with a longer key
18:25:04 <lbragstad> morganfainberg: it will truncate on varchar255, won't it?
18:25:15 <dolphm> lbragstad: how convenient!
18:25:19 <morganfainberg> lbragstad, thats the implication w/ mysql,
18:25:19 <bknudson> it's the total length of all the fields in the column that might have an effect on the pagesize.
18:25:29 <morganfainberg> lbragstad, i think pg is less... picky
18:25:40 <dolphm> morganfainberg: doesn't pg barf?
18:25:47 <ayoung> OK, so lets expand the key size to the max safe length, explain why we are doing it, and have a comment in there saying "we can't go any larger"
18:25:56 <morganfainberg> dolphm, doesn't matter, 255 is what we're setting it at ;)
18:26:02 <dolphm> sure
18:26:08 <morganfainberg> dolphm, oh if value > 255, yeah
18:26:13 <ayoung> then, for  user and groups IDs from LDAP, it is ldap-attribute@@domain_id
18:26:43 <topol> two @@ or one?
18:26:45 <dolphm> henrynash: if we don't have a "fix" for multi-ldap by feature freeze, i'd at least like to ship icehouse with the relevant docs commented out or removed
18:26:46 <ayoung> two
18:26:55 <ayoung> topol, to avoid tripping on people using an email address
18:26:58 <ayoung> topol, so
18:27:10 <ayoung> ayoung@redhat.com@@abcd1234  is OK
18:27:12 <henrynash> dolphm: You'll have a fix in code review by the 18th
18:27:16 <dolphm> henrynash: the "guess my domain" code needs a giant docstr explaining how broken it is as well, and not to use it as-is
18:27:28 <dolphm> henrynash: alright
18:27:37 <dolphm> henrynash: is there a bug or something we can track against i3?
18:27:46 <bknudson> the fix is not going to be guessing domains, I hope?
18:27:50 <henrynash> dolphm: yes, there is…let me find it
18:27:56 <morganfainberg> bknudson, no no guessing
18:28:03 <ayoung> its also essential that the code that we don't break existing LDAP deployments, or timbell will be sad
18:28:16 <ayoung> We don't need to "guess domains"
18:28:24 <ayoung> we just need to be safe in generating the userids
18:29:04 <ayoung> Oh...wait, for the list users stuff...we need a field in the domain table
18:29:49 <dolphm> ayoung: i'm just talking about the code that's currently in master
18:30:22 <ayoung> dolphm, yeah...so looking up a user by userid...can we just say that for multi domains, user domain id needs to be specified in the token request etc?
18:30:42 <dolphm> ayoung: that's an API change, but you can propose it
18:30:55 <morganfainberg> ayoung, i don't think that is unreasonable.  but yeah.. api change (but it's not incompatible)
18:31:18 <dolphm> morganfainberg: actually, it's an additional required attribute, so it is backwards-incompatible
18:31:21 <bknudson> get/users/ayoug@@edhat.com@@abcd1234 ?
18:31:32 <bknudson> oops GET /v3/users/ayoug@@edhat.com@@abcd1234 ?
18:31:38 <morganfainberg> dolphm, no it's only incompatible if you enable multi-domains
18:31:45 <morganfainberg> dolphm, oh oh wait..
18:31:53 <morganfainberg> dolphm, this would include the sql backends?
18:32:03 <morganfainberg> yeaaah nvm i'm wrong
18:32:04 <henrynash> dolphm: I can't find the explicit defect (I thought there was one), there's this: https://bugs.launchpad.net/keystone/+bug/1226171
18:32:05 <bknudson> GET /v3/users/ayoug@redhat.com@@abcd1234
18:32:06 <uvirtbot> Launchpad bug 1226171 in keystone "When using per-domain-identity backend, user_ids could collide" [Medium,Triaged]
18:33:00 <bknudson> seems like we'd break everybody if we changed the user ID format.
18:33:05 <ayoung> ok...so is userid parsing acceptable?
18:33:33 <ayoung> either way (explicit domain id or userid parsing) we need to map from domain id to LDAP backend
18:33:44 <ayoung> which means we need a way to enumerate the backends
18:33:45 <dolphm> henrynash: that works for now
18:34:14 <dolphm> ayoung: as long as keystone owns ID's, it's acceptable IMO
18:34:20 <ayoung> bknudson, we just say that userid is a blob, but the LDAP folks have dealt with the assumption of UUID for user id already
18:34:27 <ayoung> dolphm, ++
18:34:40 <ayoung> OK, so how do we go from domain table to the LDAP config?
18:34:56 <morganfainberg> bknudson, if we change the id format we can also do "if it's not the 'new-format' handle it in a specific backwards-compatible way"
18:34:57 <ayoung> or, more correctly, can we make it so that this works for Federation as well
18:35:16 <henrynash> ayoung: the multi-domain config files are "indexed" by domain name (or ID, one or the other)
18:35:29 <dstanek> just a quick note about the above user ids - we need to make sure @ is url safe or bknudson is right we could break things
18:35:35 <dolphm> in the face of hierarchical multitenancy, i should put my patch back up for configurable UUID lengths (so we don't hit that 255 limit immediately)
18:35:57 <ayoung> I'd like to treat the SQL backend, any LDAP backens, and the Federated "backends" as different forms of the same thing.
18:36:07 <henrynash> ayoung: ++
18:36:16 <dolphm> henrynash: that should be replaced with one or the other
18:36:21 <dolphm> henrynash: the indexing by name or id
18:36:24 <ayoung> is the @ sign going to make things break>?
18:36:26 <morganfainberg> dolphm, ? configurable uuid lengths?
18:36:29 <dolphm> henrynash: just pick one; i think names are terrible but that's just me
18:36:36 <henrynash> dolphm: it is one ptr the other, I just can't remember which!
18:36:44 <ayoung> I know people are using email addresses for userids already
18:36:50 <ayoung> I can't see that @@ is any worse.
18:36:56 <morganfainberg> henrynash, files are indexed by name afaik for the external configs
18:37:01 <henrynash> dolphm: I think it is name so that it is human readable
18:37:04 <dolphm> morganfainberg: i replaced all the uuid.uuid4().hex calls with something in keystone.common that did uuid.uuid4().hex[:CONF.uuid_length]
18:37:08 <morganfainberg> henrynash, it uses domain-name.conf and reads it in
18:37:31 <dstanek> ayoung: i would guess yes since the @ is usually before the domain portion of a url, but if we aleady have some...
18:37:44 <dolphm> morganfainberg: i got shot down due to increased risk of collision, but it sounds like a more interesting tradeoff now
18:37:51 <morganfainberg> dolphm, hm....
18:38:11 <morganfainberg> dolphm, because we have uuid@@uuid possibly?
18:38:26 <morganfainberg> but aren't our uuids 64 in len as is?
18:38:38 <morganfainberg> dolphm, i'm confused on the benefit of trimming them down
18:39:01 <dolphm> morganfainberg: uuid@@openstack.domain_uuid.project_uuid.subproject_uuid
18:39:05 <dolphm> risk of ^
18:39:20 <ayoung> NO!
18:39:29 <morganfainberg> dolphm, we should move to another column type
18:39:32 <morganfainberg> dolphm, if we did that
18:39:34 <dolphm> lol
18:39:36 <ayoung> project Ids are not domain scoped.  They are assigned by Keystone
18:39:37 <morganfainberg> dolphm, not truncated uuids
18:39:50 <ayoung> unless they want to pull them in from LDAP (in the future)
18:40:07 <ayoung> in which case it would be, at most LDAPattribute@uuid
18:40:13 <ayoung> but not more nesting than that
18:40:27 <dolphm> ayoung: i'm referring to hierarchical multitenancy (which now needs an acronym badly because i don't want to type that anymore), where they might be exposed like that
18:40:38 <morganfainberg> HMT
18:40:40 <stevemar> HMT
18:40:42 <dolphm> yay
18:40:52 <topol> HMT4U
18:40:58 <morganfainberg> topol ++
18:41:00 <henrynash> PMT?
18:41:01 <morganfainberg> ;)
18:41:01 <lbragstad> topol: ++
18:41:04 * dolphm just tried to type that and muscle-memoried HTML
18:41:06 <ayoung> Aitch Emm Tee
18:41:10 <ayoung> Heh
18:41:33 <ayoung> Heavy MeTal?
18:41:33 <stevemar> dolphm, you'll manage
18:41:48 <henrynash> ayoung: very good
18:41:48 <morganfainberg> ok, so if that is legitimately a concern, we should look at alternate column types
18:42:07 <bknudson> should be hierarchical multiprojectcy since we changed the term.
18:42:08 <morganfainberg> but, they'll need other work for indexing properly then (PK isn't viable on some of them)
18:42:10 <dolphm> in juno+1 we can rename HMT to HMP (hierarhical multiprojectsy)
18:42:18 <morganfainberg> dolphm, ++
18:42:29 <dolphm> anyway... what else is on the agenda...
18:42:32 <ayoung> keys need to stay short, as they are used in indexes, you don't want them going into the big text blob that most RDBMSes do for freeform text
18:42:41 <dolphm> #topic Specifying format for compressed tokens
18:42:43 <dolphm> ayoung: o/
18:42:49 <ayoung> OK...so this is pretty cool
18:42:59 <dolphm> ayoung: is this referring to the static prefix?
18:43:03 <ayoung> I've been learning a little bit more about CMS
18:43:09 <morganfainberg> dolphm, at the end have a quick review / bp to bring up as possible i3 target
18:43:14 <morganfainberg> (code is already up)
18:43:28 <ayoung> I need a way to specify that a token is in comporessed format
18:43:31 <dolphm> morganfainberg: (?)
18:43:43 <ayoung> the current brokenness is look for MII  at the start of the token
18:43:52 <morganfainberg> dolphm, let ayoung do his topic and i'll then jump in with the quick bit after
18:43:53 <bknudson> where does MII come from?
18:43:56 <ayoung> that is length specific, so with compression, it will not be MII
18:44:06 <ayoung> I was going with {cmsz} as a prefix
18:44:14 <ayoung> but...that i s kindof made up
18:44:17 <bknudson> an explicit prefix makes more sense
18:44:24 <morganfainberg> bknudson, ++
18:44:28 <ayoung> it would be nice if it were something that said "here is how you deal with the data"
18:44:32 <morganfainberg> i like explicit - known prefixes
18:44:34 <jamielennox> bknudson: it's a quirk of encoding the start of a CMS token into base64
18:44:39 <ayoung> and the order of ops most people need to do is:
18:44:47 <gyee> bknudson, that is base64 encoded asn.1 thing
18:44:48 <dolphm> ayoung: you know the zlib output contains gzip headers, correct?
18:44:56 <dolphm> so, it's already clear that it's compressed
18:45:00 <ayoung> base64 decode, uncompress, verify sign, parse JSON
18:45:24 <morganfainberg> dolphm, but not everything has headers like that.
18:45:24 <ayoung> dolphm, yeah...and that is also an option:  just say that it is BASE64 and then deduce at each step
18:45:34 <ayoung> the formats we  need to deal with are
18:45:35 <dolphm> or something gzip compatible; i'm not clear on what zlib does different from plain "gzip"
18:45:38 <morganfainberg> dolphm, might make sense ot just say "this is what it is"
18:45:45 <ayoung> base64, gzip, der, JSON
18:46:04 <dolphm> morganfainberg: i'm not opposed to something human-readable, i'm just pointing out that it's not entirely machine-useful
18:46:12 <dolphm> rather, it's redundant
18:46:29 <ayoung> now, there are not an clear content types in HTML land for this, mainly because crypto, comoppression, etc are done as separate HTML headers
18:46:52 <ayoung> I was thinking
18:46:53 <dolphm> ayoung: it's also in a header by itself, and should be opaque to clients
18:47:01 <dolphm> ayoung: you shouldn't expect clients to work with headers for this
18:47:04 <dolphm> (other) headers
18:47:11 <ayoung> application/JSON+CMS+GZIP+BASE64
18:47:19 <ayoung> dolphm, right
18:47:26 <gyee> ayoung, I though CMS offer compression as well, lemme check the spec
18:47:29 <ayoung> so I was strwamanning using ^^ as the prefix
18:47:41 <ayoung> gyee, I am pretty sure it does
18:47:49 <dolphm> ayoung: why not use that?
18:47:59 <jamielennox> gyee: i've never seen that
18:48:06 <gyee> https://tools.ietf.org/html/rfc3274
18:48:07 <ayoung> dolphm, well we still need a way to detect the token type
18:48:19 <dolphm> ayoung: that's also giant, and starts to bulk the token back up!
18:48:20 <morganfainberg> gyee, beat me to it
18:48:30 <gyee> not sure if its been superseded though
18:48:43 <dolphm> ayoung: if CMS handles compression already, then it wouldn't be our problem
18:48:43 <ayoung> dolphm, yep...I am aware,
18:48:52 <jamielennox> gyee: awesome
18:48:55 <ayoung> dolphm, CMS format might, not sure if the tools expose it
18:49:02 <ayoung> Let me see...
18:49:07 <dolphm> so, does openssl support that spec?
18:49:30 <gyee> dolphm, should, but need to double check
18:49:38 <dolphm> that spec makes a good argument for compressing before signing
18:49:43 <ayoung> the lib does
18:49:45 <ayoung> http://www.openssl.org/docs/crypto/CMS_compress.html
18:49:49 <ayoung> not sure if the CLI does
18:49:55 <ayoung> I don't see a switch for it
18:50:11 <ayoung> -compress
18:50:21 <ayoung> okits not inthe man page, but on the site.  let me play around with that
18:50:32 <ayoung> http://www.openssl.org/docs/apps/cms.html
18:50:49 <ayoung> so...what to do about detecting token format, then?
18:51:14 <dolphm> ayoung: can you hit -dev with a clear breakdown of the options?
18:51:17 <morganfainberg> ayoung, might be a new(er) release than the cli
18:51:19 <bknudson> then you'll need --uncompress on the other side?
18:51:27 <dolphm> ayoung: we have several viable paths at this point, it seems :)
18:51:31 <ayoung> bknudson, I think that might be done by default
18:51:33 <gyee> ayoung, we should use a header to indicate the token format
18:51:42 <gyee> I think that's the proper way to do this
18:51:43 <jamielennox> ayoung: nothing? it means we keep a CMS packet and we can just detect whether its compressed or not
18:51:51 <dolphm> plus it'd be fun to advertise support for this to a broader audience
18:52:03 <ayoung> dolphm, yep...and there is one other nastiness I was hoping to clean up, which is base64 should be url_safe...I think I might be able to get that, too
18:52:04 <dolphm> gyee: i don't think so
18:52:05 <jamielennox> gyee: i don't think we should add more headers
18:52:18 <gyee> dolphm, why not?
18:52:24 <morganfainberg> jamielennox, we should move everything to headers.
18:52:28 <morganfainberg> jamielennox, EVERYTHING
18:52:30 <morganfainberg> jamielennox, ;)
18:52:33 <dolphm> gyee: because the token should be opaque
18:52:33 <ayoung> jamielennox, I think I can check the length, and, if it is greater then len of a uuid, perform a base64decode on it
18:52:56 <gyee> CMS tokens are not opaque, they contain stuff
18:52:59 <jamielennox> ayoung: if it's a CMS token though we should be able to still check for MII
18:53:01 <ayoung> OK..I have some work to do...I think I can drop all of the PEM stuff
18:53:07 <ayoung> jamielennox, nope
18:53:13 <ayoung> MII won't work if it is compressed
18:53:17 <gyee> they are essentially signed documents
18:53:24 <ayoung> it MII is length of the token dependent
18:53:25 * dolphm going to cut the meeting 5 minutes short as i have to run soon
18:53:31 <ayoung> I think I'm good
18:53:40 <jamielennox> ayoung: it won't work if we gzipped a token - if we have compresseddata in cms it probably will
18:53:50 <ayoung> jamielennox, ++ that is what I meant
18:53:50 <dolphm> jamielennox: if openssl supports compressed CMS, then ++
18:53:53 <jamielennox> gyee: clients don't know that yet
18:53:58 <jamielennox> s/yet/though
18:54:00 <dguitarbite> .
18:54:01 * ayoung going to test
18:54:04 <gyee> jamelennox, they will right? :)
18:54:09 <jamielennox> gyee: no
18:54:15 <bknudson> ayoung: thanks for looking into this. I think it will make a lot of users happy to have smaller tokens.
18:54:16 <dolphm> gyee: they're not opaque to keystone tools, they're opaque to clients and need to remain so
18:54:19 <jamielennox> gyee: for no reason i can think of
18:54:29 <ayoung> it should be transparent.  When the check the signature, library should see it is compressed
18:54:55 <dolphm> try: zlib.decompress(token) except: pass
18:54:59 <ayoung> I might abandon the old review, if the code is radically simpler
18:55:29 <dolphm> cool
18:55:36 <dolphm> cutting it short... thanks everyone!
18:55:38 <dolphm> #endmeeting