Open Stack

Thanks John for your response.
I am aware that application/octet-stream works for the retrieval of secret
.
We are utilizing the key generated from Barbican in our AES encryption
algorithm . Hence we  wanted the response in text/plain format from
Barbican since AES encryption algorithm would need the key of ASCII format
which should be either 16,24 or 32 bytes.

The AES encyption algorithms would not accept the binary format and even if
binary  is converted into ascii , encoding is failing for few of the keys
because some characters exceeeds the range of ASCII and for some keys
 after encoding length exceeds 32 bytes  which is the maximum length for
doing AES encryption.

Would like to know the reason behind Barbican not supporting
the retrieval of the secret in text/plain format generated from the order
resource in plain/text format.

Thanks and Regards,
Asha Seshagiri

On Sun, Jun 7, 2015 at 11:43 PM, John Wood <john.wood at rackspace.com> wrote:

>  Hello Asha,
>
>  The AES type key should require an application/octet-stream Accept
> header to retrieve the secret as it is a binary type. Please replace
> ‘text/plain’ with ‘application/octet-stream’ in your curl calls below.
>
>  Thanks,
> John
>
>
>   From: Asha Seshagiri <asha.seshagiri at gmail.com>
> Date: Friday, June 5, 2015 at 2:42 PM
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Cc: Douglas Mendizabal <douglas.mendizabal at RACKSPACE.COM>, John Wood <
> john.wood at rackspace.com>, "Reller, Nathan S." <Nathan.Reller at jhuapl.edu>,
> Adam Harwell <adam.harwell at RACKSPACE.COM>, Paul Kehrer <
> paul.kehrer at RACKSPACE.COM>
> Subject: Re: Barbican : Retrieval of the secret in text/plain format
> generated from Barbican order resource
>
>   Hi All ,
>
>  I am currently working on use cases for database and file Encryption.It
> is really important for us to know since my Encryption use case would be
> using the key generated by Barbican through order resource as the key.
> The encyption algorithms would not accept the binary format and even if
> converted into ascii , encoding is failing for few of the keys because some
> characters exceeeds the range of ASCII and for some key  after encoding
> length exceeds 32 bytes  which is the maximum length for doing AES
> encryption.
> It would be great if  someone could respond to the query ,since it would
> block my further investigations on Encryption usecases using Babrican
>
>  Thanks and Regards,
> Asha Seshagiri
>
>
> On Wed, Jun 3, 2015 at 3:51 PM, Asha Seshagiri <asha.seshagiri at gmail.com>
> wrote:
>
>>   Hi All,
>>
>>  Unable to retrieve the secret in text/plain format  generated from
>> Barbican order resource
>>
>>  Please find the curl command and responses for
>>
>>  *Order creation with payload content type as text/plain* :
>>
>> [root at barbican-automation ~]# curl -X POST -H
>> 'content-type:application/json' -H
>> "X-Auth-Token:9b211b06669249bb89665df068828ee8" \
>> > -d '{"type" : "key", "meta": {"name": "secretname2","algorithm": "aes",
>> "bit_length":256,  "mode": "cbc", "payload_content_type": *"text/plain"*}}'
>> -k https://169.53.235.102:9311/v1/orders
>>
>> *{"order_ref":
>> "https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680
>> <https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680>*
>> "}
>>
>>  *Retrieval of the order by ORDER ID in order to get to know the secret
>> generated by Barbican*
>>
>> [root at barbican-automation ~]# curl -H 'Accept: application/json' -H
>> "X-Auth-Token:9b211b06669249bb89665df068828ee8" \
>> > -k  *https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680
>> <https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680>*
>> {"status": "ACTIVE", "sub_status": "Unknown", "updated":
>> "2015-06-03T19:08:13", "created": "2015-06-03T19:08:12", "order_ref": "
>> https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680",
>> "secret_ref": "*https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e
>> <https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e>*",
>> "creator_id": "cedd848a8a9e410196793c601c03b99a", "meta": {"name":
>> "secretname2", "algorithm": "aes", "payload_content_type": "text/plain",
>> "mode": "cbc", "bit_length": 256, "expiration": null},
>> "sub_status_message": "Unknown", "type": "key"}[root at barbican-automation
>> ~]#
>>
>>
>> *Retrieval of the secret failing with the content type text/plain*
>>
>> [root at barbican-automation ~]# curl -H 'Accept:text/plain' -H
>> "X-Auth-Token:9b211b06669249bb89665df068828ee8" -k *https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e/payload
>> <https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e/payload>*
>> *{"code": 500, "description": "Secret payload retrieval failure seen -
>> please contact site administrator.", "title": "Internal Server Error"}*
>>
>> I would like to know wheather this is a bug from Barbican side  since
>> Barbican allows creation of the order resource with text/plain as the
>> payload_content type but the retrieval of the secret payload with the
>> content type text/plain is not allowed.
>>
>>  Any help would highly be appreciated.
>>  --
>>  *Thanks and Regards,*
>> *Asha Seshagiri*
>>
>
>
>
>  --
>  *Thanks and Regards,*
> *Asha Seshagiri*
>



-- 
*Thanks and Regards,*
*Asha Seshagiri*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150608/d696fb74/attachment.html>