Predicting problems with PKCS #11 as a Trust Store

[Rick van Rein]

Hello,

If I understand correctly, then one of the goals of p11-kit is to serve
as a trust store.  That use surprised me a bit, because PKCS #11 seems
too constraining for that use-case, unlike alternatives like LDAP.  May
I present my cautions, in the hope they are useful to you?

  * Useful about PKCS #11 is that it has well-defined storage formats
for X.509 certificates, but that won't help much with other key
infrastructures.  I defined a format for OpenPGP [1] but that isn't
standardised, it isn't widely supported, and so you cannot rely on it
being possible in general.  The same can be said about OpenSSH, DNSSEC,
and so on.  The only thing you could do for those is store the raw
public key -- that is, if a suitable format exists; I had a lot of
trouble squeezing SRP into PKCS #11 for example.

  * PKCS #11 can be setup for readonly access, but of course that is
hardly a unique property.  Also, don't forget that PKCS #11 is a
library, so mostly the protection would be "enforced" in the user's process.

  * Searches with C_FindObject() can be terribly slowly implemented,
through a linear search; I've seen that with expensive high-end HSMs. 
If you need to do this for each individual key you're hoping to match
then you're in for a treat!  A somewhat illogical aspect in the design
of the OpenDNSSEC Signer runs into this as well, causing a quadratic
load time and making the Signer work for hours to simply load the keys
for a few thousand zones.  PKSC #11 is first and foremost security
software, and not necessarily well-optimised.

  * PKCS #11 may present a snapshot image to its users, meaning that it
won't change the set of objects presented during a session.  Only after
closing the last session (effectively logging off) and opening a new one
(logging back on) can the most recent information be had with
certainty.  If you are aiming for a generic PKCS #11 token
implementation then you might be logging in more than you like -- and
more than you think makes sense.  (I know that you can also have a
Public R/O Session, that could bypass this problem.  Still, continuously
opening new sessions is not going to win you efficiency awards either,
especially with implementations that store a lot of state in a session.)

  * In general, PKCS #11 has no update mechanism, so caching to overcome
the previous two points is bound to lag behind at some point, leaving
you wondering how okay your public key store is.  You can make pragmatic
choices of course, but is it not a pitty to have that as a result of
choosing this particular implementation?

May I suggest an alternative instead of PKCS #11?  Use LDAP.  It is just
as capable of carrying X.509 certificates with annotations.  And I think
it is a good idea [2] to have LDAP servers for structured data such as
public keys under domain names anyway; this is something we are actively
working towards [3].  Using SyncRepl, you can be updated virtually
instantly.  And definitions for many public-key systems have been made
already; OpenSSH and OpenPGP are both covered, and you could easily add
your own if you wanted, without risking a conflict with other LDAP
users, and without the need to go through a standardisation committee :)


Sorry that my first post on this list is a long (and negative) advise. 
PKCS #11 is lovely, p11-kit is very interesting, but IMHO it would cause
probelms to use PKCS #11 as a trust anchor store.  I hope this input
helps to further develop the ideas!


Cheers,
 -Rick


[1] http://openfortress.nl/doc/spec/pgp-in-pkcs11/
[2] http://rickywiki.vanrein.org/doku.php?id=globaldir
[3] http://internetwide.org/about/solution.html