Re: [Opensc-devel] OpenSC onepin

[David W. <dw...@in...>]

On Tue, 2016-10-04 at 14:41 +0200, Jakub Jelen wrote:
> On 10/04/2016 01:17 PM, David Woodhouse wrote:
> > 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.

Well, the problem is that the specification doesn't actually *give* any
recommendations here. The overall behaviour of applications trying to
find an object across a number of PKCS#11 tokens is *entirely*
unspecified, without even any hints about common practice in the Usage
Guide.

I'm trying to remedy that (amongst other things) in 
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

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

Right. So far I've been focusing on tools which take a certificate
specifier (previously just a filename, but now a PKCS#11 URI) on the
command line or in a config file. In that case it's simple — if the
certificate has CKA_PRIVATE==CK_TRUE, then the PKCS11 URI needs to
uniquely specify the token. Then we'll log into that token, and find
the certificate we need.

For NSS, some of the FindCertificate* APIs do operate only on the
internal softokn, and not on external tokens at all. Others will
attempt to iterate over all tokens, requiring PINs for them all.

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

Actually, there isn't *much* software to update. Applications generally
don't do this for themselves. We fix NSS, GnuTLS and the OpenSSL
PKCS#11 ENGINE, and that actually covers *much* of the ecosystem.

But first we do need a consensus on the behaviour we want them to
implement. Even in the Mozilla bug you referenced, I don't see a
specific algorithm that would work.

-- 
dwmw2