Lutz Behnke wrote:
>
> Dr Stephen Henson wrote:
> >
> > There is no standard to handle CRLs: problem number one.
> Why do CRLs have to be on a hardware token?
PKCS#11 doesn't necessarily even involve a hardware token, there are
several software only implementations.
There are two related uses PKCS#11 could be used for in OpenSSL. As a
standard for crypto operations and as a standard for a key and
certificate database: basically a sophisticated version of X509_LOOKUP.
When I say "database" I don't necessarily mean allowing keys to leave
the token: just being able to set up an EVP_PKEY (currently RSA_METHOD)
structure so the key can be accessed transparently.
Most of my message refers to this this latter use. As such it would
need a standard way to store and retrieve CRLs.
> >
> > 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.
Suppose I have an S/MIME message, it refers to the recipient as an
issuer and serial number: there will probably be several recipients, one
being the sender. I need to lookup a certificate (or private key) by
issuer and serial number and at least one lookup will fail.
While the lookup is taking place I need to know if I've looked through
all certificates on a given token: the only way to be sure that you have
seen all private key certificates (there may be none) is to login.
If the password is wrong then it might not be totally harmless: some
smartcards are unusable after three incorrect PIN entries.
> >
> > 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.
Thats only certificates you have personally loaded or created. You have
no way of knowing whether already existing certificates are private. You
can do the Netscape trick of allowing an option that says "this token
contains no private certificates" but you can't do this with PKCS#11
alone.
There are some cases where you must have private certifiate objects:
consider a PKCS#11 interface to a typical PKCS#12 file. When you "login"
you supply the PKCS#12 file password and can access all the private keys
and certificates: without the password you can't see any of 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?
As a general standard for a key and certificate database. There are some
PKCS#11 tokens that store their keys and certificates in PKCS#12 files
they are a kind of "software token".
> >
> > 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.
An email address (or several) would be a certificate attribute, or
possible a public key attribute. Imagine you want to send someone S/MIME
email and all you have is the email address.
Putting the email address in the DN is considered bad practice. There
can also be several email addresses and the correct place is the subject
alternative name.
Anyway the point is you can't search for a certificate object based on
email address, you have to search all certificates. If the database is
big this could be very inefficient.
> >
> > 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.
Indeed it does. Loading doesn't necessarily mean being able to read all
the key components: just being able to use it in a fairly transparent
fashion. Hardware will (for RSA keys) set up an RSA_METHOD to redirect
the private key methods and it might load the public key components to
allow the key to be used to sign a certificate request for example.
> >
> > 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.
>
What Chris needs is a way to run several operations in parallel in the
same thread of the *same application*. Thats where PKCS#11 is a problem.
Imagine an single SSL application that serves several connections in a
single threaded fashion using a select() loop and talking to some crypto
hardware that can handle several simultaneous requests 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]
