Re: OpenSC onepin

On Tue, 2016-10-04 at 11:55 +0200, Jakub Jelen wrote:
> Hello all,
> 
> recently we discussed the usefulness of the onepin library and basically 
> came to conclusion that the onepin should be used by default. Most of 
> the cards have only one pin (if there is the second, it is most probably 
> not needed to be visible in the PKCS#11, since should be "signature 
> pin") and also the PKCS#11 specification is moving away from the mapping 
> of multiple pins to multiple PKCS#11 tokens (citation needed?).

The citation for that would be 
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html#_Toc406760011

> The intention of this email is to start a discussion, if we still want 
> to have virtual slots by default. Mozilla is not going to expose the 
> "friendly bit" in UI [1], which would be possible workaround. But AFAIK, 
> we could make that default and for the other use cases create some 
> virtual-slots-opensc-pkcs11.so which would behave like the current default.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145

Hm, that manages to be all about the CKA_PRIVATE attribute on objects,
without ever once mentioning CKA_PRIVATE. Impressive :)

It seems that the NSS softokn doesn't *permit* you to specify
CKA_PRIVATE==CK_TRUE when importing a cert...

$ p11tool --load-certificate ec-cert.pem --mark-private --label OC-EC --id 123403 --write 'pkcs11:token=NSS%20Certificate%20DB'
...
C_CreateObject
  IN: hSession = S16777217
  IN: pTemplate = (10) [ CKA_CLASS, CKA_ID, CKA_VALUE, CKA_TOKEN, CKA_CERTIFICATE_TYPE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, CKA_LABEL, CKA_PRIVATE ]
C_CreateObject = CKR_ATTRIBUTE_VALUE_INVALID


NSS therefore knows that its own token will always show *all*
certificates in a C_FindObjects() call even before login. It calls this
special-case behaviour "friendly".

We can't know that other tokens are "friendly", because objects can be
explicitly created with CKA_PRIVATE==CK_TRUE and if they are created
*without* an explicit value for CKA_PRIVATE then the token itself gets
to choose, and some tokens *do* set CKA_PRIVATE==CK_TRUE even for
CKO_CERTIFICATE objects, if given the choice.

So what's the problem here? That NSS is trying to log in to *all* the
different PKCS#11 slots of a given card, which are exposed separately
in PKCS#11 because they *might* theoretically have different PINs? 

And the proposed solution is to stop exposing multiple PKCS#11 slots
per card, because in practice people *don't* actually set multiple PINs
on the same card? So at least they only get one PIN prompt?

I'd still prefer to see the NSS behaviour improved, and perhaps achieve
some kind of consensus on how we search for objects in various
"friendly" and non-friendly tokens. 

For a start, why can't we iterate over all the tokens and see if we
find what we're after, and only *then* go back and log in to the ones
that need it, if we don't?  Although that doesn't necessarily fix
Firefox when we *don't* have a client cert and the request was just
opportunistic, it would fix many cases where the object *is* found.

It might also be interesting to approach the PKCS#11 TC and suggest a
new flag which tokens can report, to indicate that they *are*
"friendly", which is defined as "has no CKA_PRIVATE certificates". Or
perhaps the C_FindObjects() API can be extended in a compatible way, to
allow a token to indicate that "No CKA_PRIVATE objects were excluded
from these results" for *that* specific C_FindObjects() call. Then NSS
*would* be able to extend its "PK11_IsFriendly()" hack to cover tokens
other than its own internal softokn.


-- 
dwmw2

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
Opensc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensc-devel