opensc-devel — discussion of developement of OpenSC and related projects

Re: [Opensc-devel] honoring PINPAD

[<J.W...@mi...>]

Please find some comment/explenation below…

From: Ludovic Rousseau [mailto:lud...@gm...]
Sent: donderdag 10 maart 2016 22:15
To: ope...@li...
Subject: Re: [Opensc-devel] honoring PINPAD



2016-03-10 17:53 GMT+01:00 Douglas E Engert <dee...@gm...<mailto:dee...@gm...>>:


On 3/10/2016 9:23 AM, J.W...@mi...<mailto:J.W...@mi...> wrote:
> Hi all,
>
> Can anybody shine some light over this?
>
> We finally have found some pinpad-readers that do work under Linux, with our cards and the AET-drivers.
>
> For instance, if I type opensc-tool –l, I can see with readers have a pinpad or not
>
> Also, when I do pkcs11-tool –O –l, I _/must/_ enter the pin on the reader.
>
> Furthermore the screen-lock (driven by pam) knows when to ask for a pin, or refer to the reader-console.
>
> However, openvpn simply continueus to ask for the pin on the console (or its management interface).
>
> I presume openvpn should have checked the reader’s capabilities, but forgot to do that…

There is more work to do to use the pinpad reader. The code has to setup the template so the reader knows how to fill in the PIN.

>
> Secondly, as the code works with the pin on the prompt, I presume there is a switch (routine in libccid ??) that specifies IF a pinpad should be used or not?

I don't think so, it really enforced by the the calling software, OpenSC, openvpn or whatever....

 From a security standpoint, the card can not tell if the pin came from the pin pad reader or from the host.

There maybe readers that will not accept a pin command from the host. (I don't know of any.)

Exact. At least Gemalto provides such pinpad readers.
The feature is called "firewall" and the reader will refuse any VERIFY (and similar) command with the PIN sent from the host. With this reader you can only verify a PIN using the pinpad keyboard.

You can have a look at some extra features available at https://pcsclite.alioth.debian.org/ccid/readers/extra_features/
For example https://pcsclite.alioth.debian.org/ccid/readers/extra_features/Gemalto_Ezio_Shield_PinPad_features.txt has:

Firewall: True
The same reader model can have the firewall feature enabled or not. I guess you will have to specify what configuration you want when buying the readers.

So if you are trying to force the user to never expose their pin to host (either on the keyboard or from a file) and always use the pin pad reader, you would need
one of these readers. You would also have to force the user not to change readers!

There may be issues trying to enforce this with Remote Desktop over the network.

The application can check the reader VendorID/ProductID to verify it is still the same reader. But you can't fight against the user if he is root on the system and can change any software and use another reader instead.
But I am not sure why the user would want to steal his own secret PIN.


> So you can optionally overrule the pinpad-capability???

There is no switch in libccid for force the use of the pinpad. It is only an application decision.
But the reader has such a switch.
Bye

--
 Dr. Ludovic Rousseau


Thanks Dr. Rousseau,
I’ve seen and used the info on your page before.

The complicating factor with respect to PINPAD readers however is our AET software (card-applet and driver on the pc), they are a further limiting factor.
I have several PP-readers that should work ok, and indeed, with the cards I bought and initialized myself (like myEID) they work correctly.
But our ministry supplied smartcard, just fails with most readers….

Since I’ve found two working PINPAD-readers, I was overjoyed!
So we do have readers that work, with some applications.
Point now is, that openvpn simply ignore the PP-functionality of the reader by default.

I fully agree that the card itself should not be aware or care, what kind of reader it is inserted into.
And I understand that it is up to the application itself, to detect the reader-capabilities, and act accordingly.
So the application can decide the ignore the extra capabilities, and treat it like a dumb class-1 reader,
Or the application has to fill-in templates for allowing the PINPAD-capabilities.
That sounds like an configuration-option for the appropriate application….

Thank you for education me (and perhaps others)
Kind regards, Hans.

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Opensc-devel] Make OpenSC work for Oberthur ID-One Cosmo V7.0

[Mon-Loi P. <mo...@sg...>]

Hi folks,

 

I'm new to smart cards and have been reading the archives for the solution
to my problem

 

