Dr Stephen Henson wrote:
>
> There is no standard to handle CRLs: problem number one.
Why do CRLs have to be on a hardware token?
>
> 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.
In theory this is a problem. But I have to query the user for a password
anyway if the key is protected. And if the password is wrong for a given
token you will simply not find the object you are looking for.
>
> 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.
This does not need a special Netscape handling. You simply do not mark
the
Certificates privat when loading or creating them. Then you never have
to log in to see or retrieve them.
>
> 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.
Again I beg the question what use PKCS#11 has in a 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.
Which object should hold the e.g. email addr? The keys on the token hold
the DN, thus the email-addr as well.
>
> 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.
Loading from where to where? The keys might never leave the hardware,
and
the interface needs to reflect this.
>
> 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.
No it does not. You simply attach multiple applications to a single
token.
An application in this context means that you have seperate process. If
the token does some magic shared-mem or pipe stuff or similar, it has to
hide this from the application. How Objects are visible between
applications
is described in the standard.
I have been doing this with a IBM Smartcard when using Communicator
and their own management tool at the same time, on the same card.
I makes Communicator crash when it suddenly looses a key, but that is
a different story.
mfg lutz
--
*******************************************************************
Lutz Behnke Tel.: 040 / 766 29 1423
TC TrustCenter for Security Fax.: 040 / 766 29 577
in Data Networks GmbH email: [EMAIL PROTECTED]
Am Werder 1
21073 Hamburg, Germany
S/MIME Cryptographic Signature
