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?
Hello Viktor, first of all some clarifications. With prkey-Encoder I mean the function, which takes a sc_pkcs15_prkey_info as it's input and outputs the corresponding asn1 byte array. And all the references I was talking about are 'algorithm references' on prkeys. Improving opensc that way, that it has a greater awareness of the pkcs15 structures on cards is a goal of mine. If this is the development you ask for, then I could do it. A second goal is, to use these cards according to the information found in the pkcs15 structures (on card). In the long term this will hopefully let to a plug and play experience, where a completely new (but still initialised) card will instantly work with opensc. Without any hacks and emulations of course. That's all pkcs15 is about. Isn't it? What's your opinion on that? Regards Andre > > 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. > 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
