Re: [opensc-devel] About OpenSC PKCS#11

2011-11-10 Thread Viktor Tarasov
Hello Douglas,

Le 09/11/2011 20:26, Douglas E. Engert a écrit :
 On 11/9/2011 11:39 AM, Viktor Tarasov wrote:
 Hello,

 I would like to 'touch' the PKCS#11 module of OpenSC and looking for your 
 opinions/suggestions about:
 - removing of 'pkcs15init' framework;
 Would you keep the functionality of the pkcs15init, and support it with the 
 pkcs15 framework?
 Parts of the current pkcs15init code that I am interested in is required to 
 support
 for PKCS#11 session objects. For example the C_DeriveKey output is returned 
 as a session key object.
 Session objects may reside on the card or only in the software, depending how 
 a card
 does a key derivation.

Pkcs15init functionalities are supported by pkcs15 framework of OpenSC built 
with OpenSSL.

The main (and it seems the only) functionality of 'pkcs15init' framework is to 
create pkcs#15
application on the non-initialized card. Do we really need do it with PKCS#11 
API?


 - configurable support of the multi on-card applications and multi-pins;
 - removing the 'one-pin' version of pkcs#11 module (or rather replacing it 
 with particular case of the configuration);
 - no separate slot for public objects.
 The support for mutli on-card applications, would be good. The PIV-card, for 
 example, is really
 an on-card application, and any support to select card/application drivers 
 based on application
 rather then just ATR could be useful.


 The proposed PKCS#11 configuration concerns creating of slots, its 
 authentication objects and its content.
 Possibilities are:

 - 'all' -- actual behavior -- slot for every non-sopin, non-unblock PINs 
 and optionally for PUK;
   All public objects in the limit of one on-card application are 
 associated to the first 'User PIN' slot.

 - combinations of symbolic PIN names: 'user', 'sign' and 'application', 
 where important combination are:

 -- if only 'user' (one-pin) used, the unique slot will contains private 
 objects from the all on-card applications
which are protected by corresponding card's PIN. (In the 
 multi-application cards, the same global card's PIN could be
referenced by the pkcs#15 'authentication' object from more then one 
 on-card application).
 Other private objects are not visibles (For ex. the ones protected by 
 SignPIN).
To this slot also added all public objects from the all on-card 
 applications.
(This configuration is suitable for FF).

 -- 'user' + 'sign' -- the same as previous with exception that second slot 
 is created for the
private object protected by 'sign' PIN and this object's public 
 'friends'.
(This configuration could be useful for FF, and Thunderbird).

 -- 'application' -- one slot per on-card application. So that there is the 
 possibility to differentiate
   the  on-card application with the PKCS#11 API. (Equivalent of the 
 '--aid' option in the pkcs15(init) tools).
   (This configuration mostly for initializing of the on-card 
 applications with the PKCS#11 API.)

 -- 'application' + 'sign' the same as 'all' without optional slot for PUK.
 How would all of this effect existing card drivers?

'All' configuration is destinated to reproduce the actual behavior of pkcs11 
module.
With an exception of separate slot for all public objects -- do we really need 
it?

Actual 'one-pin' version of pkcs11 module will be presented by new version of 
pkcs11 module in 'user' configuration
-- no need to package two versions of the OpenSC pkcs#11 module.



 Are the above configurations based on the card or some configuration file?


These configuration options are supposed to be included into 'pkcs11' section 
of the general OpenSC configuration (opensc.conf file).



 Kind wishes,
 Viktor.
 ___
 opensc-devel mailing list
 opensc-devel@lists.opensc-project.org
 http://www.opensc-project.org/mailman/listinfo/opensc-devel


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] About OpenSC PKCS#11

2011-11-10 Thread Alon Bar-Lev
On Wed, Nov 9, 2011 at 7:39 PM, Viktor Tarasov viktor.tara...@gmail.com wrote:
 Hello,

 I would like to 'touch' the PKCS#11 module of OpenSC and looking for your 
 opinions/suggestions about:
 - removing of 'pkcs15init' framework;
 - configurable support of the multi on-card applications and multi-pins;
 - removing the 'one-pin' version of pkcs#11 module (or rather replacing it 
 with particular case of the configuration);
 - no separate slot for public objects.

1. If you remove the pkcs#15 init how will you init the card? How will
you create several PINs?

2. If you separate PINs into slot, you must expose the public object
within the same slot of the private object. As application will look
for the private object on the same slot with the same id of the public
one.

