Re: OpenSC onepin

On 10/04/2016 01:17 PM, David Woodhouse wrote:
> 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

Thank you for the reference. It is exactly what I had in my mind, but I 
didn't find proper words to pinpoint that.

>> 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
> [...]
>
> 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?

That is basically the original problem in the bug and one of the 
variants brought up many times on this mailing list and among Mozilla 
users. But so far, the proposed solution was to use "onepin". There was 
an pressure on Mozilla to change their behavior (above bug), but it was 
never accepted. Instead the specification shifted the onepin way.

I think upstream projects should follow specification recommendations 
and make the tools working for most of the current users and use cases, 
unless there is a good reason not to do that.

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

The problem is how you define what "you're after". Unless you log in, 
you can never know if it is everything what you can see. You can have a 
card showing only single certificate before login and hiding the other, 
which would lead into very unexpected behavior for users. You can also 
have empty cards, which would also fail with this heuristic.

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

This would be the optimal approach, but it sounds like a run on a very 
long distance, updating all the software to reflect these flags and the 
new cards to publish these attributes. But thank you for mentioning 
that. I will try to pursuit that.

Regards,

-- 
Jakub Jelen
Security Technologies
Red Hat


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