Re: [Opensc-devel] OpenSC at FOSDEM 2018

[Jakub J. <jj...@re...>]

On Mon, 2018-01-08 at 00:31 +0100, NdK wrote:
> Il 07/01/2018 15:14, Douglas E Engert ha scritto:
> 
> > Note that much of the middleware including pkcs11 runs in the user
> > applications not in the OS.
> 
> IMO that's one of the problems. Connect the daemon to the user's
> processes ("session" is limiting...).
> 
> > Some call this a security requirement.
> 
> I call it lazyness. Many programs use long-term locking only because
> it's simpler to handle. You don't risk that objects change without
> you
> knowing.
> 
> History is becoming a weight that prevents further evolution. Many
> limitations are rooted in assumptions that are no longer true.
> We'd need PKCS11-2018, a complete revision of the standard that
> ditches
> a lot of dead weight.

PKCS#11 is not dead. There is going to be PKCS#11 3.0 [1], which I try
to follow, but I don't think, there is going to be any significant
change in the way of handling multiple processes. Or what dead weight
you mean in this case?

> 
> > Others would call this a bug.
> 
> Ill-planned feature, since there usually are many processes.
> 
> > There are some things you can do. For some cards, OpenSC can cache
> > certificates
> > and other data in in the user's home directory. OpenSC can try and
> > leave
> > the card
> > in a logged instate if you set the disconnect = leave see the
> > comments
> > in opensc.conf.
> > But other applications not using OpenSC can still lock the access
> > to the
> > card at the PCSC level.
> 
> All the SC-aware programs I tried in Linux required OpenSC :)

GnuPG's scdaemon is example that was already mentioned several times,
that is widely used and that does not go through the OpenSC, which
makes it common problem.

Anyway, thank you Diego for your valuable comments and ideas. I will
certainly have a look into them and try to address them in my talk or
in OpenSC project, if it would be possible.

[1] https://wiki.oasis-open.org/pkcs11/3.0WorkItems

Thanks,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.