3. The one-pin should have been removed long time ago in favor of
configuration :)

But as usual, I will keep reminding anyone that the most severe issue
of OpenSC PKCS#11 is the require for lock reader since C_Login until
eternity in order to achieve secured setup. As far as I know this has
not been addressed.

1. It is explicitly violate PKCS#11 spec.

2. Disabling this lock_login=false exposes your card for other
applications without authentication.

3. Default is disabled, which and back to (2).

Regards,
Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] About OpenSC PKCS#11

2011-11-10 Thread NdK
Il 09/11/2011 18:39, Viktor Tarasov ha scritto:

 I would like to 'touch' the PKCS#11 module of OpenSC and looking for your 
 opinions/suggestions about:
Regarding touches... Is some level of restructuration planned?
I'm thinking about something object-oriented, a-la GTK+ (OO C, not C++).

I'm sure it could attract more developers (at least I'd try again to get
involved) and simplify adding features (as long as the internal API is
well-planned)...

BYtE,
 Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] About OpenSC PKCS#11

2011-11-10 Thread Viktor Tarasov
Le 10/11/2011 13:16, Alon Bar-Lev a écrit :
 On Wed, Nov 9, 2011 at 7:39 PM, Viktor Tarasovviktor.tara...@gmail.com  
 wrote:
 Hello,

 I would like to 'touch' the PKCS#11 module of OpenSC and looking for your 
 opinions/suggestions about:
 - removing of 'pkcs15init' framework;
 - configurable support of the multi on-card applications and multi-pins;
 - removing the 'one-pin' version of pkcs#11 module (or rather replacing it 
 with particular case of the configuration);
 - no separate slot for public objects.
 1. If you remove the pkcs#15 init how will you init the card? How will
 you create several PINs?


When creating the on-card PKCS#15 application on the non-initialized card,
I guess that the 'pkcs15-init' tool is more flexible, has more possibilities 
and more appropriate to use.

Creating, modifying, removing of the objects on the initialized card is covered 
by 'pkcs15' framework.


 2. If you separate PINs into slot, you must expose the public object
 within the same slot of the private object. As application will look
 for the private object on the same slot with the same id of the public
 one.

Exact.
That's what I described in the details of different configuration possibilities.


 3. The one-pin should have been removed long time ago in favor of
 configuration :)


Look into the win32/OpenSC.wxs, src/pkcs11/Makefile.am(mak) and search for 
'onepin_opensc_pkcs11'.
Also look sources for 'hack_en(dis)abled'.



 But as usual, I will keep reminding anyone that the most severe issue
 of OpenSC PKCS#11 is the require for lock reader since C_Login until
 eternity in order to achieve secured setup. As far as I know this has
 not been addressed.

 1. It is explicitly violate PKCS#11 spec.

 2. Disabling this lock_login=false exposes your card for other
 applications without authentication.

 3. Default is disabled, which and back to (2).

Ok, we will think about it.


 Regards,
 Alon.

Kind wishes,
Viktor.


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] About OpenSC PKCS#11

2011-11-10 Thread Viktor Tarasov
Le 10/11/2011 14:02, NdK a écrit :
 Il 09/11/2011 18:39, Viktor Tarasov ha scritto:
 I would like to 'touch' the PKCS#11 module of OpenSC and looking for your 
 opinions/suggestions about:
 Regarding touches... Is some level of restructuration planned?
 I'm thinking about something object-oriented, a-la GTK+ (OO C, not C++).

 I'm sure it could attract more developers (at least I'd try again to get
 involved) and simplify adding features (as long as the internal API is
 well-planned)...

It could be interesting and didactical.
But I'm afraid that it will need more time for conceiving and implementing.
It would be nice to have parallel dedicated development branch.

As for me, this noble task of complete redesigning of pkcs#11 module
should not delay the implementing of the features that are needed here and now.

My proposal is mostly appealed to answer an actual need -- support of the 
multi-pkcs15-applications cards.
As well as some evident (from my point of view) optimizations.

 BYtE,
   Diego.

Kind regards,
Viktor.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


[opensc-devel] About OpenSC PKCS#11

2011-11-09 Thread Viktor Tarasov
Hello,

I would like to 'touch' the PKCS#11 module of OpenSC and looking for your 
opinions/suggestions about:
- removing of 'pkcs15init' framework;
- configurable support of the multi on-card applications and multi-pins;
- removing the 'one-pin' version of pkcs#11 module (or rather replacing it with 
particular case of the configuration);
- no separate slot for public objects.


