Salz, Rich wrote:
>
> >Maybe a better way of stating my intent would've been to say
> >that I'd like to
> >provide the cross platform interface to make a PKCS#11
> >interface easier.
>
> sigh. Does the world really need another token interface?
> (As opposed to PC/SC, PKCS11, CDSA, etc.)
>
Maybe. PKCS#11 is probably the nearest to OpenSSLs requirements but it
has various annoying "quirks", particularly its key and certificate
database handling.
There is no standard to handle CRLs: problem number one.
Another example is "to login or not to login". Suppose you are searching
for a private key corresponding to a certificate. Under PKCS#11 the
certificate might be a private object or a public object. If its a
private object it wont even be visible without a login. So if OpenSSL
had a bunch of PKCS#11 interfaces it was talking to it might have to
login to *all* of them just to give a "not found" error at the end.
Netscape works round this by having an extra "out of band" attribute in
each PKCS#11 token called "publically readable certificates", if you set
this then it doesn't log in when it looks for a certificate.
Also PKCS#11 is far too hefty a beast to handle very simple cases. I
wouldn't want to force someone to write a full blown PKCS#11 interface
for something simple like a PEM or PKCS#12 file reader.
The list of attributes is also incomplete for this kind of application.
There is no "email address" attribute and no official trust setting
attribute.
At its simplest level IMHO we need some way to turn an ASCII string
like: "somehardware:steves-key" into a "driver call" that then loads in
the right key and prompts for any passwords or insertion of cards. All
this hidden from the application.
At a more complex level there should be a way to search for keys,
certificates and CRLs using various attributes and also add, modify or
delete those already there.
> >Although there are some things in PKCS#11 that I strongly
> >disagree with, like pg. 111 of the 2.1 PKCS #11 draft:
>
> I don't think you understand the excerpt that you quoted.
> It doesn't prevent threads -- and in fact the current PKCS11
> is multi-threaded, isn't it? -- it just says that every
> function is atomic. In other words, the card won't be left
> in an inconsistent state. That's very important and very
> useful.
What Chris is saying is that certain crypto hardware (e.g. nFast boxes)
can operate much more efficiently if they are handling several requests
in parallel.
Under PKCS#11 the only way to do this is to have one thread per crypto
operation. There was a parallel session interface in PKCS#11 at one
point but it is now been removed. The problem is not that PKCS#11
prevents threads just that it forces you to use them if you want to run
several crypto operations in parallel.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
