On 6/12/2011 6:57 AM, Viktor Tarasov wrote:
> 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?
Describe characteristics of the key, but not characteristics of how policy says
a key
can be used. 'signature' and 'qualified signature' should like policy set by
the card
issuer, and not characteristics of a key.
>
>> 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 ... ?
PKCS#11 is an abstract standard, and in principal could be used to initialized
and personalized
a card, but in the real world, it is not practical, as card vendors have not
made this a priority
and each has their own way to do this.
>
>
>
>>> 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.
As Martin points out there are ways in PKCS#11 to define vendor objects, key
types, certificates,
attributes, mechanisms and return values. I know the Mozilla NSS does some of
this, looking for trust.
>
>>> 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.
Again agreeing with Martin, if you can show that your extensions fit within the
PKCS#11 extensions,
and the code does not affect other cards or calling application, OpenSC could
consider these
modifications.
>
>
>>> 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
>>>
>>>
>
>
--
Douglas E. Engert <[email protected]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
