Predicting problems with PKCS #11 as a Trust Store
stef-list at thewalter.net
Tue Mar 8 08:05:26 UTC 2016
On 04.03.2016 23:08, Rick van Rein wrote:
> 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  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  to have LDAP servers for structured data such as
> public keys under domain names anyway; this is something we are actively
> working towards . 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.
More information about the p11-glue