curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Has the time come to drop NSS?

From: David Woodhouse via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 01 Feb 2022 13:44:33 +0000

On Tue, 2022-02-01 at 14:35 +0100, Claes Jakobsson via curl-library wrote:
> At least ten years ago the PKCS#11 support in NSS was, at least from
> our extensive use and testing, far superior to the one provided by
> OpenSSL at the time especially when talking to cryptographic
> smartcards. If this is not longer the case then dropping NSS would be
> fine.

These days we're probably better off with OpenSSL than NSS for PKCS#11.
GnuTLS is better by far than both.

For OpenSSL we still need the PKCS#11 engine but things are still set
up such that it can *relatively* easily just be invoked with a RFC7512
PKCS#11 URI and Just Work™ with a PKCS#11 module that is correctly
registered with the system via p11-kit. It sucks that applications have
to manually invoke the ENGINE but curl has the code to do that (see
commit 298d2565e2a2f).

As OpenSSL 3.0.0 deprecated ENGINEs and has moved to providers, I'm not
sure what the best option is. Maybe it's to link curl directly against
libp11 instead of relying on the ENGINE? That's what I do in
OpenConnect because I can give the user better behaviour w.r.t
automatically finding keys and matching certs.

NSS needs a bit more work to achieve anything like that at all.

GnuTLS will just take your RFC7512 PKCS#11 in many APIs in place of a
filename for a cert/key, and silently Do The Right Thing with it,
without making the application jump through hoops.


-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
  • application/pkcs7-signature attachment: smime.p7s
Received on 2022-02-01