Le 12/06/2011 05:29, Douglas E. Engert a écrit :
> On 6/11/2011 12:31 PM, Viktor Tarasov wrote:
>> Le 10/06/2011 19:06, Martin Paljak a écrit :
>>> Hello,
>>>
>>>
>>> On Jun 10, 2011, at 19:46 , [email protected] 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?
> Good question, but I would suggest that I agree with Martin's comments
> below, as there is a different answer and conclusion to what you are
> proposing.
>
> PKCS#15 may have such a flag, but this does not imply that PKCS#11 has to
> make it available.
> PKCS#11 does not require the use of PKCS#15. And as you point out not all
> PKCS#15
> information is available via PKCS#11.
>
> I would argue that with PKCS#11 the source of any such flags, must come from
> the
> certificate and and the application should verify the certificate, and its
> flags.
> The application can then select the certificate and issues the required
> PKCS#11 calls
> to use the private key associated with the certificate.
What do you suppose the PKCS#11 usage key CKA_ attributes are existing for?
> So the application can always search for all certificates, and find the
> one with the non-repudiation bit set. (If the certificate dons not have this
> but the PKCS#15 does, the certificate should not be trusted.)
>
> The application should not depend on the flags in PKCS#15, but only depend on
> the certificate or other signed objects that can be read from the card and
> the ability
> of the card to do the crypto.
Application that uses keys and certificates do not depends, it's an application
that creates them do (can do).
> So I would argue that it is not for OpenSC to to define extensions to PKCS#11
> to
> accommodate PKCS#15.
I agree with all this when it's going about using of the card -- the card
already initialized and personalized -- 'read-only' card.
My question is, from your point of view,
should the OpenSC PKCS#11 module be used for the card initialization (in lesser
manner) and
for the card personalization -- generate, import, renewal, etc ... ?
>> 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).
>>
> So why do you assume that you can initialize a PKCS#15 card using PKCS#11?
> One is not a super set
> of the other. If there are special PKCS#15 flags, ACLs, etc, use a PKCS#15
> tool to initialize
> the card.
Initialization can be a part of operation with PKCS#11,
but essential is not initialization. It's going about card personalization and
update.
>> 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.
> But that is part of the card issuing process.
How do you classify the card personalization and update process ? Do it make
the part of 'post-issuance' process?
>>> I would leave the task for the application to figure out instead of
>>> inventing nonstandard extensions.
> I agree.
If I will not arrive to convince our community, I will roll it back.
>> 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-commits mailing list
>> [email protected]
>> http://www.opensc-project.org/mailman/listinfo/opensc-commits
>>
>>
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
