Hello folks, FWIW, we've been trying to refine the ssl cert generation workflows via this blueprint: https://blueprints.launchpad.net/barbican/+spec/add-ssl-ca-support
These flows could be kicked off via the orders API. Thanks, John ________________________________ From: Adam Young [[email protected]] Sent: Monday, April 28, 2014 2:52 PM To: [email protected] Subject: Re: [openstack-dev] [barbican] certificate orders discussion On 04/28/2014 02:07 PM, Pitucha, Stanislaw Izaak wrote: Hi all, I've seen some blueprints/wikis from people interested in certificate signing via barbican orders, so hopefully you'll have some feedback. I submitted a proposal for certificate/signing order API at https://review.openstack.org/90613 (based on previous Arvind's work with keys) Good stuff. It's not pretty and needs some more details, but it's there :) There are some things I wasn't really sure how to handle, so here's my reasoning you may have an opinion on: 1. The keys for generating a new certificate request + signing could be handled inside of the generate+sign order. This would require fewer requests than uploading a key as a secret first, but on the other hand, there's already an api for generating those keys, so it would be nice to just reference the key potentially already generated by barbican. I went with posting an id reference to the key. Lets not reinvent a format here. Certmonger can already do that stuff client side, so lets just focus on getting the request to the server, signed, and returned. 2. The signing-only request takes the pkcs10-style csr inline in its meta part. I thought about treating it that same as the key decision above, but thought this would be wrong. The request isn't really secret - it doesn't contain any private data, so it would be incorrect to treat it the same as keys. Correct. This should be simpler than a Keys escrow call: you might want to do key escrow for encryption keys that get signed this way, but that could used the existing mechanism via a separate call, either prior or after. Prior might be the way to go: "if you request a certificate with an encryption attribute, you need to have submitted the key for escrow." On the other hand, having one order to generate a CSR and one to sign it would be a cleaner design without a mix of attributes that are required or not depending on the use case. In this case the first option won - just include it as inline - generation of the request by barbican is unlikely to be a very common case. Otherwise, if you're interested in certificate orders, please have a look and see if the proposed api is missing any parts you would like to see. Maybe we can figure it out before the coding starts :) Lets get the basics down: process a CSR. We still need to handle the workflow for approval. Regards, Stanisław Pitucha Cloud Services Hewlett Packard _______________________________________________ OpenStack-dev mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
