On 10/25/2012 1:49 PM, Martin Paljak wrote: > On Thu, Oct 18, 2012 at 9:48 PM, Douglas E. Engert <deeng...@anl.gov> wrote: > >> So until FF and TB get the fixes, OpenSC-0.13.0 adds a new option to >> the opensc.conf file to cache the pin to accommodate older applications. >> >> pin_cache_ignore_user_consent = true; >> > > Just a suggestion-question: OpenSC behavior in not caching the user > consent PIN is logically correct, so why not disregard the user > consent bit instead on the PKCS#15 object level?
Part of the problem is long lead times for deployment on both OpenSC and applications. OpenSC is far ahead of the applications, and other PIV/CAC specific pkcs#11 implementations too. The support for CKA_ALWAYS_AUTHENTICATE has been talked about with Mozilla since 2006, 6 years, and code changes to support that have been around for a year and a half (or so) and only this year have made it into the NSS CVS. Its still not clear when the changes will be in TB and FF. But when they do get deployed, thing will work as expected. My Oct 18 note was in response to James Southwell's questions on the MUSCLE list dealing with this same issue. By using OpenSC 0.13.0 and uncommenting the line in opensc.conf he got his card working. One could not just disregard the user consent bit at the PKCS#15 level, because if the card enforces it, the OpenSC and application better send the pin just before the crypto operation, and they don't. A related problem is Mathias Tausig's thread: "Re: [opensc-devel] PIN not sent to card before signing" on 10/23 is another example of a card enforcing user_consent, but the OpenSC code issuing a sign operation, that fail, then trying again, but the security context is now not valid. > > IMHO it feels a bit weird, that there is the PIN caching (to be turned > on or off, on by default), then this mechanism that first disables PIN > caching (user consent), then there is a mechanism that enables it > again. Yes it looks weird. By putting the #pin_cache_ignore_user_consent = true; in the opensc.conf file allows one to provide a fix or circumvention (by just uncommenting the line) to get cards that enforce user_consent with OpenSC 0.13.0 to work with older applications without a code change, just a configuration change. > > This would of course unfortunately mean crippling the semantics of the > module (reporting a "normal" key when in fact it has > CKA_ALWAYS_AUTHENTICATE implemented in the hardware). > > The real problem is the difficulty in exposing the different PKCS#11 > hacks and tweaks to different applications in an easily managed way, > with concurrent applications... The hacks are: pin caching, and PIN caching for user_consent, and these are there because many PKCS#11 implementations don't know how to support CKA_ALWAYS_AUTHENTICATE and many applications don't know how to ask for CKA_ALWAYS_AUTHENTICATE, even though cards are being issued that enforce it. > > > Just a thought. Yes it is messy. CKA_ALWAYS_AUTHENTICATE has been in PKCS#11 V2.20 since 2004, 8 years now. OpenSC 0.12.0 got ahead of these applications by enforcing user_consent, but older applications would still fail, as they did not know how to deal with it. 0.13.0 supports it *AND* provides a simple "uncomment a line in opensc.conf" to work with old applications. > > -- 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
