Hello, So to recap what I've understood: - certain cards have different operations for generating signatures, one which is good for nonrepudiation and one that is good for any other signature/encryption operation. - detection of these differences in the card river happens with detecting the presence of PKCS#15 key usage bit "nonrepudiation" - PKCS#11 does not define an attribute that would carry the "nonrepudiation" meaning, which is present in PKCS#15 - the main purpose for this new attribute would be setting the nonrepudiation flag through the template when generating keys with PKCS#11 - vendor specific PKCS#11 attributes is a perfectly legit way of extending PKCS#11 - there are mixed feelings about the flag :)
As I understand there's an important difference - your intended primary purpose for the flag is not to communicate the "this is a nonrepudiation key" fact to the application for existing keys (which, indeed, should be done by trusted attributes, AKA information in the certificate) but vice versa: allowing the application to say that "the generated key will be provisioned with a certificate that will also have nonrepudiation properties, so please set this flag in the to-be-created PKCS#15 structures as well". Having the extra attribute available for existing nonrepudiation keys (which was the only visible result of the patch as it was now commited) will be a cherry on the cake. I personally don't like deviations from standards because it demolishes the point of the them. A standard means that given a fixed set of requirements from the standard, the underlying implementations should be interchangeable. Extending the standard means becoming Microsoft - looks like following the standard, smells like following the standard, but interoperable with only MS products ;) Of course there's another option - leading the way and resulting in your actions being standardized, somebody has to be the first anyway? That's why I think that open source projects, if going a "proprietary way", should make every effort to make sure that the deviations become widespread and find their way back to the original standard. Having open standards makes open source software possible, that spirit should be followed and encouraged. But that's my personal opinion. As said, custom PKCS#11 attributes are perfectly "legal", thus having useful extended functionality should be a welcomed change. But here's an interesting quote from a person who could be well informed about the internals of PKCS#11: [1] On Mar 16, 2010, at 00:12 , Robert Relyea wrote: > To date, even the Cryptoki group has washed its > hands on provisioning and initialization of cards. Maybe that is a reason why PIV also only mandates a "read interface" and the personalization part can be anything (proprietary). This might be the business model "motivator". Personalization happens usually once, usage of those keys happens for years. I am thus not very optimistic about any amendments on this getting to PKCS#11 spec, which is meant for *any* HSM type device, be it a small USB token or a network connected HSM. As written by Alon, the safest (not necessarily the smartest) bet for any PKCS#11 application which wishes to remain compatible is to use the smallest possible subset and implement it in as standard way as possible. Thus I would not climb many fences inside OpenSC to piggyback onto PKCS#11 for operations that will require special "tweaking" of the PKCS#11 application to implement support for something for what PKCS#11 might not be the most appropriate API. For implementing proprietary applications against a proprietary (even if open source, non-standard means "proprietary") library, a nonstandard API can be used as well. This is the place where libopensc (or interfacing with pkcs15-init) should be used. Maybe it would make sense to develop the example further, so that the attribute could be pulled together with some meaningful activity (like creating the key with the necessary flag) around it. The vendor specific attribute alone might not make much sense otherwise. [1] http://www.opensc-project.org/pipermail/opensc-devel/2010-March/013719.html On Jun 13, 2011, at 18:56 , Viktor Tarasov wrote: > 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? This description also sounds legit. You want to draw the parallel for CKA_NON_REPUDIATION ? -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
