On Tue, 2010-12-14 at 13:07 +0200, Martin Paljak wrote: > Hello, > On Dec 14, 2010, at 11:11 AM, Andre Zepezauer wrote: > > to make a long story short, there is an (easy?) way to get ride of the > > whole flag magic. > > > > It would require more attention on TokenInfo.SupportedAlgorithms and > > implementation of CKA_ALLOWED_MECHANISMS. > It is not implemented by OpenSC currently. But is it used by common PKCS#11 > applications (like NSS?)? > > > > That's it. When these to > > mechanism are in place, things would still happen auto-magically. But in > > a more appealing way. > > > > Facts: > > > > 1. CommonKeyAttributes.algReference and > > PrivateAbcKeyAttributes.keyInfo.reference > > These two fields are supposed to reference one or more algorithms in > > TokenInfo.SupportedAlgorithms. For a visual representation of the > > information contained in TI.SA see [1]. For descriptions have a look at > > the specs. > That looks visually appealing indeed :) > > > > > > 2. With the above information an implementation of > > CKA_ALLOWED_MECHANISMS is trivial. > > > > 3. If CKA_ALLOWED_MECHANISMS is working, then the calling application > > can use C_SignInit only with mechanism actually supported by the given > > private key. > Nevertheless, at least proper mechanisms could be enforced early in the > PKCS#11 module instead of returning with questionable results from > src/libopensc. > > > > 4. The buffer given in C_Sign could pass through down to the driver/card > > because we know that the key in question supports the requested > > mechanism. > > > > 5. Additionally the value of AlgorithmInfo.algRef should be passed to > > set_security_environment. It could be used in tag 0x80. Or in the case > > of PIV, as P1 or P2 in GENERAL AUTHENTICATE. > > > > That may sound strange at first, but all these pieces fit nicely > > together. > Without seeing the code, it at least reads as OK. > > Right now I guess that the stripping of input data, coming from an > application (meaning that the calling application will expect the data to be > exactly the same when verifying the signature) is wrong in pkcs15-sec.c [1]. > As there are no other fields that would control the absence (or addition in > the card) of DigestInfo prefix, it does not make any sense to me. Thoughts > anyone?
It really does make sense for cards, that will reattach the prefix internally ;) > What could be the "ISO version" of SHA1 + PKCS#1 + RSA Stef was referencing > to in the e-mail I referenced in this thread? > > [1] > https://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-sec.c#L294 > _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
