Le 13/06/2011 16:40, Douglas E. Engert a écrit :
>
>
> 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 , 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?
>>> 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.
Sorry, I do not follow .
Where and how can I use the characteristics described, for example, by
'CKA_SIGN and CKA_DECRYPT' ?
I do not talking about key using, it's going about creating key.
Let's imagine,
my 'crypto device' contains key slots with only 'decrypt' or only 'sign'
operation allowed.
From your point of view, when creating key in such device, is it acceptable:
- to put the CKA_DECRYPT attribute into the create-object template;
- on the frame-pkcs15 side detect the presence of this attribute (and the
absence of CKA_SIGN);
- compose accordingly the PKCS#15 key usage flags;
- transfer these usage flags to the card specific part;
- and finally create key in a proper slot.
Is it still in the limits of the 'normal' using of the PKCS#11 module?
>>
>>> 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.
As far as I understood your answer, you accept the using of PKCS#11 module for
the card personalization and post-issuance operations.
>>
>>>> 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.
It's going about defining the OpenSC vendor specific attribute.
In complete accordance with the PKCS#11.
>
>>
>>>> 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,
Vendor defined CKA_ attribute fits the PKCS#11 specification.
> and the code does not affect other cards or calling application, OpenSC could
> consider these modifications.
Application that do not use this attribute will not have PKCS#15
'nonRepudiation' flag set when creating key.
Do you need something more to 'show that it do not affect other cards' ?
>>>> 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
>>>> opensc-comm...@lists.opensc-project.org
>>>> http://www.opensc-project.org/mailman/listinfo/opensc-commits
>>>>
>>>>
>>
>>
>
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
