[openstack-dev] [Neutron] Representing PEM Format file as string
nachi at ntti3.com
Mon Jan 27 18:49:04 UTC 2014
May I ask why we need single line representation of PEM format?
For CLI, we will use file_name as same as nova keypair-add.
We won't specify PEM on the URL.
2014-01-27 Rajesh Mohan <rajesh.mlists at gmail.com>:
> Thanks John.
> My initial approach is similar to Keystone's. This is mainly to unblock me
> from making progress on the driver. Nachi is doing the API part. I will
> discuss with him to explore other options.
> Can you send us the link to your review?
> -Rajesh Mohan
> On Mon, Jan 27, 2014 at 6:00 AM, John Dennis <jdennis at redhat.com> wrote:
>> On 01/26/2014 05:36 PM, Rajesh_Mohan3 at Dell.com wrote:
>> > I am working on SSL VPN BP.
>> > CA certificate is one of the resources. We decided to use PEM formatted
>> > certificates. It is multi-line string
>> > 1 -----BEGIN CERTIFICATE-----
>> > 2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD
>> > <snip>
>> > 21 0vO728pEcn6QtOpU7ZjEv8JLKRHwyq8kwd8gKMflWZRng4R2dj3cdd24oYJxn5HW
>> > 22 atXnq+N9H9dFgMfw5NNefwJrZ3zAE6mu0bAIoXVsKT2S
>> > 23 -----END CERTIFICATE-----
>> > Is there a standard way to represent this as single line string? Maybe
>> > there is some other project that passes certificates on command line/url.
>> > I am looking for some accepted way to represent PEM formatted file on
>> > command line.
>> > I am thinking of concatenating all lines into single string and
>> > rebuilding the file when configuration file is generated.Will we hit any CLI
>> > size limitations if we pass long strings.
>> In general PEM formatted certificates and other X509 binary data objects
>> should be exchanged in the original PEM format for interoperabilty
>> purposes. For command line tools it's best to pass PEM objects via a
>> However, having said that there is at least one place in Openstack which
>> passes PEM data via a HTTP header and/or URL, it's the Keystone token id
>> which is a binary CMS object normally exchanged in PEM format. Keystone
>> strips the PEM header and footer, strips line endings and modifies one
>> of the base64 alphabet characters which was incompatible with HTTP and
>> URL encoding. However what keystone was doing was not correct and in
>> fact did not follow an existing RFC (e.g. URL safe base64).
>> I fixed these problems and in the process wrote two small Python modules
>> base64utils and pemutils to do PEM transformations correctly (plus
>> general utilities for working with base64 and PEM data). These were
>> submitted to both keystone and oslo, Oslo on the assumption they should
>> be general purpose utilities available to all of openstack. I believe
>> these have languished in review purgatory, because I was pulled off to
>> work on other issues I haven't had the time to babysit the review.
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev