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
