On 6/15/2011 4:28 PM, Nikos Mavrogiannopoulos wrote: > On 06/13/2011 11:11 AM, Stef Walter wrote: >> On 06/10/2011 07:08 PM, Martin Paljak wrote: >>> On Jun 10, 2011, at 13:11 , Stef Walter wrote: >>>> After sleeping on this idea, I realized it won't work in certain >>>> cases. In particular when the key has CKA_ALWAYS_AUTHENTICATE >>>> and requires C_Login with CKU_CONTEXT_SPECIFIC. >>> This is hardly the case with SSL. >>> >>> CKA_ALWAYS_AUTHENTICATE in OpenSC context for example is only set >>> for keys that require "user consent" or usually are used for >>> "nonrepudiation". Most cards I've seen can use authentication keys >>> once the cardholder is verified until the card is reset or >>> removed. >>> >>> Using such card with a pinpad reader would be impossible for web >>> authentication, you'd be typing the PIN most of the time
The card may have two certificate, one that is unlocked once by the browser and one using CKA_ALWAYS_AUTHENTICATE used for signing e-mail. In that the intent of the card issuer forcing CKA_ALWAYS_AUTHENTICATE and setting the policy of using a pin pad reader, is designed to have the user enter the pin. So middle ware developers have to live with policy. >> Since the PKCS#11 URI's say that the pinfile attribute of the URI >> can be determined by the application, we can build something simple >> in p11-kit and register callbacks so that one component (in the same >> process) can provide the pin for another (like gnutls). > > I didn't like the pinfile attribute of pkcs11-urls much, because its > semantics are undefined. I see it as an option that could cause > compatibility issues between libraries using URLs. That's why I have > ignored it so far. Are there other alternatives to solve the issue at hand? This might not be answering your direct question, but is relevant to the handling of PINs. One example of using a pin pad reader with a complicated callback mechanism is with login at the console. It involves Gnome or other window manager, PAM, PAM modules like pam_krb5, the Kerberos libs, openssl, openssl_engine, engine_pkcs11 and OpenSC's PKCS11, and pcsc. PAM has conv routines to allow messages, prompting, and input. Kerberos has its own callback routines, as well as the openssl engine ui_method. These can all work together to to pass back a message to the user to use the PIN PAD to enter the pin. This is no input passed back by the callbacks, just the message to the user. Since PAM was designed to start with a user/password, even before determining that a smartcard might be used, the password may be entered as a blank. (It will not be used later.) > > regards, > Nikos > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
