On 10/06/08 16:36, Valerie Bubb Fenwick wrote: > 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
Hi Valerie - I agree, its difficult to come up with a fool proof way to automatically sort providers especially given that they each may be better at certain things. Having an admin command to manually prioritize them could be a nice feature and at least better than having to use the hammer of "disable". -gary