Will Fiveash wrote: > On Wed, Oct 28, 2009 at 05:24:42PM -0400, Wyllys Ingersoll wrote: >> Will Fiveash wrote: >>> On Wed, Oct 28, 2009 at 05:14:27PM -0400, Wyllys Ingersoll wrote: >>>>>> The problem is that when you query the token and check the flags, >>>>>> the token has no way to know if you want to read the private or >>>>>> public areas so it cannot have any logic to indicate whether or >>>>>> not to set the login bitfield in the flags. pktool defaults to the >>>>>> safest method, which is to prompt always (we ran into trouble >>>>>> when we did not do this on some devices other than softtoken). >>>>> Looking at the spec there is support for different session types >>>>> including the default of CKS_RO_PUBLIC_SESSION. Why can't the token use >>>>> this to determine what the app wants to read and whether login is >>>>> necessary? >>>> That sounds like it should be possible but I haven't looked at the code >>>> to check. You should be discussing this with the EF iteam or >>>> crypto-discuss at opensolaris.org . >>> I've been cc'ing crypto-discuss at opensolaris.org on this thread. >> >> >> C_GetTokenInfo does not take a session handle as an argument, so the >> token has no idea if you will be opening a readonly public session >> or not and thus cannot tailor the info that it gives you. > > Fair enough but given this from the PKCS#11 v2.20 spec: > > After it opens a session, an application has access to the token?s > public objects. All threads of a given application have access to > exactly the same sessions and the same session objects. To gain > access to the token?s private objects, the normal user must log in > and be authenticated. > > it seems like our implementation of softtoken, which has C_GetTokenInfo > setting CKF_LOGIN_REQUIRED regardless of the type of object that is > going to be accessed, is violating the spec. Should I open a bug > against the pkcs11_softtoken.so? >
I'm not sure. Just setting the CKF_LOGIN_REQUIRED flag could be interpreted to mean that in "some cases", you must login. It might be a bug if CKF_LOGIN_REQUIRED is NOT set but yet the token still requires a login in some situations. I've forgotten what problem you are trying to solve now. What is it you are trying to fix and is there another approach to take? -Wyllys
