On Fri, 2010-09-17 at 10:02 +0200, Viktor TARASOV wrote: > 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.
Hello Viktor, if someone wants to use opensc for personalisation, then everything should map fine to the on card data structures. In another post [1] you gave a promising hint, that led me belief that 7816-15 has advanced in this direction (compared to pkcs15). I will check this and if it is true, then the solution proposed by you would be a natural fit. [1] http://www.opensc-project.org/pipermail/opensc-devel/2010-September/014920.html Regards Andre _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
