On 04/22/2016 04:29 PM, moparisthebest wrote:
> Now I'm wondering if gskit.c should instead have special code that does:
>
> if(strncmp(pinnedpubkey, "sha256//", 8) == 0) {
> /* hashes are not supported in gskit without curlssl_sha256sum defined */
> return CURLE_SSL_PINNEDPUBKEYNOTMATCH;
> }
>
> Just to keep everything 100% on the same page?

Let me also analyze the global situation:

- In the cURL project, there has always been a confusion between an
SSL/TLS library and a crypto library. Probably because most of these
libs provide both types of APIs (in fact, a 3rd kind of API is
x509/ASN1, but we already have a limited internal support for it and is
out of the subject of this thread).
- The GSKit library supports SSL/TLS, not crypto. On OS400, there is a
crypto library called QC3 that supports all these kind of algorithms,
but is specific to this platform.
- Although I initially wrote the GSKit backend for the OS400, I know
there are some people interested in adapting this module for support on
other platforms (I don't have access to these non-OS400 GSKit
implementations) and as a consequence, this refrain me of making it less
"generic".

I'm really interested in having as much support as possible on the
OS400. If we enter the "piggyback" code above, it'll limit things easily
doable.

The real question is: how to implement crypto algorithms when the
selected SSL/TLS library does not support them. Suggested alternative
solutions follow (in decreasing order of personal preference):

1) Introduce a crypto vs SSL/TLS library dichotomy: of course a library
supporting both may be listed twice.
2) Provide missing crypto algorithms locally, as it is already the case
for md5.
3) Update the GSKit backend to provide these crypto algorithm via QC3
calls: of course this will move GSKit towards a more OS400 specific version.

Your opinion is welcome :-)

Patrick
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-04-22