On Mon, 13 Jul 2009, Wyllys Ingersoll wrote: > > Since the KMF bits are unchanged, then my review stands - LGTM. >
Thanks, Wyllys. > I was thinking about the KMF/PKCS11 problem a bit - would it help > if we had a specific KMF plugin that was only pkcs11_softtoken? we could > dlopen sofftoken directly instead of libpkcs11. > > The KMF framework would also have to be modified to dlopen softtoken directly > for those operations where it requires some pk11 access instead of dynamically > linking with pkcs11. That was a design option I had tried, but the problem is all of the PK11 functions in the framework itself. If they all resided in the plugin (forcing things like pktool to go through the plugins, which I don't think is a bad idea), then it would be a much easier more straight forward solution than what I have. Unfortunately, when I tried unraveling this, after a few hours, I realized I did't have the right expertise to do this correctly or in a timely manner. The big problem is that a consumer like the elfsign command would sometimes want libpkcs11 as the token and sometimes want pkcs11_softtoken as the token. The PK11 calls that live in the framework itself made that very difficult (impossible?) to do, without some rearchitecture of KMF, which is clearly out of my project scope :) > I agree these changes are out of scope for your project, but if we were > to take them on as an RFE for KMF, would it help down the road or is this a > case where once you have a solution then the problem is effectively "solved" > and won't be changing again for a while. > > I don't think it is really all that much work in KMF. The plugin is already > there, it just has to dlopen softtoken instead of libpksc11 and make the > function calls a little differently. If you had the time to do so, it would certainly be worthwhile. Making KMF less dependant on a specific PK11 implementation is a good thing, in my opinion, which would make the entire framework more robust. If you look at my current code changes, it would be very easy to "undo" them and replace them with a rearchitected KMF. Valerie -- Valerie Fenwick, http://blogs.sun.com/bubbva/ @bubbva Solaris Security Technologies, Developer, Sun Microsystems, Inc. 17 Network Circle, Menlo Park, CA, 94025.
