Hi,
Richard Levitte wrote: > >From: Eric Laroche <[EMAIL PROTECTED]> > >Eric.Laroche> The token object specification format has been widened. >Eric.Laroche> It is now more powerful and more intuitive, using >Eric.Laroche> name/value pairs, e.g.: >Eric.Laroche> "pkcs11:library=cryptoki&tokenlabel=eric&objectlabel=two&dologin=true" > > Interesting. I've one question though: is the choice of library > really tied to the key? I assume we're talking about routine > libraries here and not some other kind of library that I don't grasp > yet. Sorry, the key specification sample may be, again, for brevity, a bit misleading. The 'library' parameter is not intended to specify the library interface (which must be the PKCS#11 API), it specifies the vendor library's location. Typically one would specify it by an absolute path name, e.g. "library=/opt/Eracom/lib/libcryptoki.so" or "library=/opt/SUNWconn/sunsecure/lib/libcryptoki22.so". This allows us to access keys on different vendors' hardware tokens at the same time (i.e. using different hardware simultaneously). [The sample simply took, for brevity, advantage of OpenSSL DSO abstraction being able to expand 'cryptoki' to 'libcryptoki.so', and find that one, provided that LD_LIBRARY_PATH is properly set.] > If "library" is about routine libraries, have you noticed the > engine command definitions that have been implemented in the current > development of OpenSSL? Yes, I am aware of the OpenSSL engine interface. Our code applies quite similar mechanisms of feeding 'configuration' information (name/ value pairs) from application code. However, the engine command definitions affect the whole engine setting, whereas our configuration affects an abstraction called (key) 'object specification'. Each key or certificate may have quite different settings concerning where to accomplish encryption and which password callbacks to be applied, etc. The PKCS#11 object specification / configuration seems to me to be a different concept compared to the engine configuration. However, the PKCS#11 interface may be seen as a 'PKCS#11' engine. > BTW, are you working against 0.9.7-dev or 0.9.6b [engine]? The former > is prefered for anything new (and provides a much larger range of > supported algorithms and methods). We're developing against recent 0.9.7-dev snapshots. > Now, for another issue: I haven't quite followed the sequence of > events so I'm not completely up to date here. There was a time when > there were two persons approaching us with a PKCS11 engine each, and I > suggested they join forces. Is this a result of such a join? I'm > sorry that my memory doesn't serve me better on this, and I have had a > hard time finding the info I need to know how things have developped. This is intended to be a first step from our side towards a joint PKCS#11 code base. Our code needed some cleanup and better abstractions, which has been done with this version. Right now, we're in contact with Eracom, which provided PKCS#11 code in july and september. Best regards, Eric ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
