On Thu, 2018-05-17 at 00:51 +0200, Daniel Stenberg wrote:
> On Wed, 16 May 2018, Zach van Rijn wrote:
>
> > ...
>
> I think that as long as nobody reports a problem with them
> being left as-is we can just let them be. Unless someone feels
> an urge to dig in and figure out what the "right" way forward
> is here.
>

I asked in #cryptography on Freenode, and was told:

  * RFC 7468 says "Parsers MUST handle non-conforming data
    gracefully."

  * It explicitly says that "Data before the encapsulation
    boundaries are permitted, and parsers MUST NOT malfunction
    when processing such data", but nothing about data after the
    END line

  * There's also section 5.2, which notes that "Many tools are
    known to emit explanatory text before the BEGIN and after the
    END lines for PKIX certificates, more than any other type."

(Side note: if anyone wishes to remove all of the labels and
'===' lines from the PEM file I referenced earlier, one
possibility is: "perl -p0e 's/.*\n=.*\n//g' -i cacert.pem").

So conclusively, the file on the website should be left intact.

> > ...
> I think there is an interest. This subject has been up
> before[1] and is also mentioned in the TODO [2].
>
> I don't know how complicated this feature is to implement for
> other TLS backends than openssl (and its siblings
> boringssl/libressl).
>
> [1] = https://github.com/curl/curl/issues/2310
> [2] = https://curl.haxx.se/docs/todo.html#Support_in_memory_cer
> ts_ca_certs
>

From what I gather, mbedTLS should be straightforward but I've
not looked at the others as I'm only using mbedTLS currently.

Anyone else want to help with this? I think it would be nice to
see this come to fruition.

ZV

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-05-17