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