<div dir="ltr">Thanks John. <div><br></div><div>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. </div>
<div><br></div><div>Can you send us the link to your review?</div><div><br></div><div>Thanks,</div><div>-Rajesh Mohan</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 6:00 AM, John Dennis <span dir="ltr"><<a href="mailto:jdennis@redhat.com" target="_blank">jdennis@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/26/2014 05:36 PM, Rajesh_Mohan3@Dell.com wrote:<br>
> I am working on SSL VPN BP.<br>
><br>
> CA certificate is one of the resources. We decided to use PEM formatted certificates. It is multi-line string<br>
><br>
>   1 -----BEGIN CERTIFICATE-----<br>
>   2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD<br>
>  <snip><br>
>  21 0vO728pEcn6QtOpU7ZjEv8JLKRHwyq8kwd8gKMflWZRng4R2dj3cdd24oYJxn5HW<br>
>  22 atXnq+N9H9dFgMfw5NNefwJrZ3zAE6mu0bAIoXVsKT2S<br>
>  23 -----END CERTIFICATE-----<br>
><br>
> 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.<br>
><br>
> I am looking for some accepted way to represent PEM formatted file on command line.<br>
><br>
> 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.<br>
<br>
</div>In general PEM formatted certificates and other X509 binary data objects<br>
should be exchanged in the original PEM format for interoperabilty<br>
purposes. For command line tools it's best to pass PEM objects via a<br>
filename.<br>
<br>
However, having said that there is at least one place in Openstack which<br>
passes PEM data via a HTTP header and/or URL, it's the Keystone token id<br>
which is a binary CMS object normally exchanged in PEM format. Keystone<br>
strips the PEM header and footer, strips line endings and modifies one<br>
of the base64 alphabet characters which was incompatible with HTTP and<br>
URL encoding. However what keystone was doing was not correct and in<br>
fact did not follow an existing RFC (e.g. URL safe base64).<br>
<br>
I fixed these problems and in the process wrote two small Python modules<br>
base64utils and pemutils to do PEM transformations correctly (plus<br>
general utilities for working with base64 and PEM data). These were<br>
submitted to both keystone and oslo, Oslo on the assumption they should<br>
be general purpose utilities available to all of openstack. I believe<br>
these have languished in review purgatory, because I was pulled off to<br>
work on other issues I haven't had the time to babysit the review.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
John<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>