Martin Paljak wrote: > On 14.06.2007, at 1:00, Douglas E. Engert wrote: >> So it looks like the latest FireFox 2.0.0.4 is working much better. > * Certificate selection is still broken - it selects nonrepudiation > certificate with no ssl client certificate usage bits automatically even > though it should select a certificate with SSL client capabilities (IMO) > (see https://bugzilla.mozilla.org/show_bug.cgi?id=328346 - even though > it is considered as fixed). This is one of the reasons why the onepin > module exists - to only present one certificate (protected with one pin) > to firefox so that it could do dumb decisions.
OK, the NR bit selection still looks like a big problem, in FF. A problem I don't have. > > * 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. > > 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 > > -- Douglas E. Engert <[EMAIL PROTECTED]> 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
