Predicting problems with PKCS #11 as a Trust Store

[Stef Walter]

On 04.03.2016 23:08, Rick van Rein wrote:
> 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?

Certainly. If you're interested in the p11-kit trust implementation,
it's been in use on Linux (Fedora, RHEL, OpenSuSE, Debian, and others)
for a while now. You could check out those operating systems to see
p11-kit at work.

In addition NSS as used in Firefox has been using PKCS#11 as a trust
store for at least a couple decades now. The NSS PKCS#11 objects are
also exposed by the p11-kit trust module as a compatibility measure.

>   * 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.

Indeed. I contributed a bit in the PKCS#11 TC on the topic of
extensibility. Although to be fair, object based extensions haven't.

>   * 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.

Right. Although you'll find that the p11-kit trust implementation is
obviously optimized better than a linear search (at least last time I
touched it, heh).

>   * 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.)

Right, although that's implementation specific. The p11-kit trust
reference implementation achieves realtime updates, not snapshotted. You
can (for example) see changes made to the trust store reflected
immediately in the behavior of a running Firefox browser instance.

>   * 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. 

Makes sense. In fact one could layer one on top of the the other for
compatibility if necessary. If you're interested in working on this I
wouldn't be against it.

In fact open source projects like FreeIPA would be a great place to work
on prototyping this and building it into an actual ready to use solution.

> 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!

No problem at all. Thanks for the post.

Stef