Basically I have the same problem as this guy from this thread
(https://sourceforge.net/p/opensc/mailman/message/34165067/). I'm using
Oberthur ID-One Cosmo V7.0 loaded with OT - PKI Applet called AuthentIC V3.
I know the AID of the card but don't know how to proceed. In short has
anyone tried this card with opensc? If none anyway to make this work?

 

In addition the guy in the thread added an "atr" in opensc.conf does that
help?

 

Regards,
Mon

 

NOTICE: This e-mail (including any attachments) may contain confidential or
legally privileged information. Any unauthorised use, retention,
reproduction or disclosure is prohibited and may attract civil and criminal
penalties. If this e-mail has been sent to you in error, please delete it
and notify us immediately.

 

Re: [Opensc-devel] honoring PINPAD

[Frank M. <mo...@in...>]

Use `enable_pinpad = false;` to disable the PIN-pad
https://github.com/OpenSC/OpenSC/blob/master/etc/opensc.conf.in#L96.
But have in mind the limitations already spoken about.

You should delegate the PIN-Pad problem to OpenVPN!



Am Donnerstag, dem 10. März, um 22:15 Uhr schrieb Ludovic Rousseau:
> 2016-03-10 17:53 GMT+01:00 Douglas E Engert <dee...@gm...>:
> 
> >
> >
> > On 3/10/2016 9:23 AM, J.W...@mi... wrote:
> > > Hi all,
> > >
> > > Can anybody shine some light over this?
> > >
> > > We finally have found some pinpad-readers that do work under Linux, with
> > our cards and the AET-drivers.
> > >
> > > For instance, if I type opensc-tool –l, I can see with readers have a
> > pinpad or not
> > >
> > > Also, when I do pkcs11-tool –O –l, I _/must/_ enter the pin on the
> > reader.
> > >
> > > Furthermore the screen-lock (driven by pam) knows when to ask for a pin,
> > or refer to the reader-console.
> > >
> > > However, openvpn simply continueus to ask for the pin on the console (or
> > its management interface).
> > >
> > > I presume openvpn should have checked the reader’s capabilities, but
> > forgot to do that…
> >
> > There is more work to do to use the pinpad reader. The code has to setup
> > the template so the reader knows how to fill in the PIN.
> >
> > >
> > > Secondly, as the code works with the pin on the prompt, I presume there
> > is a switch (routine in libccid ??) that specifies IF a pinpad should be
> > used or not?
> >
> > I don't think so, it really enforced by the the calling software, OpenSC,
> > openvpn or whatever....
> >
> >  From a security standpoint, the card can not tell if the pin came from
> > the pin pad reader or from the host.
> >
> > There maybe readers that will not accept a pin command from the host. (I
> > don't know of any.)
> >
> 
> Exact. At least Gemalto provides such pinpad readers.
> The feature is called "firewall" and the reader will refuse any VERIFY (and
> similar) command with the PIN sent from the host. With this reader you can
> only verify a PIN using the pinpad keyboard.
> 
> You can have a look at some extra features available at
> https://pcsclite.alioth.debian.org/ccid/readers/extra_features/
> For example
> https://pcsclite.alioth.debian.org/ccid/readers/extra_features/Gemalto_Ezio_Shield_PinPad_features.txt
> has:
> 
> Firewall: True
> 
> The same reader model can have the firewall feature enabled or not. I guess
> you will have to specify what configuration you want when buying the
> readers.
> 
> So if you are trying to force the user to never expose their pin to host
> > (either on the keyboard or from a file) and always use the pin pad reader,
> > you would need
> > one of these readers. You would also have to force the user not to change
> > readers!
> >
> > There may be issues trying to enforce this with Remote Desktop over the
> > network.
> >
> 
> The application can check the reader VendorID/ProductID to verify it is
> still the same reader. But you can't fight against the user if he is root
> on the system and can change any software and use another reader instead.
> But I am not sure why the user would want to steal his own secret PIN.
> 
> 
> > So you can optionally overrule the pinpad-capability???
> >
> 
> There is no switch in libccid for force the use of the pinpad. It is only
> an application decision.
> But the reader has such a switch.
> 
> Bye
> 
> -- 
>  Dr. Ludovic Rousseau

> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel


-- 
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

Re: [Opensc-devel] honoring PINPAD

[Ludovic R. <lud...@gm...>]

2016-03-10 17:53 GMT+01:00 Douglas E Engert <dee...@gm...>:

>
>
> On 3/10/2016 9:23 AM, J.W...@mi... wrote:
> > Hi all,
> >
> > Can anybody shine some light over this?
> >
> > We finally have found some pinpad-readers that do work under Linux, with
> our cards and the AET-drivers.
> >
> > For instance, if I type opensc-tool –l, I can see with readers have a
> pinpad or not
> >
> > Also, when I do pkcs11-tool –O –l, I _/must/_ enter the pin on the
> reader.
> >
> > Furthermore the screen-lock (driven by pam) knows when to ask for a pin,
> or refer to the reader-console.
> >
> > However, openvpn simply continueus to ask for the pin on the console (or
> its management interface).
> >
> > I presume openvpn should have checked the reader’s capabilities, but
> forgot to do that…
>
> There is more work to do to use the pinpad reader. The code has to setup
> the template so the reader knows how to fill in the PIN.
>
> >
> > Secondly, as the code works with the pin on the prompt, I presume there
> is a switch (routine in libccid ??) that specifies IF a pinpad should be
> used or not?
>
> I don't think so, it really enforced by the the calling software, OpenSC,
> openvpn or whatever....
>
>  From a security standpoint, the card can not tell if the pin came from
> the pin pad reader or from the host.
>
> There maybe readers that will not accept a pin command from the host. (I
> don't know of any.)
>

Exact. At least Gemalto provides such pinpad readers.
The feature is called "firewall" and the reader will refuse any VERIFY (and
similar) command with the PIN sent from the host. With this reader you can
only verify a PIN using the pinpad keyboard.

You can have a look at some extra features available at
https://pcsclite.alioth.debian.org/ccid/readers/extra_features/
For example
https://pcsclite.alioth.debian.org/ccid/readers/extra_features/Gemalto_Ezio_Shield_PinPad_features.txt
has:

Firewall: True

The same reader model can have the firewall feature enabled or not. I guess
you will have to specify what configuration you want when buying the
readers.

So if you are trying to force the user to never expose their pin to host
> (either on the keyboard or from a file) and always use the pin pad reader,
> you would need
> one of these readers. You would also have to force the user not to change
> readers!
>
> There may be issues trying to enforce this with Remote Desktop over the
> network.
>

The application can check the reader VendorID/ProductID to verify it is
still the same reader. But you can't fight against the user if he is root
on the system and can change any software and use another reader instead.
But I am not sure why the user would want to steal his own secret PIN.


> So you can optionally overrule the pinpad-capability???
>

There is no switch in libccid for force the use of the pinpad. It is only
an application decision.
But the reader has such a switch.

Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] honoring PINPAD

[Douglas E E. <dee...@gm...>]

On 3/10/2016 9:23 AM, J.W...@mi... wrote:
> Hi all,
>
> Can anybody shine some light over this?
>
> We finally have found some pinpad-readers that do work under Linux, with our cards and the AET-drivers.
>
> For instance, if I type opensc-tool –l, I can see with readers have a pinpad or not
>
> Also, when I do pkcs11-tool –O –l, I _/must/_ enter the pin on the reader.
>
> Furthermore the screen-lock (driven by pam) knows when to ask for a pin, or refer to the reader-console.
>
> However, openvpn simply continueus to ask for the pin on the console (or its management interface).
>
> I presume openvpn should have checked the reader’s capabilities, but forgot to do that…

There is more work to do to use the pinpad reader. The code has to setup the template so the reader knows how to fill in the PIN.

>
> Secondly, as the code works with the pin on the prompt, I presume there is a switch (routine in libccid ??) that specifies IF a pinpad should be used or not?

I don't think so, it really enforced by the the calling software, OpenSC, openvpn or whatever....

 From a security standpoint, the card can not tell if the pin came from the pin pad reader or from the host.

There maybe readers that will not accept a pin command from the host. (I don't know of any.)
So if you are trying to force the user to never expose their pin to host (either on the keyboard or from a file) and always use the pin pad reader, you would need
one of these readers. You would also have to force the user not to change readers!

There may be issues trying to enforce this with Remote Desktop over the network.



>
> So you can optionally overrule the pinpad-capability???
>
> Kind regards, Hans.
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en
> het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the
> message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@gm...>

[Opensc-devel] honoring PINPAD

[<J.W...@mi...>]

Hi all,

Can anybody shine some light over this?

We finally have found some pinpad-readers that do work under Linux, with our cards and the AET-drivers.
For instance, if I type opensc-tool -l, I can see with readers have a pinpad or not
Also, when I do pkcs11-tool -O -l, I _must_ enter the pin on the reader.
Furthermore the screen-lock (driven by pam) knows when to ask for a pin, or refer to the reader-console.
However, openvpn simply continueus to ask for the pin on the console (or its management interface).

I presume openvpn should have checked the reader's capabilities, but forgot to do that...

Secondly, as the code works with the pin on the prompt, I presume there is a switch (routine in libccid ??) that specifies IF a pinpad should be used or not?
So you can optionally overrule the pinpad-capability???


Kind regards, Hans.

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Opensc-devel] Fix (default) compiler warnings and be more strict

[Ludovic R. <lud...@gm...>]

2016-02-28 18:34 GMT+01:00 Ludovic Rousseau <lud...@gm...>:

> Hello,
>
> I worked on the idea that important warnings should NOT be ignored.
> To do that I add the compilation flag -Werror so that a compilation
> warning is considered as an error and the automatic compilation from
> travis-CI will report the build in error.
>
> The current master branch already reports problems, without changing the
> compiler warnings level.
> See [1] for the GNU/Linux gcc 4.6.3 compilation and [2] for the GNU/Linux
> clang 3.4 compilation.
> And [3] for the Mac OS X gcc LLVM 6.0 and [4] for the Mac OS X clang LLVM
> 6.0.
>
> If I enable -Werror (as done in my travis PR [5]) the 4 compilations fails.
> I have not modified the compilation on MinGW.
>
> My plan is to:
> 1. fix the few warnings reported
> 2. merge the -Werror change so that all future PR will be tested
> 3. increase the warning level and fix corresponding bugs (if time permit)
>

Point 1 and 2 are done and committed.

Point 3 is still work in progress.
I created a .travis-configure script that sets some compiler flags but I
have not had the time to work on the new warnings.

My problem is that on Mac OS X the linker complains with:
clang: warning: argument unused during compilation: '-pthread'
The message is misleading and is really generated by the linker, not by the
compiler.

And since we now have -Werror the warning is considered an error and the
build fails.
I will have to work on this on GNU/Linux, but I don't know when I will be
able to do that.

Comments?
> Volunteers to help on this task?
>
> Regards,
>
> [1] https://travis-ci.org/OpenSC/OpenSC/jobs/112371473
> [2] https://travis-ci.org/OpenSC/OpenSC/jobs/112371472
> [3] https://travis-ci.org/OpenSC/OpenSC/jobs/112418930
> [4] https://travis-ci.org/OpenSC/OpenSC/jobs/112418929
> [5] https://github.com/OpenSC/OpenSC/pull/692
>
> --
>  Dr. Ludovic Rousseau
>



-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] Fix (default) compiler warnings and be more strict

[Douglas E E. <dee...@gm...>]

Sounds good.

On 2/28/2016 11:34 AM, Ludovic Rousseau wrote:
> Hello,
>
> I worked on the idea that important warnings should NOT be ignored.
> To do that I add the compilation flag -Werror so that a compilation warning is considered as an error and the automatic compilation from travis-CI will report the build in error.
>
> The current master branch already reports problems, without changing the compiler warnings level.
> See [1] for the GNU/Linux gcc 4.6.3 compilation and [2] for the GNU/Linux clang 3.4 compilation.
> And [3] for the Mac OS X gcc LLVM 6.0 and [4] for the Mac OS X clang LLVM 6.0.
>
> If I enable -Werror (as done in my travis PR [5]) the 4 compilations fails.
> I have not modified the compilation on MinGW.
>
> My plan is to:
> 1. fix the few warnings reported
> 2. merge the -Werror change so that all future PR will be tested
> 3. increase the warning level and fix corresponding bugs (if time permit)
>
> Comments?
> Volunteers to help on this task?
>
> Regards,
>
> [1] https://travis-ci.org/OpenSC/OpenSC/jobs/112371473
> [2] https://travis-ci.org/OpenSC/OpenSC/jobs/112371472
> [3] https://travis-ci.org/OpenSC/OpenSC/jobs/112418930
> [4] https://travis-ci.org/OpenSC/OpenSC/jobs/112418929
> [5] https://github.com/OpenSC/OpenSC/pull/692
>
> --
>   Dr. Ludovic Rousseau
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[David W. <dw...@in...>]

On Tue, 2016-03-01 at 21:39 +0100, Andreas Jellinghaus wrote:
> 
> thus the code can be tracked back to opensc that way. Also the code
> at that age is already BSD-2 or OpenSSL licensed.

The latter is the point I'd missed; thanks. I was worried about the
provenance of the code when it *arrived* in OpenSC. But if it was
already suitably licensed at that point, we don't need to care.

The same appears to be true for the libp11 repository — you changed the
licence when you moved the files to the new repository, so all we need
to track is changes which were contributed *since* then, which is
great.

Thanks again.

-- 
dwmw2

Re: [Opensc-devel] Capturing APDU trace on Windows => my solution

[Vlastimil P. <vla...@ce...>]

Hello,

>The adaptation needed for a winscard.dll stub for all version of Windows is
>a continous job.
>Like for the function SCardReadCache used by the PIV/GIDS minidriver,
>that's why I explored an other lead  ...
>
>I do not know if there is a problem in winscard stub, but the Base smart
>card KSP on Windows 10 seems to prohibit the use of winscard stub.

Another interesting approach is to inject a dll which hooks winscard API into a running process. I had some working PoC code (which I -unfortunately- can not share).

Some links:
https://en.wikipedia.org/wiki/DLL_injection
http://codefromthe70s.org/mhook24.aspx
http://research.microsoft.com/en-us/projects/detours/

Best regards
VLP

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[Andreas J. <an...@io...>]

found it, commit b2455b097f8bd9b0a075df3820ce21c6bf33357a in engine_pkcs11
has the same content as opensc in
commit bae2b51e01e16c126613289dd68e75545d3dd333 at least for these files:

aj@seiryu:~/opensc-git/src/sslengines$ md5sum ~/xx/xx/engine_pkcs11/src/*
f16abeabca8f30197b94f5cbbed56132
 /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.c
e693a2a09ee07964722d71f1afbf1882
 /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.def
9936c4fc0357e7c24ddc12abe66fcd06
 /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.h
e4d4f039411f964636b11973d5617ffc
 /home/aj/xx/xx/engine_pkcs11/src/hw_opensc.c
8f7565d60db0ad6246c50b3282676bbf
 /home/aj/xx/xx/engine_pkcs11/src/hw_pkcs11.c
f4911e7a7cd3b44a4251ca8529f685bc
 /home/aj/xx/xx/engine_pkcs11/src/Makefile.am
003221d31d444bb8cd3ca09b7a305158
 /home/aj/xx/xx/engine_pkcs11/src/Makefile.mak
aj@seiryu:~/opensc-git/src/sslengines$ md5sum *
1a29991197312afe0b8d055e5912ce2f  engine_opensc.c
e4219829d19f13cc6c59f7a49d1d830c  engine_opensc.h
f16abeabca8f30197b94f5cbbed56132  engine_pkcs11.c
e693a2a09ee07964722d71f1afbf1882  engine_pkcs11.def
9936c4fc0357e7c24ddc12abe66fcd06  engine_pkcs11.h
e4d4f039411f964636b11973d5617ffc  hw_opensc.c
8f7565d60db0ad6246c50b3282676bbf  hw_pkcs11.c
cae21328df67ce552a790779bf3e4015  Makefile.am
003221d31d444bb8cd3ca09b7a305158  Makefile.mak
0afa2a574a5f83c7fa52cfe35fbd9098  test_engine.sh

thus the code can be tracked back to opensc that way. Also the code at that
age is already BSD-2 or OpenSSL licensed.

engine_pkcs11.def is trivial and I guess you have no need to reuse old
Makefiles. Thus you should be all good?

Regards, Andreas

2016-03-01 17:43 GMT+01:00 David Woodhouse <dw...@in...>:

> On Tue, 2016-03-01 at 16:12 +0100, Andreas Jellinghaus wrote:
>
> > Yes, all code from me for libp11 may be re-used under the BSD-3 clause.
> > Same applies to engine_pkcs11 or pam_p11 (the two users of libp11
> > that I'm aware off), in case that is helpful.
>
> Thank you.
>
> > Please note that I created libp11 mostly by splitting
> > engine_pkcs11/opensc code into a new project, so that I can use it
> > for a pam module I was adding. At least that is how I remember it.
> > Thus most code under my name might come from Olaf Kirch instead, but
> > he has given the same approval already for all I know.
>
> Actually, the interesting part starts before that. You moved the code
> out from OpenSC to separate engine_pkcs11 and libp11 repositories in
> August/September 2005.
>
> But they all appeared, in a big lump, in OpenSC in May 2003:
> https://github.com/OpenSC/OpenSC/commit/496232d9b
>
> Where did they come from before that?
>
> There are commits earlier in the OpenSC history which strongly imply
> that the engine code was already there — Olaf's commit f169b5c891
> tweaks some autoconf code and is titled "only build sslengine if
> OpenSSL supports it". But according to the git history there *is* no
> code at that point; only the autoconf test...
>
> --
> dwmw2
>
>

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[Andreas J. <an...@io...>]

2016-03-01 17:43 GMT+01:00 David Woodhouse <dw...@in...>
>
> Actually, the interesting part starts before that. You moved the code
> out from OpenSC to separate engine_pkcs11 and libp11 repositories in
> August/September 2005.
>
> But they all appeared, in a big lump, in OpenSC in May 2003:
> https://github.com/OpenSC/OpenSC/commit/496232d9b
>
> Where did they come from before that?
>

http://archive.debian.org/debian/pool/main/o/opensc/opensc_0.9.6.orig.tar.gz
src/sslengines has the source code from Olaf and Kevin Stefanik.

Many files are already using the BSD-2 or OpenSSL license.

Also maybe someone has a backup of the old SVN server? my backup disk died
some year ago,
after the project was moved already to github and the server was retired :(

Regards, Andreas

There are commits earlier in the OpenSC history which strongly imply
> that the engine code was already there — Olaf's commit f169b5c891
> tweaks some autoconf code and is titled "only build sslengine if
> OpenSSL supports it". But according to the git history there *is* no
> code at that point; only the autoconf test...
>
> --
> dwmw2
>
>

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[David W. <dw...@in...>]

On Tue, 2016-03-01 at 16:12 +0100, Andreas Jellinghaus wrote:

> Yes, all code from me for libp11 may be re-used under the BSD-3 clause.
> Same applies to engine_pkcs11 or pam_p11 (the two users of libp11
> that I'm aware off), in case that is helpful.

Thank you.

> Please note that I created libp11 mostly by splitting
> engine_pkcs11/opensc code into a new project, so that I can use it
> for a pam module I was adding. At least that is how I remember it.
> Thus most code under my name might come from Olaf Kirch instead, but
> he has given the same approval already for all I know.

Actually, the interesting part starts before that. You moved the code
out from OpenSC to separate engine_pkcs11 and libp11 repositories in
August/September 2005.

But they all appeared, in a big lump, in OpenSC in May 2003:
https://github.com/OpenSC/OpenSC/commit/496232d9b

Where did they come from before that? 

There are commits earlier in the OpenSC history which strongly imply
that the engine code was already there — Olaf's commit f169b5c891
tweaks some autoconf code and is titled "only build sslengine if
OpenSSL supports it". But according to the git history there *is* no
code at that point; only the autoconf test...

-- 
dwmw2

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[Andreas J. <an...@io...>]

Sorry for the late response. Responding once more to give a public
statement. Comments inline below, I suppose your email reader can trim the
quoted section, thus not spending time on that myself.

2016-02-26 15:19 GMT+01:00 David Woodhouse <dw...@in...>:

> It would be really useful if OpenSSL *included* support for PKCS#11 as
> a first class citizen.
>
> This would mean that it could be natively incorporated into higher
> level APIs such as SSL_CTX_use_certificate() and friends. Basically any
> API that can take a filename to reference a certificate, should also be
> able take a RFC7512 PKCS#11 URI.
>
> This would also allow us to use a coherent trust database from PKCS#11,
> which solves the problem of which *purposes* we trust each CA for,
> unlike the existing flat-file solutions.
>
> And applications would no longer need to jump through additional hoops
> and have additional dependencies to get PKCS#11 support; we could make
> it largely Just Work™, like it does for example with GnuTLS.
>
>
>
> The code in libp11 is basically written to be OpenSSL code. If you
> dropped it into the crypto/pkcs11 directory of OpenSSL precisely as it
> stands, it wouldn't look out of place.
>
> I propose — as the starting point of a plan which will surely be
> modified by the time we conclude this thread — that we do so.
>
> The biggest barrier to this, of course, is the licence. For reasons
> which are lost in the mists of time, libp11 is licensed under the
> LGPLv2, and is not compatible with the OpenSSL licence.
>
> Therefore, I propose that we relicense the libp11 project under a
> standard 3-clause BSD licence.
>
> I did a bit of a sanity check offline, and I contacted Olaf Kirch as
> well as the top contributors responsible¹ for 8611 of the 8984 lines of
> .[ch] files in the repository. All of whom so far have agreed to allow
> their contributions to be re-used under a BSD licence.
>
> That gives me reasonable confidence that we can all agree, and that if
> there *are* some people we can't find, or who don't agree, we can
> reimplement the corresponding lines of code without too much of a
> problem.
>
> If you have ever contributed to libp11 (or the engine, although I
> wasn't going there yet), I would be very grateful for an explicit
> response to the question: "May I re-use your code under the 3-clause
> BSD licence as seen at https://opensource.org/licenses/BSD-3-Clause?"
>

Yes, all code from me for libp11 may be re-used under the BSD-3 clause.
Same applies to engine_pkcs11 or pam_p11 (the two users of libp11 that I'm
aware off), in case that is helpful.

Please note that I created libp11 mostly by splitting engine_pkcs11/opensc
code into
a new project, so that I can use it for a pam module I was adding. At least
that is how I remember it.
Thus most code under my name might come from Olaf Kirch instead, but he has
given the same approval
already for all I know.

(There is a separate question, if we get that far, which is "shall we
> *change* the licence of the libp11 project to 3-clause BSD?".
> Personally I'd say yes to that too.)
>

If anyone wants to maintain libp11 and wants to change the license: all ok
from my side.


> So next we come to the technical approach, and I'd really appreciate
> feedback here.
>
> Do we *want* to drop the libp11 API directly into OpenSSL? That might
> be ideal from the point of view of existing applications as they
> migrate from OpenSSL <=1.1 + libp11, to OpenSSL 1.2.
>
> Or perhaps we want to take this opportunity to change the API? Perhaps
> libp11 would continue to exist alongside OpenSSL 1.2 for compatibility
> with those existing apps?
>
> (That question is specifically aimed as the OpenSSL folks on Cc as well
> as the libp11 list.)
>

I don't know current users or use cases who/how libp11 is being used.
For me it is important there is a nice story at the end: this is how you
can use
smart cards. The work I did a few years ago included opensc, openct,
pam_p11,
engine_pkcs11, libp11 and openssl. If there is an updated story with other
components,
fine with me as well. The result counts for me, the details on how to get
there: not that much.

In theory it would be fine if people still could use a smart card or usb
crypto token for
both SSL connections, ssh connections and console login. In practice maybe
noone is
interested in maintaining that, and then it is ok if some progress on one
side kills
unmaintained code elsewhere. If there is sufficient interest, the code is
easy enough to understand and adapt I think.

For a start, I definitely think we should at least add functions for
> obtaining an EVP_PKEY or an X509 cert from a PKCS#11 URI alone —
> similar to the pkcs11_load_key() and pkcs11_load_cert() functions in
> the engine code.
>
> I'm also tempted to suggest that we should make it capable of using
> p11-kit for the basic module loading and initialisation. Since p11-kit
> is "sufficiently ubiquitous" on the platforms where this is relevant,
> my approach would probably be to *start* by depending on p11-kit, and
> if anyone objects they can do so in 'diff -up' form. Starting with a
> full implementation of RFC7512 URI parsing...
>

I haven't kept up with that RFC or p11-kit, thus can't comment on what is
the best way
here. As this is open source: do what you think is right :)

Thanks for taking on this project! I'm glad to see someone improves the
support
for smart card / hardware based authentication into our daily live.

Andreas

Once we have a consensus on what the resulting API would look like,
> my idea would be to create a sequence of submissions to OpenSSL (not
> for 1.1 but to be merged to OpenSSL HEAD after that), which slowly add
> the required functionality step by step (probably leaving out the
> deprecated functions).
>
> Each commit would then be easily reviewable for merging into OpenSSL.
> And where it's lifted from existing libp11 code, I could properly check
> the provenance of each line of code as I go, to make sure I do have
> permission to relicense it.
>
> That's about as far as my plan goes, really. The point here is to
> solicit feedback and work out how best to proceed...
>
> Please note there are two members of the OpenSSL team in Cc. Please
> make sure you "reply to all" and don't drop them.
>
> --
> dwmw2
>
>
> ¹ According to 'git blame', which I appreciate is a blunt tool and doesn't
>   even credit Olaf with any lines of code. But as a sanity check for
> "should
>   I give up on this idea and just write something from scratch?" it's OK.
>   Specifically:
>
> $ for a in `find . -name \*.[ch]` ; do git blame $a; done | sed
> 's/........ (\(.*\)[[:space:]]*20..-..-.. ..:..:.. .*/\1/' | sed
> s/[[:space:]]*$// | sort | uniq -c  | sort -rn
>    4559 Michał Trojnara
>    2813 Andreas Jellinghaus
>     749 Doug Engert
>     454 Nikos Mavrogiannopoulos
>     163 Ludovic Rousseau
>      59 Mikhail Denisenko
>      45 Alon Bar-Lev
>      44 Stephane Adenot
>      39 Nils Larsch
>      32 Michal Trojnara
>       9 Martin Paljak
>       6 Anton Fedorov
>       4 David Woodhouse
>       3 Christian Heimes
>       2 Mike Gerow
>       2 Jean-Pierre Szikora
>       1 LE TOUX Vincent
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[David W. <dw...@in...>]

On Mon, 2016-02-29 at 23:05 +0200, Alon Bar-Lev wrote:
> I believe it will be a mistake to introduce PKCS#11 into OpenSSL.
> The engine should be extended up to a point in which someone can
> implement and engine that can leverage any crypto interface,
> CryptoAPI, PKCS#11 or whatever.

You mean the engine API, rather than specifically engine_pkcs11, yes?

That does seem like a reasonable approach. The STORE that Rich has been
working on does sound like it would facilitate this.

The thing is, I absolutely DO NOT CARE how we do it. I'm more than
happy to listen to your thoughts on how it should be done.

My primary aim is just when applications use OpenSSL, it shall be
expected that *wherever* they could use a filename to specify a
certificate or key, it should Just Work™ if the user provides a PKCS#11
URI instead (in the config file, on the command line, or wherever).

Further than that, I really don't care about much at all :)

> There is much work to be done at OpenSSL level, for example a
> certificate/key/crl store, hierarchy awareness (a set of keys are
> stored on a device, a set of devices can be accessed via same engine
> instance), dynamic content to enable removal and re-introduce keyset
> without destroying context, events for key/device
> availability/removal.

Those sound useful, although I wouldn't class all of them as imperative
for my own purposes. I'd certainly want to ensure that whatever design
we end up with *can* support those. Even if some of them are left as an
exercise for later implementation.

> > Just as importantly, please could you agree to the use of your code
> > in libp11 under a 3-clause BSD licence? 

> Fine by me, 

Thank you.

> but again, libp11 is not the quality nor mindset of what
> OpenSSL should merge.

It provides a lot of the basic PKCS#11 functionality for loading
modules and invoking them. I suspect we can use a lot of it even if we
*then* stop and take a closer look at how it should be seamlessly
*integrated* into the OpenSSL API set.

I see it as a two-phase project in that sense. And I get the impression
most of your commentary is about the second phase.

-- 
dwmw2

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[Alon Bar-L. <alo...@gm...>]

On 29 February 2016 at 10:25, David Woodhouse <dw...@in...> wrote:
>
> On Fri, 2016-02-26 at 19:12 +0200, Alon Bar-Lev wrote:
> >
> > What you seek is actually NSS.
> > This won't happen, ever.
> > Even if it will happen, libp11 is not the right implementation of
> > doing that.
>
> Yeah, we don't want NSS. NSS has its own problems :)
>
> When I say we want to make PKCS#11 a first-class citizen in OpenSSL, I
> don't mean we want to rearchitect OpenSSL to be completely based around
> PKCS#11, as NSS is. I only mean that we want the PKCS#11 functionality
> (like that of libp11 or indeed pkcs11-helper) to be a *part* of
> OpenSSL's APIs. So that anyone using OpenSSL could reasonably be
> *expected* to support certificates/keys from PKCS#11 whenever they
> support using them from a file.

I believe it will be a mistake to introduce PKCS#11 into OpenSSL.
The engine should be extended up to a point in which someone can
implement and engine that can leverage any crypto interface,
CryptoAPI, PKCS#11 or whatever.

There is much work to be done at OpenSSL level, for example a
certificate/key/crl store, hierarchy awareness (a set of keys are
stored on a device, a set of devices can be accessed via same engine
instance), dynamic content to enable removal and re-introduce keyset
without destroying context, events for key/device
availability/removal.

One of the major challenges is to delegate CPU time to the engine for
house keeping and idle tasks. Another challenge is to resolve
threading issues. An asynchronous engine interface will resolve most
of the issues.

> > I have experience in working with openssl codebase and it won't be
> > extended to support such specific implementation.
> > There was the opencryptoki project, that was the closest one of doing
> > that without adding any code to openssl.
>
> The point here *is* to add code to OpenSSL. That's why we have OpenSSL
> developers on Cc, who are interested in making this happen.
>
> Your ideas on what the OpenSSL API should look like would be very much
> welcomed. You're absolutely right that it shouldn't turn into NSS, and
> I have already been talking to Rich about the keystore. Any more
> insight, either in advance or as I proceed with trying to put something
> together, would be very much appreciated; thanks!
>
> Just as importantly, please could you agree to the use of your code in
> libp11 under a 3-clause BSD licence? Whether or not the final OpenSSL
> 1.2 API actually looks like libp11 or not, I'm fairly sure there *will*
> be a lot of opportunity for code re-use, and the permission to
> relicense it would be very much appreciated.

Fine by me, but again, libp11 is not the quality nor mindset of what
OpenSSL should merge.

Regards,
Alon

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[David W. <dw...@in...>]

On Fri, 2016-02-26 at 19:12 +0200, Alon Bar-Lev wrote:
> 
> What you seek is actually NSS.
> This won't happen, ever.
> Even if it will happen, libp11 is not the right implementation of
> doing that.

Yeah, we don't want NSS. NSS has its own problems :)

When I say we want to make PKCS#11 a first-class citizen in OpenSSL, I
don't mean we want to rearchitect OpenSSL to be completely based around
PKCS#11, as NSS is. I only mean that we want the PKCS#11 functionality
(like that of libp11 or indeed pkcs11-helper) to be a *part* of
OpenSSL's APIs. So that anyone using OpenSSL could reasonably be
*expected* to support certificates/keys from PKCS#11 whenever they
support using them from a file.

> I have experience in working with openssl codebase and it won't be
> extended to support such specific implementation.
> There was the opencryptoki project, that was the closest one of doing
> that without adding any code to openssl.

The point here *is* to add code to OpenSSL. That's why we have OpenSSL
developers on Cc, who are interested in making this happen.

Your ideas on what the OpenSSL API should look like would be very much
welcomed. You're absolutely right that it shouldn't turn into NSS, and
I have already been talking to Rich about the keystore. Any more
insight, either in advance or as I proceed with trying to put something
together, would be very much appreciated; thanks!

Just as importantly, please could you agree to the use of your code in
libp11 under a 3-clause BSD licence? Whether or not the final OpenSSL
1.2 API actually looks like libp11 or not, I'm fairly sure there *will*
be a lot of opportunity for code re-use, and the permission to
relicense it would be very much appreciated.

Thanks.

-- 
dwmw2

[Opensc-devel] Fix (default) compiler warnings and be more strict

[Ludovic R. <lud...@gm...>]

Hello,

I worked on the idea that important warnings should NOT be ignored.
To do that I add the compilation flag -Werror so that a compilation warning
is considered as an error and the automatic compilation from travis-CI will
report the build in error.

The current master branch already reports problems, without changing the
compiler warnings level.
See [1] for the GNU/Linux gcc 4.6.3 compilation and [2] for the GNU/Linux
clang 3.4 compilation.
And [3] for the Mac OS X gcc LLVM 6.0 and [4] for the Mac OS X clang LLVM
6.0.

If I enable -Werror (as done in my travis PR [5]) the 4 compilations fails.
I have not modified the compilation on MinGW.

My plan is to:
1. fix the few warnings reported
2. merge the -Werror change so that all future PR will be tested
3. increase the warning level and fix corresponding bugs (if time permit)

Comments?
Volunteers to help on this task?

Regards,

[1] https://travis-ci.org/OpenSC/OpenSC/jobs/112371473
[2] https://travis-ci.org/OpenSC/OpenSC/jobs/112371472
[3] https://travis-ci.org/OpenSC/OpenSC/jobs/112418930
[4] https://travis-ci.org/OpenSC/OpenSC/jobs/112418929
[5] https://github.com/OpenSC/OpenSC/pull/692

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] Erasing card with pkcs15-init not possible.

