I think this scheme has a long way to go before it becomes
generally useful. An obvious shortcoming in the app-powered
world we live in is that an issuer has no way restricting keys
to certain trusted apps.
Such a scheme will probably be included in future versions of
Windows, iPhone and Android. At least this is what I read
"between the lines" when talking to some of the architects :-)
Anders
On 2011-04-25 12:34, Martin Paljak wrote:
> 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
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
