Re: [Muscle] pcscd / firefox / ubuntu on android

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Muscle] pcscd / firefox / ubuntu on android

Douglas E. Engert
Ask on the opensc-mail list. there is a 0.13.0-rc1 available.

On 10/18/2012 7:40 PM, James Southwell wrote:
> When is opensc 0.13 going to be released?
>
> Thanks
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Muscle] pcscd / firefox / ubuntu on android

Martin Paljak-4
On Thu, Oct 18, 2012 at 9:48 PM, Douglas E. Engert <[hidden email]> 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?

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.

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...


Just a thought.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Muscle] pcscd / firefox / ubuntu on android

Jean-Michel Pouré - GOOZE
Le jeudi 25 octobre 2012 à 21:49 +0300, Martin Paljak a écrit :
>
> 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...

Maybe using and promoting an library like
http://p11-glue.freedesktop.org/
would be a suitable solution.

Kind regards,
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Muscle] pcscd / firefox / ubuntu on android

Douglas E. Engert
In reply to this post by Martin Paljak-4


On 10/25/2012 1:49 PM, Martin Paljak wrote:

> On Thu, Oct 18, 2012 at 9:48 PM, Douglas E. Engert <[hidden email]> 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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel