On Thu, Oct 29, 2009 at 10:38:15AM -0600, Gary.Morton at Sun.COM wrote: > On 10/29/09 09:50, Wyllys Ingersoll wrote: > >Will Fiveash wrote: > >>On Thu, Oct 29, 2009 at 02:42:22PM +0000, Darren J Moffat wrote: > >>> Wyllys Ingersoll wrote: > >>>>The problem I recall is that I think the SCA6000 requires login even > >>>>for > >>>>accessing public objects and "pktool list" without the logging in > >>>>resulted in no objects being found. > >>> Hmn, okay at least if I remove CKF_LOGIN_REQUIRED from softtoken > >>>that fixes the most common use case. So maybe leave pktool alone > >>>then. > >> > >>It also sounds like the SCA6000 is broken in regards to requiring login > >>to access public objects. > > We don't support public token objects at all.
It'd be nice to have a flag for that. CKF_LOGIN_REQUIRED isn't it, just the closest to it. There are several things we can do here: a) make softtoken not set CKF_LOGIN_REQUIRED (Darren agrees, and, I think, we all do); b) make SCA6000 not set CKF_LOGIN_REQUIRED and explicitly not support public objects (if you try to create one, you get an error); c) make pktool(1) not prompt for PIN when searching for public objects (users trying to list SCA6000 objects will see none, and will have to know to ask for private objects); d) make pktool(1) not prompt for PIN when searching for public objects unless some cli option is given that tells it to do the login anyways; e) make the PKINIT pre-auth plugin search for public objects without first doing a C_Login(), and then return an error / skip PKINIT if there are no suitable certs in the token; f) same as (e), but with a krb5_get_init_creds_option / krb5.conf option to force login (so one can store certs as private objects, for privacy protection reasons). I think we all agree on (a) and (e). (f) would be nice. I'm not sure if (b) makes sense. I like (c) and (d), but we might not reach consensus on those. Nico --
