Douglas E. Engert wrote:
>
>
>> * Loading the module via standard GUI (preferences
-> advanced ->
>> encryption -> security devices -> load) still
results in 'unfriendly
>> behavior' meaning automatic certificate selection,
if enabled, requires
>> you to type in all different pins and puks on the
card (PIN1 for slot1,
>> PIN2 for slot 2 and PUK, alone in the separate
slot). (see
>> h
ttps://bugzilla.mozilla.org/show_bug.cgi?id=201333) This
is the second
>> reason why the hackerish module exists - even if
Firefox knew how to
>> select the right certificate if given the ones
present on Estonian eID,
>> it would ask both PIN1 and PIN2 just to make the
decision to choose the
>> one with PIN1 to proceed (even though the
certificates are public)
>>
>
> Reading the bug report, and your note, make it sound
like NSS is not
> handling certificates correctly. The way I read PKCS#11
if they can see
> the certificate with a Public session they could read
it. If the PIN is
> needed to read the cert the public PKCS#11 session
should not see the cert
> as it would be marked PRIVATE. The OpenSC
pkcs11-object.c enforces this.
>
Hi all,
there are 2 issues here that PKCS #11 complaint tokens can
and do which
requires authentication before you can see the
certificates.
1) Some tokens cannot export their certs unless you
authenticate. You
can't look at the CKA_PRIVATE flag because the C_FindObjects
cannot
actually see any objects until you authenticate. These
tokens are fairly
rare but will not work unless you authenticate.
2) NSS needs to be able to distinguish between User and
non-User
certificates. Prior to version 2.20 of the PKCS #11 spec,
there was no
attribute on the certificate that says whether or not the
cert was a
user cert. NSS identified user certs by the presence of a
corresponding
key. Usually the private key is CKA_PRIVATE, and therefore
not visible
if the token is not logged in. As a fall back NSS would
check to see if
the corresponding *PUBLIC* key was present. Storage of the
public key is
not required by the PKCS #11 spec (though NSS does try to
create it when
doing key gens and key imports).
By default, NSS is designed to work with any token that
actually meets
the PKCS #11 spec, so NSS need to authenticate to the token
before it an
read the certs and decide if any are candidates for
signing/authentication (so if you have multiple tokens
plugged in, it
may request the PIN for all of them before presenting any
dialog).
Since this is not friendly behavior, NSS does allow tokens
which meet
the requirements of 2) to indicate as such through the
'Publically
Readable Certs' flag. Unfortunately, as the bug points out,
you can't
use the device manager to set the flag. You can, however,
use a simple
webform to install the module. You can use even customize
this template
for a specific pkcs11 module.
In the long term NSS should look at and set the 2.20 User
attribute on
the certificate. If someone were interested in doing that, I
would
gladly point them in the right direction.
bob
>
>> Thus the need still exists for this hackerish
module to enable seamless
>> operation for Estonians at least. :(
>>
>
> Your cards look very complicated, with the use of
multiple PINS and certs.
> I have a single PIN, but multiple certs, and none have
the NR bit.
>
>
>> If there are bugs in the code or changes that
change this behavior - let
>> me know and I'll give it a try to see what happens.
Unfortunately I'm
>> not a pkcs11 expert.
>>
>
> Looking at pkcs15-esteid.c, do you really need to set
> the SC_PKCS15_PRKEY_USAGE_NONREPUDIATION?
>
> Someone wrote in framework-pkcs15.c:
> 2510 /*
> 2511 * Map pkcs15 usage bits to pkcs11 usage
attributes.
> 2512 *
> 2513 * It's not totally clear to me whether
SC_PKCS15_PRKEY_USAGE_NONREPUDIATION should
> 2514 * be treated as being equivalent with
CKA_SIGN or not...
> 2515 */
>
> I am going to go back to the pkcs15-piv.c and look at
the bits I have set
> a little closer too.
>
>
>> --Martin Paljak
>> http://martin.paljak.pri.
ee
>>
>>
>>
>
>
_______________________________________________
opensc-devel mailing list
opensc-devel lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel
|
