Open Stack

Hello Justin,

First off, the current implementation of Barbican only supports one encrypted payload per secret record. We plan to revisit this once we begin work on the SSL certificate processing features.

As for the Barbican API, please note that the latest Barbican API is located here: https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface

As detailed in this wiki page, the current implementation of Barbican utilizes an 'Accept' request header to indicate to the Barbican service which media type to return the secret in. If 'application/json' is provided, only the secret's metadata is returned (i.e. nothing is decrypted). Alternate 'Accept' types may then be used to decrypted and return the secret, such as 'application/octet-stream' from binary secret types, and 'text/plain' for text based secrets.

Effectively these are different representations of the same REST-ful secret resource, which we believe is an acceptable (no pun intended) use of the 'Accept' header, but open for further debate.

That said, we did encounter an issue related to the 'Accept-Encoding' request header. We had hoped to use this header to indicate if (for example) a binary secret should be returned as 'base64' encoded versus raw binary data. We found the ability to override this header from default was problematic on Chrome, so decided to hold off on this feature for now. Curiously one option discussed was to add a '/base64' extension to the URI. Hence this feature could similarly be open for debate.

BTW, we do have a Python client library available for interaction with Barbican as well: https://github.com/cloudkeep/python-barbicanclient

Thanks,
John







________________________________
From: Justin Santa Barbara [justin at fathomdb.com]
Sent: Sunday, September 22, 2013 2:25 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Barbican] MIME types vs path (secrets/{id}/{name})

As part of my project to add a second implementation of the OpenStack API, I'm implementing Barbican, and I'm struggling to understand the motivations behind the API spec.

The API supports storing multiple secrets under a given key, the canonical example for that being SSL keys which comprise a certificate/public key and a private key.  That makes sense.

But, to set or retrieve the "sub-secrets", the MIME type of the request is used.  'application/json' is special and retrieves the metadata.

Wouldn't it be much easier just to use a path ( i.e. .../secrets/{id}/{name} ), rather than using MIME types?  Using MIME types seems very un-RESTy, but I'll leave that argument to the REST police :-)

It seems much more complicated to use MIME types, so I'm betting there's a good reason.  Can someone from the Barbican team share what those are?

(The API ref I'm looking at is here: https://github.com/cloudkeep/barbican/wiki/Blueprint%3A-MIME-Type-Revamp )

Justin

---

Justin Santa Barbara
Founder, FathomDB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130923/d42c6426/attachment.html>