On Mon, 2010-11-01 at 21:35 +0000, Mr Dash Four wrote: > > It's completely hidden, for sure. Without login, you cant decided, if > > there are private objects on the token or not. > > > True, after testing it earlier there is nothing there to see - it is as > if the token does not exist (rightly so, I think). > > > >> 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. > > > Actually, having thought about it again, I think it makes sense that > without proper authorisation there shouldn't even be a hint that this > object exists. In which case I will have to implement just two modes - > 'public' or 'private' - and leave it at that. > > As an aside question: when I create a data token I could specify > "--auth-id" (I normally chose "--auth-id=01" if I need that data token > to be private), which, to me, implies that I could register more than > one "auth-id".
Do you use auth-id with pkcs15-init? If true, then you could specify more than one. Each auth-id correlates to an authentication object, which in turn defines a protection domain and has its own PIN. But the PKCS#11 API maps each protection domain to a different token. Compare output of "pkcs15-tool -D" and "pkcs11-tool -L". _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
