On Tue, 2010-08-31 at 10:14 +0200, Viktor TARASOV wrote: > Andre Zepezauer wrote: > > 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? > > > > Can you develop, please? > Prkey-Encoder? One 'key reference' or 'algorithm reference' per key? > > > 1) The scenario you described would also be possible through a direct > > lookup of TokenInfo.supportedAlogrithms. > > > The algorithms supported by key is not the same as algorithms supported > by PKCS#15 card. > The first one, in general, is the sub-set of second. > > > 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. > > > It can be the cases when private keys are created (or key slot > allocated) before the corresponding certificate is imported > and without knowledge about the future usage of these keys. > For this reason and for the sake of simplicity, there are can be the > keys that are able to accept different algorithms -- 'general purpose' keys.
And after key generation you have to populate the information about the newly generated key (to be able to find this key later). In case of a p15 card you have to create the appropriate on card data structures. And now you could be in trouble. Because p15 allows ***exactly one*** algorithm per key to be specified. As stated in point 3) above, use CKM_RSA_X_509 for 'general purpose' keys. > The question is -- should PKCS#15 structure reflect the real key > attributes or only the 'useful' ones? > > > Looking at all these facts, I think a single reference per key should > > work fine in almost every case. > > > > It's this 'almost' that I'm a little bit worried about. > > > >> The same concerns security environment (SE) -- the number of algorithms > >> can be defined in one SE. > >> > > > > Haven't worked on this. > > > > > >>> Regards, > >>> Andre > >>> > > Kind regards, > 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
