On Mon, 2010-08-30 at 17:50 +0200, Viktor TARASOV wrote: > Hello, > > > Andre Zepezauer wrote: > > Hello, > > > > attached is a patch which makes it possible to explicitly request > > specific algorithms for the cryptographic operations. The advantage is, > > that if the token provides sufficient information about itself, then the > > driver is not required to do any guess work. Which in turn could result > > in a more reliable operation of libopensc. Furthermore there could be > > positive effects in terms of compatibility with tokens not initialised > > by opensc. > > > > My recommendation is to test/improve this patch in an experimental > > branch or something like that. The reason for this is, that > > ALG_REF_PRESENT is not in use since revision 177 and I assume a lot of > > drivers to misbehave or crash at first. > > > > Few remarks about your patch. > > Private key can be used with more than one algorithm. > So, IMHO, in the 'sc_pkcs15_prkey_info' it's better to have some array with > the references to the crypto algorithms supported by PKCS#15 card (and > defined in tokenInfo).
Not a good idea, I think. Because the sc_pkcs15_prkey_info structure should also be the input of the prkey-Encoder. Remember that the standard allows only one reference per key. If the encoder gets an array of references, then all references of this array must be dropped except one. Which one? 1) The scenario you described would also be possible through a direct lookup of TokenInfo.supportedAlogrithms. 2) Another point to mention is, when using X.509 certificates the algorithm to use is fixed by the certificate. For example: "SubjectPublicKeyAlgorithm := PKCS#1 SHA-1 With RSA Encryption" Because X.509 is predominating at this time, there is little use for multiple algorithms per key. 3) And there is the CKM_RSA_X_509 algorithm, which allows for every kind of padding and hashing with a single key. Looking at all these facts, I think a single reference per key should work fine in almost every case. > The same concerns security environment (SE) -- the number of algorithms > can be defined in one SE. Haven't worked on this. > > Regards, > > Andre > > > > Kind wishes, > Viktor. > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > opensc-devel mailing list > > opensc-devel@lists.opensc-project.org > > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
