Open Stack

On Fri, 2013-04-26 at 20:11 -0400, Eric Windisch wrote:
> I meant the keyserver software itself. Your keyserver needs to be a
> custom built to purpose service. To scale that keyserver, you'll need
> to run more of them. Maybe you can deploy some HTTP proxies for
> caching. This is additional infrastructure for organizations to
> support and organizations will only add as much as they can afford to.

I am currently planning to bake this stuff into keystone, but it could
be a separate service.
In any case I am being careful in the design about making sure it is
easy to deploy duplicate copies to allow scaling.

> A PKI-based solution could potentially allow a pluggable keysever
> component that might be scaled in a variety of ways that may leverage
> existing infrastructure.  DNS, Swift, etc…
> 
> However, to play devil's advocate against myself, if the PKI solution
> doesn't *also* use a custom built-to-purpose service as a keyserver,
> it complicates the revocation story.

You cannot handle revocation at all, nor you can check the certificates
are legit to start with. I don't think there is any chance to run a PKI
based system without a Central Authority, or some sort of central
repository.

> At least, perhaps, with PKI we do open the possibility of a pluggable
> keyserver mechanism and changing the keyserver solution -- whereas the
> shared-key solution will need to be much more baked-in and
> tightly-coupled?

Not sure what this means honestly.

Simo.
> 
-- 
Simo Sorce * Red Hat, Inc * New York