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 https://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
Title: Install a PKCS #11 module
Install a PKCS #11 module
Module Name:Module Path:
Uses Publically Readable Certs
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel