Hello!

On Thu, Nov 24, 2016 at 08:57:35PM +0100, Flemming Frandsen wrote:

> Yes, that's correct, but:
>
> 1: You'd need custom code to url decode the header anyway and ignoring lack
> of newlines is simpler.

URL decoding is available out of the box in most environments.
That is, recovering original PEM is as simple as wrapping a
reference to a header into a function call.

> 2: No existing parser will handle url decoding of the header without
> changes, but some might work without the newlines.

You may want to name a few.

And we already use URL encoding in out mail module, so the are
good reasons to keep things consistent.

> 3: You don't need to recover the original PEM format as newlines are
> optional for any reasonable base64 parser.

They aren't optional at least for OpenSSL itself.

> If anything, it could be argued that the -----BEGIN CERTIFICATE----- and
> -----END CERTIFICATE----- bits should be removed too as that's of no use to
> the base64 decoder and has to be removed to get started parsing the actual
> content anyway.
>
> Without the begin and end bits someone who is really interested in getting
> a complete PEM file out of the header could very easily slap the start and
> end lines around a line-wrapped base64 content.

Such approach was already considered when working on the mail
implementation of client certificates support. Essentially, this
provides Base64-encoded certificate in DER format. This is
certainly better than just removing newlines, yet urlencoding is
considered to be better in most cases.

> If you're really unhappy with my proposed solution, then I can try to fix
> up the url encoding patch that was posted earlier, though I still think
> it's silly to go to such lengths to preserve newlines that nobody wants.

There is no problem with preparing any patch. And there
were already quite a few. The main problem here is naming things:
that is, how things are expected to be named in the future, and how
transition is expected to look like. The situation when
$ssl_client_cert variable is not usable in most if not all cases
looks at least strange.

We probably need to switch it back to original meaning of
PEM-encoded certificate (now available as $ssl_client_raw_cert).
And it would be enough if we have some trivial functions like
urlencode/urldecode available (see ticket #52) - but,
unfortunately, we don't have them now. So at least urlencoded
variant is needed ($ssl_client_escaped_cert?). And the next
question is what to do with current $ssl_client_cert, as we need
to preserve compatibility at least somehow for people who
currently use certificate with tabs added as a multiline header.

Another possible approach might be to change $ssl_client_cert to
use spaces (tabs?) instead of newline + tab. This should be
compatible with what most servers provide as a result of parsing
multi-line header, and implies less changes. This needs an
additional investigation though.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel