Le 10/06/2011 19:06, Martin Paljak a écrit :
> Hello,
>
>
> On Jun 10, 2011, at 19:46 , webmas...@opensc-project.org wrote:
>> pkcs11: framework-pkcs15: OpenSC specific 'non-repudiation' cryptoki
>> attribute ...
>>
>> In PKCS#11 there is no CKA_ attribute dedicated to the NON-REPUDIATION flag.
>> We need this flag in PKCS#15/libopensc to make dinstinction between
>> 'signature' and 'qualified signature' key slots.
> Why?
In PKCS#15 there is 'nonRepudiation' key usage flag.
In PKCS#11 the 'non-repudiation' is mentioned, but there is no dedicated
attribute and there is no means transfer the 'non-repudiation' key usage to the
pkcs#11 module.
On the card level (libopensc), for the two operations -- 'signature'
('INTERNAL-AUTHENTICATION')
and 'signature-with-non-repudiation' ('PSO-COMPUTE-DIGITAL-SIGNATURE')
different mechanisms can be used.
The card (can) make clear distinction between these two operations, with the
distinct ACLs.
The card with the pre-allocated key slots may have the different slots for
these operations.
So, when generating new key, it's important to transfer on the card level the
information about the future usage of the key.
It's actually easy to make with the pkcs15 tools (library), but not with the
pkcs11 tool (library).
This new flag allows to make this distinction for the application that uses the
PKCS#11 library.
> PKCS#11 is an API for accessing cryptographic hardware. From that perspective
> (and from API perspective) there's no difference if a signature is
> "qualified" or "not qualified".
Exact,
as I've told above, PKCS#11 knows about 'non-repudiation' but do not make
distinction between 'signature' and 'signature-with-non-repudiation'
('qualified signature').
PKCS#11 do not make this distinction, but PKCS#15 and libopensc do .
> Applications that deal with qualified signatures usually depend on certain
> certificates (and their properties).
Before it gets the certificate,
it has to generate the key, and at this stage it can be obliged to indicate in
somewhat manner the future usage of this key.
> I would leave the task for the application to figure out instead of inventing
> nonstandard extensions.
To figure out what? The location of the the pkcs15 tools ?
OpenSC is not the first PKCS#11 module with the non-standard extensions.
Possibility of these extensions is previewed by the PKCS#11 standard itself.
The applications that do not creates 'qsign' keys, or that uses only the
standard API,
will see no difference in the behavior of the OpenSC PKCS#11 module.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
