Hello,

On Thu, Feb 10, 2011 at 20:46, Juan Antonio Martinez <jons...@terra.es> wrote:
> As you know, I've been working last 4 month with people at Cenatic[1]
> in two areas:
>  * Specific DNIe user-interface requirements (i18n,user consent)
>  * Porting some common code from dnie files to opensc
>  * DNIe "particularities" ("user consent" popup, SM, OpenSSL)

About "User Consent" AKA "popping up notice windows about what the
user is about to do" as well as ticket #232 [1].

I still believe that it is mostly politics to delegate responsibility
:) What it tries to "protect" from or inform the user of, the chosen
technical mechanism is IMHO far from being enough. From purity vs
practicality point of view, in the context of PKCS#11 applications for
example, it would be the responsibility of the application to display
application specific notices if the signature to be given is in fact
given with an application that is meant for giving digital binding
signatures. For example, NSS thinks that non-repudiation keys are OK
for web authentication, giving a popup about legally binding
signatures if the end result is a SSL session is not appropriate.

Nevertheless, the feature has usage scenarios (like fulfilling
questionable policies). Some things to consider:
 * Where to implement it. Current implementation in a card driver is
not the right place maybe, if the driver is used from a Tokend, a
PKCS#11 or minidriver, GUI availability can vary. Thus it should be
possible to control it based on an "interface driver" (PKCS#11 vs
minidriver for eample) rather than card driver.
 * What to show to the user (and how). This includes i18n.
 * Integration with the rest of the platform. I really like the
concept of "trusted windows" or "stuff that is controlled by the
system and harder to fake for malware" like the Windows UAC. OS X and
Windows have mechanisms for this, although I'm not sure if/how
difficult it is to jack into them. On Linux, maybe GnomeKeyring can
provide some help (for Gnome desktops)? If the feature is to be
enabled, it would probably be used in a desktop environment, so tuning
for a smooth and integrated experience would be of great value.

I can figure out at least these different popups:
 1 - "Legal warning" + plaintext PIN entry
 2 - "Legal warning" + "Please enter PIN on pinpad"
 3 - "Please enter PIN on pinpad" message
 4 - Faked secure PIN entry in PKCS#11 driver and "Please enter PIN"
window for plaintext PIN
 5 - "Please re-enter PIN" window, as described in #232
 6 - "Plaintext PIN entry forbidden by policy"


[1] http://www.opensc-project.org/opensc/ticket/232
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to