[Karsten S. <ace...@we...>]

I can't erase my Feitian ePass2003 with "pkcs15-init --erase-card".
These are the failures:

reader-pcsc.c:375:pcsc_detect_card_presence: returning with: 5
iso7816.c:173:iso7816_read_record: returning with: -1202 (Record not found)
Failed to erase card: Security status not satisfied

Karsten Speckin

Re: [Opensc-devel] Capturing APDU trace on Windows => my solution

[Vincent Le T. <vin...@my...>]

Yes, I already discussed with Mounir about that.

The adaptation needed for a winscard.dll stub for all version of Windows is
a continous job.
Like for the function SCardReadCache used by the PIV/GIDS minidriver,
that's why I explored an other lead  ...

I do not know if there is a problem in winscard stub, but the Base smart
card KSP on Windows 10 seems to prohibit the use of winscard stub.

regards,
Vincent

2016-02-28 10:26 GMT+01:00 Ludovic Rousseau <lud...@gm...>:

> 2016-02-27 23:09 GMT+01:00 Vincent Le Toux <
> vin...@my...>:
>
>> Hi,
>>
>
> Hello,
>
>
>>
>> For those developping/debugging on Windows I may have something
>> interesting for you.
>>
>> To debug my programs, I needed to capture APDU.
>>
>
> have you tried SCardSpy [1]?
> I do not use Windows myself so never used it but it helped other people
> [2] debug problems on Windows.
>
> Bye
>
> [1] https://www.idrix.fr/Root/content/category/7/25/46/
> [2] https://github.com/LudovicRousseau/pyscard/issues/19
>
> --
>  Dr. Ludovic Rousseau
>



