Mozillas 1.5+ (NSS 3.10?) select wrong certificate for authentication

[Martin Paljak]

Hello!

When using a token (Estonian eID card) via OpenSC PKCS#11 module with
FF 1.5 / TB 1.5 it selects a wrong certificate automatically - if you
don't select 'ask every time' for certificate selection then the
nonrepudiation slot is used instead of the authentication slot. This
was not the case with 1.0.x

This is a somewhat blocking and also annoying bug as with automatic
certificate selection things will not work and even if the user
switches on certificate selection dialogue FF suggests the wrong cert.

Certificates:
Authentication - http://martin.paljak.pri.ee/download/mozilla-nonrep/
auth.cert.txt
Signature - http://martin.paljak.pri.ee/download/mozilla-nonrep/
sig.cert.txt
Screenshot - http://martin.paljak.pri.ee/download/mozilla-nonrep/
screenshot.png

About the web based digital signature thread - that's even not so
important. There are other cross-platform and cross-browser means for
getting digital signatures (activex, java, upi) via the preferred
itnerface (cryptoapi, cdsa, pkcs#11)

--
Martin Paljak
martin...@gmail.com

["Martin v. Löwis"]

Martin Paljak wrote:
> When using a token (Estonian eID card) via OpenSC PKCS#11 module with
> FF 1.5 / TB 1.5 it selects a wrong certificate automatically - if you
> don't select 'ask every time' for certificate selection then the
> nonrepudiation slot is used instead of the authentication slot. This
> was not the case with 1.0.x

My guess is that this comes from

https://bugzilla.mozilla.org/show_bug.cgi?id=240456

committed as revision 1.70 in security/nss/certdb/certdb.c

Can you try reverting that change, and see whether this improves
things?

Also, can you please explain why the non-repudiation certificate
is wrong? Non-repudation is a (even stronger) form of authentication.

Regards,
Martin

[Martin Paljak]

On 11.02.2006, at 13:28, Martin v. Löwis wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=240456
Will have a look, though i don't have much experience with mozilla/
nss builds.

> Also, can you please explain why the non-repudiation certificate
> is wrong? Non-repudation is a (even stronger) form of authentication.

AFAIK nonrep-only certificates are only used for legally binding
digital signatures.
Usually usage of such keys requires additional user consent.

m.

[Martin Paljak]

On 11.02.2006, at 13:28, Martin v. Löwis wrote:

> Can you try reverting that change, and see whether this improves
> things?

Yes. This helps:
--- certdb.c~ 2006-02-12 09:21:58.000000000 +0100
+++ certdb.c 2006-02-12 09:21:58.000000000 +0100
@@ -1265,8 +1265,6 @@
}
certKeyUsage = cert->keyUsage;
- if (certKeyUsage & KU_NON_REPUDIATION)
- certKeyUsage |= KU_DIGITAL_SIGNATURE;
if ( (certKeyUsage & requiredUsage) == requiredUsage )
return SECSuccess;

And my certificates list will look like this:
http://martin.paljak.pri.ee/download/mozilla-nonrep/patch.png

And the right slot chosen with automatic certificate selection.

As the nonrep only certificate does NOT have a SSL client certificate
usage bit it must not be chosen automatically for ssl client
authentication.

cheers,
m.
--
Martin Paljak
mar...@paljak.pri.ee

[Nelson B]

Martin Paljak wrote:

> As the nonrep only certificate does NOT have a SSL client certificate
> usage bit it must not be chosen automatically for ssl client
> authentication.

I looked at your certs. Your non-repudiation certificate does not have
an "extended key usage" (EKU) extension at all.

When an EKU extension is present, the cert may only be used for the usages
listed there; but when NO EKU extension is present, the cert is valid for
ALL usages, subject to the limitations of the key usage and basic
constraint extensions.

So, since your NR cert has no EKU extension, we have no reason to believe
that it is not usable for SSL client auth. It is not a CA cert, so
cannot be used to sign certs. It has a key usage that excludes use for
any sort of encryption. But it allows NR, which is a type of signature.
And signature is the key usage required for client auth. So, we conclude
that this cert can be used for ANY signature application whatsoever.
(Some signature applications require NR, but AFAIK, none forbid NR.)

If you want your NR cert to be unusable for SSL client auth, then you need
an EKU extension that doesn't include that usage.

--
Nelson B

["Martin v. Löwis"]

Nelson B wrote:
> So, since your NR cert has no EKU extension, we have no reason to believe
> that it is not usable for SSL client auth. It is not a CA cert, so
> cannot be used to sign certs. It has a key usage that excludes use for
> any sort of encryption. But it allows NR, which is a type of signature.
> And signature is the key usage required for client auth. So, we conclude
> that this cert can be used for ANY signature application whatsoever.
> (Some signature applications require NR, but AFAIK, none forbid NR.)

OTOH, usage of the NR certificate might/should require explicit user
approval (might: from the device itself, should: from the application):
It appears that applications associate a "contract-signing" meaning
with the NR bit, assuming that the user is always explicitly aware of
the usage of the NR certificate (otherwise, the user could repudiate
having signed a message, if that mesage was never presented to him).

This is surely inconvenient for SSL applications: you shouldn't have
to authorize signing each individual message if you said "select
automatically" before.

So I think it would be best if the browser detected that there is
a better-suited certificate (one which doesn't need explicit user
interaction); the browser should then also invoke explicit approval
if the NR certificate is used even though "select automatically"
was configured (explaining that this specific certificate is a
formal signature).

Regards,
Martin

[Nelson B]

Martin v. Löwis wrote:

> So I think it would be best if the browser detected that there is
> a better-suited certificate (one which doesn't need explicit user
> interaction); the browser should then also invoke explicit approval
> if the NR certificate is used even though "select automatically"
> was configured (explaining that this specific certificate is a
> formal signature).

That's an interesting idea. Please file an Enhancement request "bug"
in bugzilla.mozilla.org. But I wouldn't expect it to be implemented in
the next 6 months, because there's no much work scheduled ahead of it.
So in the meantime, get an EKU extension if you can.

--
Nelson B

[Anders Rundgren]

I would be very hesitant about such a change as the "algorithm" behind
this "better-suited certificate" stuff is anything but clear[*]. In fact, it seems
that most issuers do not make a distinction between signature and authentication
certificates these days. The meaning of the NR-bit has been discussed to
death in PKIX but no RFC was produced as there were no consensus on
what it actually meant :-(

Anders R

*] There is to my knowledge no standard for identifying a "suite" of
certificates, only local conventions. These conventions MAY be
universal but I would not count on it.