On Mon, 6 Oct 2008 Gary.Morton at sun.com wrote: > On 10/06/08 14:47, Nicolas Williams wrote: >> On Mon, Oct 06, 2008 at 01:44:34PM -0700, Anthony Scarpino wrote: >>>> Note that sc_pkcs11_get_mechanism_list is called with p11card=0x0. >>>> Ticket #181 gets around this. >>>> >>>> I have not tracked down the sshd and login problems yet. >>>> I am assuming that is related to no mechanism list. >>> Just a wild stab here.. If metaslot is enabled, it will retrieve a list >>> of mechanisms from all the providers. You may try disabling metaslot, >>> 'cryptoadm disable metaslot', to see if that helps.. >>> >>>> Note that sshd should not be using the console user's >>>> smartcard for any crypto! >>> OpenSC and the smartcard are providers in PKCS#11. If it is providing >>> crypto to the system, it is available to be used. Granted no one would >>> ever want a smartcard to do the crypto ops, but there is nothing in >>> PKCS#11 to stop it.. >> >> Is there any way to provide a provider preference order so that >> smartcards are never used for crypto other than in relation to >> non-extractable keys? > > Nope. There is an open RFE (6419307) I created for similar reasons a > while back.
Hi Gary - We've talked about this for a long time, specifically for smartcard concerns. it's tricky to do really intelligent sorting of devices, but we talked about allowing providers to set a default "weight" like "1" for preferred tokens and "3" for slow ones, that could possibly user configurable. I think it would be handy, because right now the only way to keep a provider from being selected ever would be to disable it. Valerie -- Valerie Fenwick, http://blogs.sun.com/bubbva Solaris Security Technologies, Developer, Sun Microsystems, Inc. 17 Network Circle, Menlo Park, CA, 94025.
