(oops: forgot to CC to list :-)
----Mensaje original---- De: jons...@terra.es Fecha: 25/04/2011 14:30 Para: <mar...@martinpaljak.net> Asunto: Re: [opensc-devel] OpenDNIe project is now ready for public test > 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. You're right, but in the Real World very few apps take care on these items as they should.... For instance: OpenOffice doesn't ask user approval for signing documents; ever worse: doesn't check "key usage" flag on the selected certificate. In the testing process of DNIe I've found too many apps that silently sign documents... All these "funny" apps made me change my opinion about "user consent".... (Notice that OpenDNIe does not ask user pin: only uses popup windows to ask confirmation for the signature procedure, just before sending proper APDU) > 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. So your proposal is create a separate file to store all user consent operations, and call them when required. I agree: that's the way to work > * What to show to the user (and how). This includes i18n. i18n is not only related to user consent: any xxx-tool are also candidates. Afaik Belpic card has also same i18n issues (btw no i18n ticket found) > * 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. A problem arises in Linux: dependancy with external libraries at compile time. I've solved it in linux by using pinentry as an external tool, without libassuan, and declare in config file how to process and wich program to use > 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" 7 - "You'are about to emit a digital signature. Please confirm operation" Juan Antonio
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
