Darren J Moffat wrote: > Glenn Barry wrote: >> (A few months ago I looked into the feasibility of replacing the >> openssl plug-in code w/kmfapi and I sent a version of this in email to >> some folks and now would like to circulate it wider -- and our MIT >> Kerb 1.6.3 resync is near done so we need to decide how to procede.) >> >> >> Going into this project, I was shooting for kmf-purity -- that is, try >> to replace the openssl routines totally (or at least the x509 openssl >> api) with kmfapi. >> >> But now that I've seen the pkinit routines that construct the AS >> request with signed data using the pkcs7 (openssl) api, that goal >> would be difficult because pkcs7 uses the x509 api heavily. >> >> So here's what I'm thinking now. Leave the x509 code as-is for the >> current MIT kinit/krb5.conf cert options: >> >> FILE:file-name[,key-file-name] >> DIR:directory-name >> PKCS12:pkcs12-file-name >> PKCS11:[module_name=]module-name... > > How is PKCS11 provided if KMF isn't used ? Does the MIT kerb code call > PKCS#11 C_* interfaces directly ? > > For Solaris we shouldn't need to allow specifying the PKCS11 module it > should be /usr/lib/libpkcs11, so I'd just make that the default (either > in the code if possible or in our default krb5.conf file).
Default maybe, but you still should allow the customer to provide their own pkcs#11. I am concerned about smart cards, and smart cards that Sun may not support. Being able to use OpenSC which can also be uses on Linux, Mac, Solaris and Windows is very reassuring, as new smart cards are added all the time. > >> And if there is demand (customers pls chime in) we add a new one for nss: >> >> NSS:<how-ever-one-identifies-nss-cert> > > I see zero need for that capability in the short term particularly if > PKCS#11 support is available, but I'd be happy to be shown a use case > for it. > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
