Le 14/06/2011 09:09, Martin Paljak a écrit : > 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 :)
Excellent resume. > 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. Yes, the primary purpose of the specific CKA_ attribute is to supply nonRepudiation flag when creating new key. When using existing key, the CKA_ attributes are (should be) not taken into account. > 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. Douglas proposed to associate the CKA_ALWAYS_AUTHENTICATE together with CKA_SIGN attributes on the PKCS#11 side, with the 'nonRepudiation' flags on the PKCS#15 side. Imho, it's legitimate solution -- 'ALWAYS_AUTHENTICATE' is quite close to the 'nonRepudiation'. Another, probably the most neutral solution, is to transfer to the card specific part the decision to associate (ALWAYS_AUTHENTICATE & SIGN) with nonRepudiation. >> 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 ? Yes, that was my intention. Kind regards, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
