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.
> 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.
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".
Martin
--
@MartinPaljak.net
+3725156495
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
