Andre Zepezauer wrote: > 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. >
I like a lot this line in pkcs15 specification: "... -- For future extensions ". In the real life there can be more then one algorithm defined for the key. > As stated in point 3) above, use CKM_RSA_X_509 for 'general purpose' > keys. > Also, in the real life the key can have more then one algorithm, but not all of the algorithms supported by card. For that reason it cannot be considered as 'general purpose' one. I think that pkcs15 should expose the card capacities in a most close manner, and an array of the references to the algorithms supported by key, introduced into the 'sc_pkcs15_prkey_info', would be quite flexible solution. >> 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 >> > > > -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
