We’ve been looking into CA’s that give you an instant response on a certificate signing request (based on various conditions) - I’m not sure that we can easily make this work with the state structures described?
Our basic flow is Client —[https|somecreds|some <https://somecreds|some>csr]--> CA Client <—[https|certificate/error400]—CA The CA does a lot of stuff in the backend but for the purposes of this the decision about making the cert is instant, there’s no ‘queue’ to wait on. It’s not immediately clear to me if there’s some option to shortcut the states laid out to make a plugin work nicely with our prototype CA… Cheers -Rob From: John Wood <[email protected]<mailto:[email protected]>> Reply-To: OpenStack List <[email protected]<mailto:[email protected]>> Date: Thursday, 17 July 2014 15:37 To: OpenStack List <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [openstack-dev] [barbican] Etherpad discussion related to ssl certificate workflow CR Hello folks, Ade raised concerns about the approach taken in the SSL cert CR here: https://review.openstack.org/#/c/107190/ In short, he suggests that a state machine approach that gives plugins a lot of control over workflow is not needed, and could lead to plugin developers having more difficulty creating new plugins. I think he has valid points, so I created an etherpad that details a 'generic' workflow approach, and an approach that simplifies what the plugins need to do (offloading logic to Barbican): https://etherpad.openstack.org/p/barbican-order-cert-gen-interactions Please take a look at the etherpad and weigh in if you can. Thanks, John _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
