Open Stack

On 5/3/13 8:10 AM, "Nate Reller" <rellerreller at yahoo.com> wrote:

>How are the tenant IDs populated in the database?

Our current plan is to silently create the tenant_id once the user's first
call has validated against keystone. E.g. If you have our endpoint in
keystone, we'll create the tenant. The tenant_id is going to just be a
varchar with the data from keystone since, IIRC, the OpenStack provider
can use any values for tenant_ids so we can't rely on any particular
format.

>What are the possible content_types for a secret GET request?  I'm a
>little
>confused as to what to expect for that value.  The AES key in the example
>has a
>public key word.  Why public?  Public and private I can kind of
>understand for
>asymmetric keys, but I don't know what would be there for a symmetric
>key.  

Barbican will support arbitrary secret types, not just symmetric and
asymmetric keys. Our current plan is that when a customer makes a request
with application/json as the Accepts header, they will get the metadata
for the secret (not the secret contents). This metadata will contain a
list of the other content types available. For example, something like
this:

"content-types":  {
  "raw": "application/octet-steam",
  "base64": "application/base64"
}

Or maybe just:

"content-types": [ "application/octet-steam", "application/base64" ]



We'll always support some common types (like octet-steam), but the other
options will depend on the secret type. We stole this idea from how Glance
provides image data. We were also thinking of specifying a 'default'
option that would be the format that was requested or uploaded.

The 'public' option you saw was to allow for the retrieval of the public
portion of an asymmetric key. Symmetric keys wouldn't have that option.
This facility allows us to provide an abstraction for key wrapping. We can
store the secret in whatever format makes the most sense for the backend
(HSM, etc), then munge the key to the requested format on request. So for
the symmetric key, you might have something more like the above rather
than the example on github.

Bottom line - consumers would request with application/json first, then
parse the list of available types. They can then make a request for the
one they want, use one of the common types like octet-stream or use
whatever they specified when they uploaded / requested creation of the key.


>Any particular reason you have MIME type for post and content_type for
>get?  

Probably a screw-up. We've been editing this thing a lot lately :). We'll
make a pass and clean it up and make it more consistent. Thanks for
catching that.

>I guess my expectation is that if I create an object with the properties
>name,
>expiration, and MIME type that I would be able to retrieve that same
>object and
>it would have the same properties of name, expiration, and MIME type.

You are correct. If you ask Barbican to create the secret for you or you
pass a mime type that we understand, the API may provide more options to
retrieve the key, but you would always have the option of getting back
exactly what you put in.

>Is application/aes-256-cbc an actual MIME type?  I wonder if MIME type is
>the
>best descriptor for an attribute.  I don't even think that MIME type will
>be
>returned to the user in the HTTP request since it will be
>application/json in
>most circumstances.  Perhaps algorithm or format might be better.  MIME
>types
>seem specific to protocols.

It is not currently an official mime-type. If it makes sense to use this
for Barbican as well, then we'll define the common mime-types and reach
out to IANA to hopefully standardize them. In the meantime (or if they
don't want to do it), then the mime-types would be x-application/pkcs, etc.

We could also move some of the data encoded in the mime-type currently
into metadata and simplify the mime-type down to data encodings only. E.g.
base64, octet-steam, gzip, etc. Would that approach be preferable? I'm on
the fence about it.


>Should the key expiration be a part of the secret object or the policy
>associated with the secret object?  I was thinking this would be in a
>policy
>object, but it's not a big deal to me either way.  Can this be null if no
>expiration?

We've stripped the policy stuff out for now as that was mostly aimed at
supporting the agent use case which we aren't planning on working on for
Havana. Right now we're not planning on having a policy associated with
the key, but that will change at some point.

The expiration would be nullable. It's there to support SSL certificates
and to allow a consumer to specify expirations for keys that don't
natively support it, like AES.



>-Nate


Thanks for the feedback / questions.


Jarret