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 <john.wood at RACKSPACE.COM<mailto:john.wood at RACKSPACE.COM>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>> Date: Thursday, 17 July 2014 15:37 To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>> Cc: "barbican at lists.rackspace.com<mailto:barbican at lists.rackspace.com>" <barbican at lists.rackspace.com<mailto:barbican at lists.rackspace.com>> 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