[openstack-dev] [Barbican][Security] Automatic Certificate Management Environment

Douglas Mendizábal douglas.mendizabal at rackspace.com
Mon Sep 28 15:25:32 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Rob,

I agree that the ACME standard is very interesting, but I'm also
pretty new to it.  And by pretty new I mean I just started reading it
after I saw your email. :)

There has been interest in adding support for Let's Encrypt as a
Barbican back end since it was first announced, but I don't think
anyone has looked into it recently.

Being able to deploy Barbican and issue free certificates via Let's
Encrypt is a very compelling feature, but it's definitely going to
take some effort to figure out the best way to do it.  The first issue
that I can see is sorting out auth.  The Public CA plugins we're
developing all work under the assumption that Barbican itself is a
client to the CA and has a set of credentials that can be used to
interact with it.

The Let's Encrypt model is different in that Barbican itself probably
does not want to have a set of credentials to to talk to Let's
Encrypt, or we would end up owning all of our client's certs.  So
we'll have to figure out a way for clients to be able to provide their
Let's Encrypt credentials to Barbican.

Another challenge is going to be sorting out the automated domain
verification.  We could possibly just proxy the challenges to the
client and then wait for the client to let us know which verification
challenges have been completed.

As far as supporting ACME on the front end, I'm not sure it would be
possible.  There is a lot of overlap between ACME and the current
Barbican CMS API.  Adding support for ACME would basically mean
supporting two competing APIs in a single product, which is sure to
cause confusion and a ton of overhead in development.

Additionally, there are features in ACME that I think would prove
almost impossible to support with existing public CAs.  Namely the
automated challenge feature.  Currently Barbican CMS defers the Domain
Validation to some out-of-band process between the CA and the client.
 So you could, for example, order a Symantec Cert using the Barbican
API.  Barbican would begin the Cert workflow in an automated fashion,
but at some point someone from Symantec is going to email the domain
owner and they're going to have to respond to the challenges the good
old fashioned way.

I think that a prerequisite for ACME support on the front end is going
to be Public CA support of the ACME standard.  At that point we could
probably phase out the Barbican CMS API, and just support ACME on the
front end.

- - Douglas Mendizábal

On 9/24/15 10:12 AM, Clark, Robert Graham wrote:
> Hi All,
> 
> So I did a bit of tyre kicking with Letsencrypt today, one of the
> things I thought was interesting was the adherence to the
> burgeoning Automatic Certificate Management Environment (ACME)
> standard.
> 
> https://letsencrypt.github.io/acme-spec/
> 
> It’s one of the more readable crypto related standards drafts out
> there, reading it has me wondering how this might be useful for
> Anchor, or indeed for Barbican where things get quite interesting,
> both at the front end (enabling ACME clients to engage with
> Barbican) or at the back end (enabling Barbican to talk to any
> number of ACME enabled CA endpoints.
> 
> I was wondering if there’s been any discussion/review here, I’m new
> to ACME but I’m not sure if I’m late to the party…
> 
> Cheers -Rob
> 
> ______________________________________________________________________
____
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCVvsAAoJEB7Z2EQgmLX7eMUP/1qRXJJfmmQgI/z4rj13ug8q
IAG+iENDhhXojZyvf0F87zhj6DnQSTOzGwKIotP0FxUpLGSiNOYsKix4+OIShWqH
7HPdMLZnl6cROf/n11QgSQouvhRpUTW/UKtGaPGCO2Lw53LXHQqNOXCQdq12mdhT
CB9+55PpG7dr3bY9vX9PeB61QP410+c68ICcHhpOAFEm5TnmV0NL2JQ0zkjwENM3
s3kwIyZE3awZg3fp9zdxzuI87OEqQ+f4PN55q7GMJjwAdU72SU7crFjrpJxlPCCr
LuEb6J1rz9I5eThp2woaLOS1w4irBwrk5kp+0Af8Z2VZqWo2/mX6VlQJ5cgIMQdp
je3Ku500bQSjWAfv8/CJBIQ4bkBnOwaBWxzsXEzYDlHofQQHHubpsUlV202BOtIZ
F9BN0P/siwSQ+GOmCYd64AfAsBwjiY7uhOong50GFjThDkLxgRuOXjtt7u7ZBfvF
PbLRfo9teJju6zQHrE+G4WUURdBIP9NEDr7kkT7uDcVXNrPLY/8Op4tdws5yk49w
BFlWrjCZ8uuhDGm6gyaLzjcY/UU3Zwf8G4E4CL7YpWYLhVuaqs7ig/qbTUEK/xdt
+C6yU6JJGYT9j+H18sZOCMlvXRNG3W9CO/6fKiZ1PprsYXDN2UYfYHIyBNROeVkj
au8DQsYCyQBpkJStuJwt
=8g77
-----END PGP SIGNATURE-----



More information about the OpenStack-dev mailing list