Le 12/06/2011 13:19, Martin Paljak a écrit :
> On Jun 12, 2011, at 06:29 , Douglas E. Engert wrote:
>> On 6/11/2011 12:31 PM, Viktor Tarasov wrote:
>>> Le 10/06/2011 19:06, Martin Paljak a écrit :
>>>> 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?
>> 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.
> NonRepudiation is a very tricky property, which has caused a lot of
> misunderstanding and different interpretations before (I never reached a
> consensus with NSS/Mozilla folks in the matter of the interpretation of this
> property, even in the context of *TLS authentication*)
>
> The only time nonrepudiation is mentioned in PKCS#11 is in the context of
> public keys. As the name (nonrepudiation) implies, it is IMHO more of a
> property of the verification process (meaning when somebody tries to test the
> repudiation) than for actual signing process, even if the underlying
> technical implementation on a smart card differs from the "normal" signature
> mechanism. Figuring out such differences and hiding them from applications in
> the card driver is in fact the purpose of OpenSC.
It's hidden for the applications that uses card,
but it can be important for the application that deals with the card
post-issuance process.
>> So I would argue that it is not for OpenSC to to define extensions to
>> PKCS#11 to
>> accommodate PKCS#15.
>>>> 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 .
> PKCS#11 is a technical software API for accessing keys in HSM-s or smart
> cards or any other "cryptographic device". The resulting signature (the 256
> byte array if 2048bit RSA keys are used) of a "qualified" key does not differ
> in syntax from a "nonqualified" signature.
>
> Certificates and other higher level (often non-technical) semantics should
> stay separate from that software API. The fact that a certificate (and the
> associated private key) can be used for "qualified signatures" is an
> application (or certificate) -specific semantic property. Even if it seems
> like a generic property, making the precedence would call for "flag that this
> certificate can be used for VPN authentication" and others. Yes, PKCS#11
> defines attributes that could come from the certificate (compare:
> CKA_START_DATE) but they are by no means authoritative. Evaluation of the
> certificate is still done by the calling application.
>
>>>> I would leave the task for the application to figure out instead of
>>>> inventing nonstandard extensions.
>> I agree.
>>
>>> 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.
> True. But I have not seen the actual benefit of any of those extensions.
I've seen the extensions that helps the card initialization and PIN management
operations.
> Yet you are right, attributes can be vendor-specific and they are one of the
> designed extensions, as there are much worse abuses of PKCS#11 out there.
>
> Thus if done, I would like to consider careful argumentation for the need of
> the extension and would like to see any deviations to be clearly documented
> and communicated back to the body issuing the "standard".
The key usage policy can be restricted on the 'cryptographic device' level.
For example 'decrypt', 'signature' and 'qualified signature' can be protected
by different ACLs, the key can be placed into the slots with restricted usage.
That's why it's important to transfer to the application that creates
'cryptographic objects' some insight onto the future key usage.
Actually, using the PKCS#11 API, it can be done when providing 'create-object'
template that includes the 'key usage' attributes -- CKA_SIGN, CKA_DECRYPT, ...
This list of 'key usage' attributes should be extended to include the
'NON-REPUDIATION' (or 'qualified signature') attributes to reflect
the distinction that 'cryptographic device' can made between 'signature' and
'signature-with-non-repudiation'.
> Martin
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