-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

Re: [Opensc-devel] Capturing APDU trace on Windows => my solution

[Ludovic R. <lud...@gm...>]

2016-02-27 23:09 GMT+01:00 Vincent Le Toux <vin...@my...>
:

> Hi,
>

Hello,


>
> For those developping/debugging on Windows I may have something
> interesting for you.
>
> To debug my programs, I needed to capture APDU.
>

have you tried SCardSpy [1]?
I do not use Windows myself so never used it but it helped other people [2]
debug problems on Windows.

Bye

[1] https://www.idrix.fr/Root/content/category/7/25/46/
[2] https://github.com/LudovicRousseau/pyscard/issues/19

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] Capturing APDU trace on Windows => my solution

[Vincent Le T. <vin...@my...>]

Hi,

For those developping/debugging on Windows I may have something interesting
for you.

To debug my programs, I needed to capture APDU.
I was getting tired of making winscard.dll stubs for x64 & x86 and for each
Windows version. Typically new minidriver (like GIDS) are using
SCardReadCache / WriteCache functions which are not available on older
version.
I was also limited for lsass.exe debug.

Api Monitor (http://www.rohitab.com/apimonitor) can solve the lsass problem
with this patch (
http://www.rohitab.com/discuss/topic/41981-updated-api-definitions/?p=10102474
).
But it shouldn't run on production system because at the disconnection,
lsass crashes everytimes.
Another solution is kernel debugging (windbg).
But this is not easy to use and not very user friendly for APDU debugging.

Then, I had to debug something on the shared smart card reader on VMWare.

That's why I made a small developper program I called APDUTrace (
http://download.mysmartlogon.com/APDUTrace/APDUTrace.exe).

In short, this is a stand alone .exe which a filter driver embedded.
Because this is a upper filter driver, it collects the APDU at the system
level before the APDU is sent to the smart card reader.

Launch the .exe (as admin) press "Live tracing" and enjoy.
Valid for all x64, x86 systems from Windows XP to Windows 10
Boot time logging is also available.

I've done some tests but like new programs there are hidden bugs.
To test in a VM before and feedbacks are welcome !

regards,
-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[Nikos M. <n.m...@gm...>]

On Sat, 2016-02-27 at 15:55 +0000, David Woodhouse wrote:
> On Sat, 2016-02-27 at 10:46 +0100, Nikos Mavrogiannopoulos wrote:
> > 
> > p11-kit is not about desktop. I don't even think it provides any
> > desktop integration. It is about configuration of pkcs11 modules in 
> > a
> > system and coordination of the usage of PKCS #11. For example one
> > application could use smart cards even if it is linked with all of
> > openssl, nss or gnutls (and that's a very common scenario in 
> > complex
> > applications).
> 
> However, those benefits are achieved just by going via p11-kit
> -proxy.so
> as the default PKCS#11 provider — that's how I already did it for
> engine_pkcs11, after all.

The p11-kit proxy requires function call rewritting something that
cannot work in environments where code generation is prohibited (e.g.,
apache under selinux in RHEL is like that).

Said that, for simplicity p11-kit uses code generation for few other
cases which don't relate to the proxy, but these can be fixed; the
proxy cannot unfortunately be without any code generation.

regards,
Nikos

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[David W. <dw...@in...>]

On Sat, 2016-02-27 at 10:46 +0100, Nikos Mavrogiannopoulos wrote:
> 
> p11-kit is not about desktop. I don't even think it provides any
> desktop integration. It is about configuration of pkcs11 modules in a
> system and coordination of the usage of PKCS #11. For example one
> application could use smart cards even if it is linked with all of
> openssl, nss or gnutls (and that's a very common scenario in complex
> applications).

However, those benefits are achieved just by going via p11-kit-proxy.so
as the default PKCS#11 provider — that's how I already did it for
engine_pkcs11, after all.

So perhaps we are better off keeping it simple. Just have our own URI
parsing (we can *lift* p11-kit's, we have a basic implementation in the
engine already that I put there, *and* Jaroslav has offered a version
(thanks).

Am I missing something else that a direct dependency on libp11-kit
would give us?


-- 
dwmw2

Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[David W. <dw...@in...>]

> On Fri, 2016-02-26 at 22:36 +0200, Michael Jackson wrote:
>
>> [...]
>> After the heartbleed fiasco, RH has been switching as much as
>> possible to use NSS and stopped linking against OpenSSL. NSS is
>> probably far more portable than OpenSSL, and would probably be a
>> better target for integration.
>
> I do not believe you are a Red Hat spokesperson, and as far as I know
> none of these are true.

Red Hat *did* switch a bunch of stuff to NSS in the past but IIRC that was
FIPS-related. These days we ought to be doing the opposite -- there are
open bugs for things like curl for "does not accept PKCS#11 URI"
(#1219544) which could be solved just by building against GnuTLS. Could be
made to work with OpenSSL too but requires jumping through extra
libp11/engine hoops because OpenSSL doesn't have that support built in ...
which brings us nicely back on topic :)

NSS at this point is *nit* a better target for integration. Not before
https://bugzilla.mozilla.org/show_bug.cgi?id=1161219 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1162897 are fixed.

-- 
dwmw2