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 _______________________________________________ p11-glue mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/p11-glue
