On Mon, 2010-11-01 at 17:43 +0000, Mr Dash Four wrote: > Many thanks for your input Andre! Comments below: > > >> Right, so I presume if I want to see whether a login is required I still > >> have to use "pkcs11-tool -O" and check whether the object I am > >> interested in is shown (and its 'private' flag is set). Is there another > >> (more straight-forward) alternative to that? > >> > > > > Maybe there is one. Since you are looking for a specific object, you > > have to store the ID somewhere and searching for it at execution time. > > Probably you can store the information on login requirement too. > > > The idea I've had is this: I needed data object stored in such a way > that it allows retrieval of its data using two different methods: with > or without login to the token. The method provided in OpenSC/OpenCT is > to store a data object specifying either "--application-id" or > "--application-label" attributes and also including the "--auth-id" > option (when login is required) or without specifying such > authentication ID when login to the token is not required. That is good > enough for me and what I am currently developing. > > From the normal user's point of view they need to be able to retrieve > the token data using 3 different 'modes': 1) 'auto' (in which case the > module I am developing will have to be clever and 'probe' to see whether > login is required); 2) 'public' - force reading the token data without > prompting for a pin (in which case if the object is stored with the > "--auth-id" option that will obviously fail); and 3) 'private' - force > login to the token even if the data object is stored without "--auth-id" > option (and that is where your latest patch comes in handy!). > > Options 2 and 3 are pretty straight-forward, no question. > > Option 1 is a bit tricky as I would need to somehow 'probe' to see > whether the token has its 'private' flag set. As I am writing this, I am > away from my testing harness and cannot remember whether I could see the > 'private' flag of the data object just by executing "pkcs11-tool -O" - > i.e. without logging in to the token - or whether the data object is > completely hidden from view - will test this later tonight!
It's completely hidden, for sure. Without login, you cant decided, if there are private objects on the token or not. > The guide you were kind to enclose in your previous post suggests that I > may not be able to view this at all, in which case I have to assume that > if by executing "pkcs11-tool -O" with specifying either > "--application-id" or "--application-label" I do not see such object I > have to assume that it is private (or does not exist!) and therefore > login may be required. Correct. > I have to think about what other/better alternatives I have as executing > "pkcs11-tool -O" and filtering the output seems to me a bit clumsy. You could write public readable meta data to the token. I.e. a object where all the IDs of private objects are stored. But this requires synchronisation on every create/delete operation. @ALL: Seems that PKCS#11 is a little bit odd in that direction. BTW, this could be the reason, why NSS asks for a PIN even before searching for certificates. In my opinion it should be feasible to introduce a non standards flag in opensc-pkcs11, that is named something like "CKF_DONT_HIDE_METADATA". That flag could be set in CK_C_INITIALIZE_ARGS and passed to C_Initialize(). If initialised that way, opensc shows meta data on private objects even in public sessions. Every application (not only pkcs11-tool) could read ManufacturerID from CK_INFO. If it is "OpenSC", then set that flag. Please do comment on. > > Handling of private objects is defined in [1]: > > * table 6 at page 22 and > > * page 137 [2] > > > > > > [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf > > > > [2] Quotation from PKCS#11 v2.20: > > "The object search operation will only find objects that the session can > > view. For example, an object search in an "R/W Public Session" will not > > find any private objects (even if one of the attributes in the search > > template specifies that the search is for private objects)." > > > Many thanks again - very helpful! > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
