Re: Mozilla CA Certificates, UTF-8
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
Re: Mozilla CA Certificates, UTF-8
On Wed, 16 May 2018, Zach van Rijn wrote: two entries (lines 1171 and 2638 respectively) have comments that are in UTF-8, which I noticed today, pasted below for reference: ... Should these be converted [via 'mk-ca-bundle'], ignored [leave the file as-is] or some other option? 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. My second question is, would there be any interest in having an "in-memory" certificate option? I see an example [3] for OpenSSL, but am considering adding something like 'ssl_camem' in addition to 'ssl_cafile' and 'ssl_capath' [4], and the respective easy-opt flag, perhaps 'CURLOPT_CAMEM' to specify a char * pointing to in- memory contents of that CA file. 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_certs_ca_certs -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Mozilla CA Certificates, UTF-8
Hi,
I have a question concerning the Mozilla CA Certificates bundle
encoding and a proposal for supporting in-memory certificates.
On this page:
https://curl.haxx.se/docs/caextract.html
it is possible to download one of several PEM files containing
the Mozilla CA Certificates bundle. In the current bundle,
https://curl.haxx.se/ca/cacert-2018-03-07.pem
two entries (lines 1171 and 2638 respectively) have comments that
are in UTF-8, which I noticed today, pasted below for reference:
1171: NetLock Arany (Class Gold) Főtanúsítvány
2638: TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5
These are ignored [2], of course, but may cause problems in
programs that wish to parse or store this PEM file in other
formats. It is unclear / unspecified in [1] as to whether UTF-8
is acceptable.
Should these be converted [via 'mk-ca-bundle'], ignored [leave
the file as-is] or some other option?
My second question is, would there be any interest in having an
"in-memory" certificate option? I see an example [3] for OpenSSL,
but am considering adding something like 'ssl_camem' in addition
to 'ssl_cafile' and 'ssl_capath' [4], and the respective easy-opt
flag, perhaps 'CURLOPT_CAMEM' to specify a char * pointing to in-
memory contents of that CA file.
The file could either be read into memory or compiled, e.g., the
output of 'xxd -i'. If this may be of interest, let's discuss.
ZV
[1]: https://tools.ietf.org/html/rfc1421
[2]: https://tools.ietf.org/html/rfc7468
[3]: https://raw.githubusercontent.com/curl/curl/master/docs/exam
ples/cacertinmem.c
[4]: curl/lib/vtls/{mbedtls,openssl,polarssl,...}.c
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