The proposed PKCS#11 configuration concerns creating of slots, its 
authentication objects and its content.
Possibilities are:

  - 'all' -- actual behavior -- slot for every non-sopin, non-unblock PINs and 
optionally for PUK;
All public objects in the limit of one on-card application are associated 
to the first 'User PIN' slot.

  - combinations of symbolic PIN names: 'user', 'sign' and 'application', where 
important combination are:

  -- if only 'user' (one-pin) used, the unique slot will contains private 
objects from the all on-card applications
 which are protected by corresponding card's PIN. (In the multi-application 
cards, the same global card's PIN could be
 referenced by the pkcs#15 'authentication' object from more then one 
on-card application).
Other private objects are not visibles (For ex. the ones protected by SignPIN).
 To this slot also added all public objects from the all on-card 
applications.
 (This configuration is suitable for FF).

-- 'user' + 'sign' -- the same as previous with exception that second slot is 
created for the
 private object protected by 'sign' PIN and this object's public 'friends'.
 (This configuration could be useful for FF, and Thunderbird).

-- 'application' -- one slot per on-card application. So that there is the 
possibility to differentiate
the  on-card application with the PKCS#11 API. (Equivalent of the '--aid' 
option in the pkcs15(init) tools).
(This configuration mostly for initializing of the on-card applications 
with the PKCS#11 API.)

-- 'application' + 'sign' the same as 'all' without optional slot for PUK.


Kind wishes,
Viktor.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] About OpenSC PKCS#11

2011-11-09 Thread Douglas E. Engert


On 11/9/2011 11:39 AM, Viktor Tarasov wrote:
 Hello,

 I would like to 'touch' the PKCS#11 module of OpenSC and looking for your 
 opinions/suggestions about:
 - removing of 'pkcs15init' framework;

Would you keep the functionality of the pkcs15init, and support it with the 
pkcs15 framework?
Parts of the current pkcs15init code that I am interested in is required to 
support
for PKCS#11 session objects. For example the C_DeriveKey output is returned as 
a session key object.
Session objects may reside on the card or only in the software, depending how a 
card
does a key derivation.

 - configurable support of the multi on-card applications and multi-pins;
 - removing the 'one-pin' version of pkcs#11 module (or rather replacing it 
 with particular case of the configuration);
 - no separate slot for public objects.

The support for mutli on-card applications, would be good. The PIV-card, for 
example, is really
an on-card application, and any support to select card/application drivers 
based on application
rather then just ATR could be useful.



 The proposed PKCS#11 configuration concerns creating of slots, its 
 authentication objects and its content.
 Possibilities are:

- 'all' -- actual behavior -- slot for every non-sopin, non-unblock PINs 
 and optionally for PUK;
  All public objects in the limit of one on-card application are 
 associated to the first 'User PIN' slot.

- combinations of symbolic PIN names: 'user', 'sign' and 'application', 
 where important combination are:

-- if only 'user' (one-pin) used, the unique slot will contains private 
 objects from the all on-card applications
   which are protected by corresponding card's PIN. (In the 
 multi-application cards, the same global card's PIN could be
   referenced by the pkcs#15 'authentication' object from more then one 
 on-card application).
 Other private objects are not visibles (For ex. the ones protected by 
 SignPIN).
   To this slot also added all public objects from the all on-card 
 applications.
   (This configuration is suitable for FF).

 -- 'user' + 'sign' -- the same as previous with exception that second slot is 
 created for the
   private object protected by 'sign' PIN and this object's public 
 'friends'.
   (This configuration could be useful for FF, and Thunderbird).

 -- 'application' -- one slot per on-card application. So that there is the 
 possibility to differentiate
  the  on-card application with the PKCS#11 API. (Equivalent of the 
 '--aid' option in the pkcs15(init) tools).
  (This configuration mostly for initializing of the on-card applications 
 with the PKCS#11 API.)

 -- 'application' + 'sign' the same as 'all' without optional slot for PUK.

How would all of this effect existing card drivers?

Are the above configurations based on the card or some configuration file?



 Kind wishes,
 Viktor.
 ___
 opensc-devel mailing list
 opensc-devel@lists.opensc-project.org
 http://www.opensc-project.org/mailman/listinfo/opensc-devel



-- 

  Douglas E. Engert  deeng...@anl.gov
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel