328346 - Certificates with keyusage nonRepudiation should not be used as SSL client certificates

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[John Allberg]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Firefox enables certificates with keyusage nonRepudiation as SSL client certificates.

nonRepudiation keyusage is used for certificates that is to be used with advanced signatures, not for authentication which corresponds to SSL client authentication.

RFC 3280 states:
"The nonRepudiation bit is asserted when the subject public key is used to verify digital signatures used to provide a non-repudiation service which protects against the signing entity falsely denying some action, excluding certificate or CRL signing. In the case of later conflict, a reliable third party may determine the authenticity of the signed data."

This conflicts with that Firefox uses this as a SSL client certificate, since SSL isn't a non-repudiation service.

At least in the nordic countries, it is very common to use a certificate pair, where one certificate is used for authentication purposes, for example client authenticated SSL (with keyusage digitalSignature, keyEncipherment) and the other is used for non-repudiation signatures with software outside of the browser.

Reproducible: Always

Steps to Reproduce:
1. Import a nonRepudiation certificate or connect a pkcs#11 security device which exposes a nonRepudiation certificate
2. Go to a site which accepts the CA for SSL authentication


Actual Results:  
Firefox logs on with the nonRepudiation certificate. Some web servers regards the certificate as invalid for authentication and SSL negiotiation fails with those.

Expected Results:  
SSL negiotiation should never be attempted with a nonRepudiation certificate

It seems that bug# 217721 introduced the behavior to allow login with nonRepudiation. In version 1.0.5-7 this worked as expected.

Comment 1

[Josh Birnbaum]

-> NSS

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Actually the behavioral change was the result of the fix for bug 240456 .

I might agree that a cert with only NR KU (not NR + others) ought not be
used with SSL at all (client or server), since SSL leaves no verifiable
signature after the fact.  

However, I think there are some countries whose national PKI standards 
rely on NR certs being usable for email signatures and SSL client auth.

Comment 3

[Wan-Teh Chang]

*** Bug 328458 has been marked as a duplicate of this bug. ***

Comment 4

[John Allberg]

> However, I think there are some countries whose national PKI standards 
> rely on NR certs being usable for email signatures and SSL client auth.

As I read 240456, that only handles the way a OCSP response is verified, where the RFC 3280 doesn't state anything about keyusage in the OCSP responder certificate, but rather EKU.

The sideaffect that nonRepudiation is accepted in all cases where digitialSignature is required is IMHO wrong. I agree that the validation of the OCSP signer certificate should accept NR keyusage, but SSL should not.

I haven't heard of a country using nonRepudiation keyusage only certificates in SSL. Can you give any example? The bug#217721 was reported in 2003-08-29 and the reporter hasn't even confirmed the fix or posted comments after 2004-03-12. AFAIK the germans also use nonRepudation certificates for signatures only, so I was a bit surprised that the reporter was german.

I still think this is in conflict with RFC 3280 and should be fixed.

If you still disagree and refuses to fix this, I have two suggestions:
1. Make sure certificates with other keyusage that nonRepudiation only are automaticly choosen first. As it is right now, our nonrep certificate is always choosen by Firefox, even though there is a digitalSignature certificate also.
2. When the option to manually select a certificate to log on with is selected, there is no way to distinguish a nonRepudiation certificate from a digitalSignature certificate. The GUI has to be updated to reflect the keyUsage.

Comment 5

[John Allberg]

Sorry, I used the wrong RFC for OCSP. It's supposed to be 2560, not 3280 as I wrote.

Comment 6

[Gert-Jan]

(In reply to comment #2)
> However, I think there are some countries whose national PKI standards 
> rely on NR certs being usable for email signatures and SSL client auth.

Refering to http://wp.netscape.com/eng/security/comm4-cert-exts.html the SSL client certificate must have key usage digitalSignature. SSL servers do not accept certificates with key usage nonRepudiation so I think this issue should be fixed.

Comment 7

[u60234]

*** Bug 346100 has been marked as a duplicate of this bug. ***

Comment 8

[sternmarc]

This is definitly a bug.

in RFC 2459 (X.509 v3), chapter 4.2.1.3 (Key Usage), it is specified that
"The digitalSignature bit is asserted when the subject public key is used with
a digital signature mechanism to support security services other than
non-repudiation (bit 1), certificate signing (bit 5), or revocation information
signing (bit 6). Digital signature mechanisms are often used for entity
authentication and data origin authentication with integrity."
If that bit is not present, it shouldn't be used for authentication.

If you only have the nonRepudiation bit, it shouldn't be used:
"The nonRepudiation bit is asserted when the subject public key is used to
verify digital signatures used to provide a non-repudiation service which
protects against the signing entity falsely denying some action, excluding
certificate or CRL signing."

The point is not to disable certificates that have both bits set, but only those which don't have the digitalSignature set.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Giving NR client auth complaints to Bob.

Comment 10

[Martin Paljak]

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

It is sufficient to remove the patch from that bug. Theoretically thinking: If the key has a usage 'nonrepudiation' how come 'signing' can be translated into 'nonrepudiation', when it means something else in real life (yes, technically it is signing)?

In addition to flushing most if not all European digital signature schemes, it definitely renders the usability of firefox into close to 0, as the usability of 'client certification selection' every time a new session is opened is as good to end users as 'not functioning correctly'. Most if not all European eID cards have two or more certs/keys, one being for authentication and one for digital singatures (and digitalsignatures having nonrepudiation usage only)


So unless a proper solution (nonrep having a lower priority or something similar) is made, please do try to get this thing changed in FF 2.0. 

Comment 11

[Martin Paljak]

This is seriously blocking FF 2.0. Having it the same way in FF 2.0 as in FF 1.5 shall cause people to drop using smartcards in EU with FF.

Comment 12

[Frank Wein [:mcsmurf]]

I'm not in a position to decide about this bug here, but it will be very hard (or rather: impossible) to get this fixed for FF2. Firefox 2 is basically ready for shipping and I doubt any code changes will be allowed to get in (except for security bugs and such). If this bug will get fixed, then in a Firefox 2.0.x release at earliest.

Comment 13

[Brendan Eich [:brendan]]

If this is important enough, we can fix it for Firefox 2 still.

Bob, Nelson, Wan-Teh: please advise on whether there is an expedient fix, and if so, who will make the patch.

/be

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Brendan,  The world does not speak with one voice concerning the correctness
of using NR certs in SSL client auth.  Some countries want/expect NR certs 
to be usable anywhere that signing certs are usable.  Others do not want that.
We made an explicit change to allow that, which is now being called a regression
by those who do not want it.

We're now hearing the other side of this issue vociferously threaten to stop 
using FF because it might let them use an NR client certificate in some 
situation where they believe they should not use it.  ("Doctor, it hurts when 
I do this.")  But if we disable it, it will NOT let anyone use those certs in 
the situations where others want to be able to do so.  

I think the jury is still out. I wouldn't advise to stop FF 2.0 for it.
Expect more vociferout response here.

Comment 15

[Brendan Eich [:brendan]]

Nelson, what about comment 8?

/be

Comment 16

[Martin Paljak]

(In reply to comment #14)
> Brendan,  The world does not speak with one voice concerning the correctness
> of using NR certs in SSL client auth.  Some countries want/expect NR certs 
> to be usable anywhere that signing certs are usable.  Others do not want that.
> We made an explicit change to allow that, which is now being called a
> regression
> by those who do not want it.
> 
> We're now hearing the other side of this issue vociferously threaten to stop 
> using FF because it might let them use an NR client certificate in some 
90% of people who are not forced to use FF don't look back if they have to do manual steps for things that JustWorks with other browsers.

> situation where they believe they should not use it.  ("Doctor, it hurts when 
> I do this.")  

Comment 17

[Brendan Eich [:brendan]]

AFAICT there are two issues:

1)  A claim that we don't follow the RFC.

2)  The argument that it just works in other browsers.

Both are compelling by themselves. Firefox has gained market share in part by emulating IE quirks (e.g., undetected document.all). I don't advocate making up certificate-related quirks, but I'd like to understand whether 2 is caused by 1 above.  If so, we should fix this bug based on item 1. If the RFC is incomplete or ambiguous, then 2 still may be decisive (de-facto complete standard trumps de-jure incomplete/ambiguous standard).

/be

Comment 18

[stef]

Hi Nelson, all,

I can imagine that people who have a "single key for everything"
do want this feature. Or that there are other good reasons (which
I'm curious to hear about?)

On the other hand, it's probably clear to all that e.g. eID cards
that have a key for legally binding sigs don't want this key
to be used to log to a web site...

So: wouldn't it be possible to make it an option?
(Preferably one that could be set by an installation program)

Just my 2 cents... (sorry if I'd sound too vociferous:)

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

Brendan,  The arguments would be compelling if they were indisputably true.

SSL isn't an NR service.  It isn't an application service at all.  It is a 
protocol that is used by some appliation services, some of which want NR and 
some of which do not.  There is no clear-cut standard that defines which 
protocols are elligible to use NR certs and which ones aren't.  There may 
never be.  For example, S/MIME email sends signed messages.  Some messages 
(e.g. bearing contracts) are elligible for NR signatures, others are not.  
The appropriateness of using NR certs for signatures depends on the 
application (sevice) context, not the protocol used to reach that service,
especially when the protocol is not exclusively linked to a single appliation
service.  The LDAP protocol may be linked to a single service exclusively,
but SSL is not.

Regarding the claim that it "works in other browsers", rather the claim is 
that NR DOESN'T (yet) work in other browsers, and some like it that way. 
In the past, when we NEVER used NR certs for any reason, the people who 
didn't want us to use NR certs for client auth were happy with that situation 
and the services who wanted their clients to be able to use NR certs with FF 
were unhappy.  Now that we've made NR certs work, the people who don't want 
their clients to use NR certs claim that it worked correctly before (when it 
didn't work at all).  They're happy to point at other products that also do 
not yet use NR certs.

Think of signature and NR certs like Visa and Master Card cards.  Imagine 
if a merchant who accepts Visa but not MC said "we don't want any card swipe
readers anywhere to ever accept MC cards, because we don't accept them."

The one argument that I've heard against using NR certs for SSL client auth 
that seems at all persuasive to me is that SSL client auth (today) leaves 
no signed record of the transaction that can be verified after the fact 
independently of the server's cryptographic info (keys).  However, the 
IETF is working on extending TLS to provide that very capability.  See 
http://www.ietf.org/internet-drafts/draft-housley-evidence-extns-00.txt
So, I would not say that the argument against using NR certs with SSL client
auth is indisputable.

The SSL/TLS standards predate the use of NR certs.  Today the SSL protocol 
lets the server tell the client the list of issuers whose client certs are 
acceptable to the server.  It does not also let the server express its 
willingness (or lack thereof) to accept NR certs from a single issuer who 
issues both types.  That may be seen as a deficiency of SSL/TLS, or 
alternatively, it may be seen as a deficiency of a PKI deployment that 
uses a single issuer for both NR and ordinary (non-NR) signature certs 
alike.  Such a deployment failed to consider the capabilities of the 
extant standards for enabling clients to distinguish between the two.  

In the very short timeframe remaining for FF2, we can go back to the state
of disallowing NR certs by backing out the fix for bug 240456, and reopening
that bug.  Producing a patch that allows NR for some protocols and not others 
is a much larger change that IMO is likely to take longer than the desired 
time, or to incur high risk of regression.  However, I expect the howl from
disabling NR certs to be greater than the howl against leaving them enabled.

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

It occurs to me that PSM has its own separate logic for selecting client
auth certificates, separate from NSS's code to do that.  PSM's client auth
cert selection logic can be modified to reject NR certs (if that is FF's 
wish) without any risk to other NSS-based products.  So, I am changing this
into a PSM bug.

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #15)
> Nelson, what about comment 8?

RFC 2459 was obsoleted by RFC 3280.  RFC 3280 doesn't contradict the older 
RFC in many areas,  but in the area of key usage, it says some different things.  
For example, RFC 3280 does *not* say (concerning the digital signature usage bit) 
"If that bit is not present, it shouldn't be used for authentication."

Comment 22

[Daniel Veditz [:dveditz]]

> For example, RFC 3280 does *not* say (concerning the digital signature usage
> bit) "If that bit is not present, it shouldn't be used for authentication."

Nor does rfc2459, that was an interpretation from sternmarc (outside the quote).

(In reply to comment #14)
> We're now hearing the other side of this issue vociferously threaten to stop 
> using FF because it might let them use an NR client certificate in some 
> situation where they believe they should not use it.  ("Doctor, it hurts when 
> I do this.")  But if we disable it, it will NOT let anyone use those certs in 
> the situations where others want to be able to do so.  

That may be what comment 0 says, but the real issue seems to be that in countries where it's common to have both kinds of certs we're now defaulting to the NR-cert which the server rejects, and our unclear UI doesn't let people distinguish. 

It sounds like (comment 4, comment 10) people would accept us using NR certs as long as we don't default to them if there's a more appropriate cert also available. It's not that people are spec nazis, it's that the spec is ammo in a fight against a usability problem that's confounding non-expert users (that is, most people) in their regions.

Maybe the usability problem can be solved or ameliorated in the PSM UI without having to decide the NR issue in NSS.

Comment 23

[Brendan Eich [:brendan]]

(In reply to comment #22)
> It sounds like (comment 4, comment 10) people would accept us using NR certs as
> long as we don't default to them if there's a more appropriate cert also
> available.

How do we judge algorithmically which is the "more appropriate cert"?

> Maybe the usability problem can be solved or ameliorated in the PSM UI without
> having to decide the NR issue in NSS.

UI won't solve this one, but it could ameliorate/palliate/mitigate.  I'm looking for a real fix.  However fine the new RFC is, between its change in semantics and the de-facto practices (bad or not, they're out there), we have an incompleteness or an inconsistency (or both) that should be fixable with an algorithm to choose NR or not. Is there such an alg?

/be

Comment 24

[Anders Rundgren]

The problem is that the term non-repudiation has no meaning anymore.  In actual legal cases people are convicted based on IP address logs etc.  Due to this, I personally don't see any point with having separate authentication and signature certificates.  It was a great idea 10 years ago though.

The problem with the TLS use-case is really that the algorithm for finding out if the user has a separate signature and authentication certificate is *undocumented* making it hard to filter this the way it is supposed to work.

For signatures it becomes even worse, since you may have to offer the user a choice of using a repudiatable signature or a non-repudiapable signature!  Who can possibly understand that?

Comment 25

[Martin Paljak]

(In reply to comment #20)
> It occurs to me that PSM has its own separate logic for selecting client
> auth certificates, separate from NSS's code to do that.  PSM's client auth
> cert selection logic can be modified to reject NR certs (if that is FF's 
> wish) without any risk to other NSS-based products.  So, I am changing this
> into a PSM bug.
> 

I don't really know the relation between all mozilla products and components, but for example Camino - that does not expose the manual certification selection option is currently not usable if presented a smartcard via pkcs#11 that has two certificates/keys - one with ssl client usage and one with nonrepudiation usage.  If PSM is used in Camino as well, this would solve it. If not - the problem comes from NSS and would require a separate fix for Camino.

In the end I can only describe the 'totally right' behavior, whereas the technical details and RFCs have been quoted by others already:

* If visiting a website that uses SSL client authentication
* and having two certificates from the required issuer (usually on a smart card via pkcs#11)
* One having SSL client authentication extendued usage and the other one for binding digital signatures with NR KU bit.
* The certificate for SSL client authentication must be chosen automatically.

I agree that the real problem might be somewhere else and more complicated (I even remember reading some blog post a year or so ago, telling that 'PSM has been abandoned and not really improved for long time') this is the right behavior that needs to be achieved. 

I linked to a wrong bug before - reverting bug 240456 will fix the proble just fine to previous state - but when allowing nonrepudiation bit the test case for the change shall still be the one i described before - taking into account extended key usage.

I suggest to revert that change.

Comment 26

[Eric Norman]

Here's my take about the NR thing, which is in a totally different area.  If it would have been more appropriate to file a new bug about this, I apologize for not understanding the process.

Anyway, If the NR bit is set in a certificate (regardless of which other keyUsage bits are set or how they are interpreted), then there's one thing that MUST NOT happen.  A signature cannot be affixed without the user taking some action.  For instance, if a user checks the "sign by default" option when configuring an email agent, certificates with the NR bit set should be excluded as possible choices.

The reaason for this is that a lot of folks think that in order for the notion of non-repudiation to be viable, then a user must perform some action (like clicking an "I agree" button) to signify their intent to sign the document when they are looking at it.  That is, if the default case is to sign a document when it is sent, clicking the "send" button" signifies just intent to send, not intent to sign.

Comment 27

[John Allberg]

My suggestion is to go with comment #19 and to revert 240456.

(In reply to comment #17+19)
I can't find the claim that it just works in other browsers, especially not in my own postings. But I can do that now... 

Internet Explorer doesn't care about KU, only EKU. If KU is missing in the certificate, all EKU is enabled by default (leaving nonRep certificates usable with SSL). The CSP that publish the certificate to CAPI has the option to set EKUs which we use to disable for example client authentcation on the NR certificate. That way everyone is happy. 

AFAIK there is no way to accomplish the same thing via PKCS#11, which othervise would be a viabile solution.

(In reply to comment #22+23)
Yes, this is a usabillity issue with RFC's (and drafts) as "weapons"... From a usabillity point of view, FF currently by default automaticly chooses the certificate to logon with, regardless if there are other valid certificates available. It would be nice if FF would ask the user what certificate to use if there are more than one available.

When using the option to always let the user choose certificate to logon with, there is currently no way to distinguish the two certificates by KU or EKU.

My suggestion for choosing certificate algorithm would be:
1. EKU Client Authentication
2. KU DS
3. KU NR 

(In reply to comment #26)
In the whole, I agree with Eric, but I don't think that's FF's problem to handle, but rather the PKCS#11 provider. That's how we currently handle that problem, letting the PKCS#11 provider popup both PIN dialogue and additional info, to show if its a "legal signature" or "authentication".

Comment 28

[Anders Rundgren]

After reading this it does not come as a huge surprise that the majority of e-government C2G services in the EU do NOT use TLS-client-authentication, but rather "home-grown" authentication schemes closely matching the certificates in question.

I'm personally unconvinced that TLS-client-authentication is the right solution in this segment; at least not until there is a "companion" signature scheme in place as well, and that seems to be a very long journey.

Comment 29

[Nelson Bolyard (seldom reads bugmail)]

PSM (using NSS) fetches ALL the user's certs (certs for which the user has
the private key) and makes a list of certs that are eligible to be used 
for client auth, then picks one from that list.  The eligibility is 
based on a number of factors including the name of the cert issuer, and the 
cert extensions.   KU and EKU are both used in making that determination.  
If PSM wishes to exclude NR certs from that list, it may do so. 
This can all be solved in PSM.  

I agree that, in the case where the user has multiple elligible certs, 
some with NR and some without, giving preference to the non-NR certs would 
resolve this issue, for SSL client auth.  

Comment 30

[Brendan Eich [:brendan]]

(In reply to comment #29)
> I agree that, in the case where the user has multiple elligible certs, 
> some with NR and some without, giving preference to the non-NR certs would 
> resolve this issue, for SSL client auth.  

Then let's do that for Firefox 2 -- Kai, can you whip up a patch?

/be

Comment 31

[Wan-Teh Chang]

Search for "repudiat" in the following US Federal government
standards.  I believe you'll come to the same conclusion as me
that the PIV cards will be affected by this bug, too.

http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf
http://www.cio.gov/ficc/documents/CertCRLprofileForCP.pdf

In the second document, look in particular at the nonRepudiation
field values in Worksheet 5: End Entity Signature Certificate Profile
and Worksheet 9: PIV Authentication Certificate Profile.

Comment 32

[Robert Relyea]

The one primary reason for prefering certs with NR over certs without in authentication cases is certain tokens will require another pin prompt for the use of NR.

I agree with nelson that 1) this can be fixed in psm and 2) we should allow the use of NR while prefering certs without NR. This can be done by sorting the NR certs to the 'bottom' of the cert list. This is a bit more code than just removing, and should be reviewed (NR certs shouldn't be sorted below certs that are expired or don't match the CA list sent by the server), but it is less likely to break users which only have 1 signing cert and happen to have the NR bit turned on in it.

bob

Comment 33

[Julien Pierre]

re: comment 27,

John, the PKCS#11 spec doesn't say anything about modules popping up their own UI. PKCS#11 modules can and do get used in non-GUI programs (eg. servers). If you have a UI component in your PKCS#11 library, then that module may not work in those programs. In this case we have a GUI program, Mozilla/PSM, but IMO we still need to have a solution that doesn't require the PKCS#11 modules to do things outside the spec.

Comment 34

[Kai Engert (:KaiE:)]

Attachment: Patch v1

We seem to agree on the salomonic compromise "allow NR-only certs, but prefer those who have only DS or both DS/NR". I'm attaching a patch.

But in my opinion, we must fix this for both "select automatically" and "prompt" configuration settings.


First, let's talk about those users who have set their client auth pref to "auto".  The fix seems obvious, check key usage for NR-only, and only use it if no better cert can be found.

In the existing code, we call NSS function CERT_FindUserCertsByUsage with a parameter "oneCertPerName" set to True. I believe I have to toggle this bool to False, so NSS will us return all the certs - a requirement for allowing PSM to make a choice.

I am not sure whether this has the potential to introduce side effects. Because the comment for this parameter describes it as "return the best cert per name", I wonder if NSS is doing any selection, based on the certUsageSSLClient we are passing to it.

But looking at the implementation of CERT_FindUserCertsByUsage, it appears it actually uses a very simple selection, returning the first cert that is found. So this is probably safe to do.


Second, let's talk about those users who have set their client auth pref to "prompt".

It has been suggested to sort the certs in the list and put the NR-only certs behind the other ones. I think this is hard to do right in a small amount of code. A helpful function used internally by NSS is not exported (CERT_SortCBValidity) and therefore not available to be used by PSM.

As we are looking for a small patch for last minute inclusion, I propose we do not attempt to re-sort this already sorted list.

My proposal is to show more information in the UI and make it the user's responsibility to select a good one. After all, the user has explicitly configured the wish to manually select.


It was said in this bug, the UI currently does not allow the user to distinguish between differences at the key usage level. I created test certificates and I can confirm that.


My minimal-change-proposal is: Let's add " [NR]" to the "short cert name [serial]" currently displayed in the drop down box. I hope this does not have a side effect. Looking at all involved code, it appears, the string is only displayed for display, but never as a key. So the change seems safe.

The drawback of that minimal change, the [NR] can not be localized in FF2.


My complete-UI-info proposal is: In the detailed description text box, let's add a line below the "Purposes" and display all key usages for this cert. Luckily we seem to have all strings readily available in our bundle.


In the attached patch, I have added code for both UI proposals. While the minimal approach is simpler, I think the key usages string is better.


For testing, I created 3 certs:
- a) no key usage extension
- b) key usage non-repudiation only, cert type both SSL client and S/Mime
- c) key usage digital signature only, cert type both SSL client and S/Mime
I got displayed all 3 certs, while only cert b) had the [NR] string appended in the dropdown box.
Only for b) and c) I had an additional information line in the text box.
Using cert b), I was not able to connect to my test server (as expected).
Using certs a) and c) worked fine to connect to my test server.

Comment 35

[Eric Norman]

(In reply to comment #34)

> But in my opinion, we must fix this for both "select automatically" and
> "prompt" configuration settings.
> 
> My proposal is to show more information in the UI and make it the user's
> responsibility to select a good one. After all, the user has explicitly
> configured the wish to manually select.

I filed a new bug that I think is relevant to certificate selection.  I'm not sure I did it right.  But anyway, it's bug #356060

Comment 36

[Kai Engert (:KaiE:)]

Attachment: Patch v2

Per discussion with Bob and Brendan, we prefer the [NR] change for now.

Comment 37

[Kai Engert (:KaiE:)]

Attachment: Patch v3

Addressed review comments from a chat.

Comment 38

[Robert Relyea]

Comment on attachment 241776 [details] [diff] [review]
Patch v3

r+ this one looks right.

Note that NR is set on all non-repudiation certs, not just ones with the signing bit set to zero. (this is correct behavior).

Comment 39

[Reed Loden [:reed]]

Comment on attachment 241776 [details] [diff] [review]
Patch v3

>+        if (hasExplicitKeyUsageNonRepudiation(node->cert)) {
>+          // Not a prefered cert

s/prefered/preferred/, please. :)

Comment 40

[Kai Engert (:KaiE:)]

fixed on trunk

Comment 41

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #30)
> Then let's do that for Firefox 2 -- Kai, can you whip up a patch?

Brendan, Kai, Rob: does this mean that this is a **must-fix** issue for Firefox 2?  Touching nsNSSIOLayer.cpp this late in the game makes me very nervous, and I'd like to get a clear statement of the various risks in taking and not-taking this patch at this late point in the game. (Remember: our schedule doesn't really allow for an RC4!)

Comment 42

[Martin Paljak]

Sorry, so many comments and being in 12h different timezone...

No, this patch does not fix it. Showing [NR] in the cert selection popup is nice, BUT the test case, as I described before, is still wrong:

1) Have two certificates, one with EKU SSL authentication and KU DS, and one with KU NR
http://martin.paljak.pri.ee/download/mozilla-nonrep/auth.cert.txt and http://martin.paljak.pri.ee/download/mozilla-nonrep/sig.cert.txt
2) Automatic certificate selection is turned ON
2) I go to a SSL website requesting a certificate from the CA who had issued the two previous certificates

The expected result is:
3) If automatic certificate selection is turned on, the cert from auth.sig.txt certificate is used.
3) If automatic certificate selection is turned off, the cert from auth.sig.txt certificate (as the one having TLS Client authentication usage bits) is suggested first.

Current result is:
3) NR cert is used by default or selected in the popup.

This certificate does NOT have a EKU of TSL client authentication. There exists one that has (both certificates and keys come from pkcs#11 of opensc-project.org) and that is not used.

I tried the build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ 

The discussion about the NR bit is falling off the edge, as the main problem is the fact that 1) it should work without any extra configuration (select one automatically being the default option for certificate selection) 2) It is not working as supposed (whatever the standards, common sense tells that certificate with TLS client authentication usage should be used, at least suggested as the first option, for TLS client authentication)

Removing the patch from  bug 240456 makes it back to normal. I suggest to do that and then decide what is the right way of handing the NR bit so that it is done semi-correctly. 

This still not usable.

Comment 43

[Kai Engert (:KaiE:)]

(In reply to comment #42)
> No, this patch does not fix it.

I notice your certificates are EXPIRED:
        Validity
            Not Before: Sep 29 21:00:00 2003 GMT
            Not After : Oct  3 21:00:00 2006 GMT
                        ^^^^^^ 1 week ago


> 1) Have two certificates, one with EKU SSL authentication and KU DS, and one
> with KU NR
> http://martin.paljak.pri.ee/download/mozilla-nonrep/auth.cert.txt and
> http://martin.paljak.pri.ee/download/mozilla-nonrep/sig.cert.txt

both expired


> Current result is:
> 3) NR cert is used by default

Are you sure?
Is it possible that Firefox does not use any cert at all?
As far as I can tell, our "automatic selection" will only use valid certs - it will not use expired certs.



> or selected in the popup.

Well, we have not fixed the sorting. As I explained in comment 34, a sorting change at the last minute seems tricky and risky.

The [NR] prefix is meant to allow you to select the right one.
What happens if you manually select your (expired) cert - the one which does NOT have the [NR] suffix? You did not say that. Can you try?


> I tried the build from:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ 

correct


> The discussion about the NR bit is falling off the edge, as the main problem is
> the fact that 1) it should work without any extra configuration (select one
> automatically being the default option for certificate selection) 2) It is not
> working as supposed (whatever the standards, common sense tells that
> certificate with TLS client authentication usage should be used, at least
> suggested as the first option, for TLS client authentication)

Before we continue this discussion, can you please retry with not-yet-expired certs, certs that are still valid?
Thanks

Comment 44

[Kai Engert (:KaiE:)]

Call for testers: Everyone who owns valid certificates and previously ran into this issue: Can you please test whether the nightly test build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ works for you?

Comment 45

[Martin Paljak]

The certificates on that webpage are expired, but the ones on my ca(In reply to comment #43)
> (In reply to comment #42)
> > No, this patch does not fix it.
> 
> I notice your certificates are EXPIRED:
This webpage and the files are from an earlier post on the same topic. In real life the certs I 
use are not expired. It is just to show the (E)KU bits in certs.

> > 1) Have two certificates, one with EKU SSL authentication and KU DS, and one
> > with KU NR
> > http://martin.paljak.pri.ee/download/mozilla-nonrep/auth.cert.txt and
> > http://martin.paljak.pri.ee/download/mozilla-nonrep/sig.cert.txt
> 
> both expired

They are there just for reference - but i updated the files. except sig.cert is sign.cert now.

> > Current result is:
> > 3) NR cert is used by default
> 
> Are you sure?
> Is it possible that Firefox does not use any cert at all?
> As far as I can tell, our "automatic selection" will only use valid certs - it
> will not use expired certs.

Yes, I'm sure. Forget about the validity period.

> > or selected in the popup.
> 
> Well, we have not fixed the sorting. As I explained in comment 34, a sorting
> change at the last minute seems tricky and risky.
> 
> The [NR] prefix is meant to allow you to select the right one.
> What happens if you manually select your (expired) cert - the one which does
> NOT have the [NR] suffix? You did not say that. Can you try?

Everything works as expected if I select the authentication certificate manually.


> Before we continue this discussion, can you please retry with not-yet-expired
> certs, certs that are still valid?
I never test with invalid certificates as the site I'm testing against does an extra check against OCSP.

Just the references in the web are old and wrong (certificate profiles are still exactly the same)

Comment 46

[Martin Paljak]

I still suggest to remove the 'if asked KU is DS, allow NR to act as DS' change in certdb.c introduced with  bug 240456 and then think how to support NR only KU so that it would make most sense. Future solution would be making PSM use TSL client authentication EKU as a filter or something similar.

Comment 47

[Kai Engert (:KaiE:)]

> Touching nsNSSIOLayer.cpp this late in the game makes me very nervous, and
> I'd like to get a clear statement of the various risks in taking and not-taking
> this patch at this late point in the game.

"taking" assessment:

The change is limited to SSL connections where the server requires client authentication.

If automatic cert selection is configured (the default), a different cert may be selected by Firefox.

If manual cert selection is configured (non-default), the change is limited to a cryptic suffix [NR] displayed, which assists power users in making the right selection.

I believe the code does not have a potential to introduce crashes.

Comment 48

[Kai Engert (:KaiE:)]

Reopening.

Martin, thanks a lot for your comments and examples. I created test certificates that match your example, and I am able to confirm:

The automatic selection does not yet work.

I made a mistake in my patch. We are still aborting the search for a good cert after we find the first user cert. (The break statement at the wrong position). Sorry.

With Patch v4 applied, using the example certs, the automatic selection now works correctly for me.


(In reply to comment #45)
> Everything works as expected if I select the authentication certificate
> manually.

This is good to know.

Comment 49

[Kai Engert (:KaiE:)]

Attachment: incremental patch after v3

Comment 50

[Kai Engert (:KaiE:)]

Attachment: Patch v4

This is v3 + the incremental patch.

Comment 51

[Martin Paljak]

(In reply to comment #48)
> 
> With Patch v4 applied, using the example certs, the automatic selection now
> works correctly for me.
Good! This means that it becomes usable again! Waiting for a new mac nightly to test it...!

I leave you in a nice discussion about the the most right solution to the NR bit problem, but IMHO it starts from 'If we have a EKU TSL client authentication'cert to present - we do it'. After that starts the problem of the NR bits...

Thanks!
What are the plans for FF 2.0 line regarding this issue ? 2.0 ? 2.0.1 ? 2.0.x ?

Comment 52

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #41)
> (In reply to comment #30)
> > Then let's do that for Firefox 2 -- Kai, can you whip up a patch?
> 
> Brendan, Kai, Rob: does this mean that this is a **must-fix** issue for 
> Firefox 2?  Touching nsNSSIOLayer.cpp this late in the game makes me very 
> nervous, and I'd like to get a clear statement of the various risks in taking 
> and not-taking this patch at this late point in the game. (Remember: our 
> schedule doesn't really allow for an RC4!)

Still looking for an answer here. What's the impact of not taking this for Firefox 2, and instead waiting for Firefox 2.0.0.1? What other code touches the modified sections of nsNSSIOLayer.cpp which could result in regressions?

Comment 53

[Mike Beltzner [:beltzner, not reading bugmail]]

Not reviewed, not a regression, we'll try to get this in 1.8.1.1/Fx 2.0.0.1

Comment 54

[Kai Engert (:KaiE:)]

(In reply to comment #52)
> (In reply to comment #41)
> > (In reply to comment #30)
> > > Then let's do that for Firefox 2 -- Kai, can you whip up a patch?
> > 
> > Brendan, Kai, Rob: does this mean that this is a **must-fix** issue for 
> > Firefox 2?  Touching nsNSSIOLayer.cpp this late in the game makes me very 
> > nervous, and I'd like to get a clear statement of the various risks in taking 
> > and not-taking this patch at this late point in the game. (Remember: our 
> > schedule doesn't really allow for an RC4!)
> 
> Still looking for an answer here. What's the impact of not taking this for
> Firefox 2, and instead waiting for Firefox 2.0.0.1? What other code touches the
> modified sections of nsNSSIOLayer.cpp which could result in regressions?


While I didn't want to make a decision whether this is a "must fix" for FF 2, please see my comment 47 where I try to answer your question about the risk.


Using the test certs I just verified - FF 1.5 is broken already. So if this is a regression, and if it worked in FF 1.0, it seems we have been living with this regression since 1.5

Comment 55

[Gert-Jan]

(In reply to comment #44)
Kai,

I have tested the nightly build. When certificate selection is set to manual I can see the [NR] suffix in the list of valid certificates. This is nice for power users that know everything about X.509 but is not very useful for end users. When certificate selection is set to automatic Firefox should select a certificate wiht KU digitalSignature.

Please fix the automatic certificate selection as soon as possible. As it is now, we have to advise our users to use a different browser.

Comment 56

[Martin Paljak]

What is the status of the last patch? I'd give a nightly a try but it seems that the last patch has not been reviewed nor applied?

2.0.x is not far :)

Comment 57

[Daniel Veditz [:dveditz]]

Would be great to change the cert-picking logic if we can for 1.8.1.1, not sure we could take the UI change.

Comment 58

[Kai Engert (:KaiE:)]

Comment on attachment 241833 [details] [diff] [review]
incremental patch after v3

r=kengert on my own obvious single-line correctness fix.

Comment 59

[Kai Engert (:KaiE:)]

Comment on attachment 241834 [details] [diff] [review]
Patch v4

r=kengert on this v4, which is patch v3 (r=rrelyea) plus the obvious fix listed above.

Comment 60

[Kai Engert (:KaiE:)]

Comment on attachment 241833 [details] [diff] [review]
incremental patch after v3

I checked in this incremental fix to the trunk.

Comment 61

[Kai Engert (:KaiE:)]

Marking fixed on trunk, you might want to test tomorrow's nightly trunk build.

Comment 62

[Kai Engert (:KaiE:)]

Comment on attachment 241834 [details] [diff] [review]
Patch v4

Requesting 1.8.1.1 approval of patch v4.

Note that v4 simply combines v3+fix.

I propose to take the simple UI change, which does not cause any harm, and does not affect localization.

Comment 63

[Daniel Veditz [:dveditz]]

Comment on attachment 241834 [details] [diff] [review]
Patch v4

approved for 1.8 branch, a=dveditz for drivers.

Is this something we would also want for Firefox 1.5.0.x? Probably  not, it's not a security fix and a working version will be available in FF2.0

Comment 64

[Kai Engert (:KaiE:)]

checked in to 1.8 branch

(In reply to comment #63)
> Is this something we would also want for Firefox 1.5.0.x? Probably  not, it's
> not a security fix and a working version will be available in FF2.0

I tend to agree.

Comment 65

[Martin Paljak]

(In reply to comment #62)
> (From update of attachment 241834 [details] [diff] [review] [edit])
> Requesting 1.8.1.1 approval of patch v4.
> 
> Note that v4 simply combines v3+fix.
> 
> I propose to take the simple UI change, which does not cause any harm, and does
> not affect localization.
> 


Latest nightly build (3.0a1) Does not fix the problem. Still the NR only certificate is selected automatically when another more suitable certificate with EKU SSL-client is available.

I still suggest to drop the certdb.c change in the old OCSP & NR related changeset and then introduce NR support again, after giving it some more though. Or fix it in PSM. Is somebody would point me to some PSM tutorials I would look at it myself (and also make FF respect pinpads...)

Comment 66

[Kai Engert (:KaiE:)]

(In reply to comment #65)
> Latest nightly build (3.0a1) Does not fix the problem. Still the NR only
> certificate is selected automatically when another more suitable certificate
> with EKU SSL-client is available.

Martin, sorry, it works for me now, with the test cases I had produced.
I just repeated my test and it still works as expected. I have a test site, requiring client auth, accepting certs from a test CA, I own two certs from that test CA, one having Certificate-Usage NR only, another one having Certificate-Usage Signing+KeyEncipherment+DataEncipherment. When I have "manual cert selection" configured, I get prompted to select from those two, selecting the NR results in a failure (as expected), selecting the other one works (as expected). When I restart the browser, and switch to "select cert automatically" it will give me a successful connection, which demonstrates the right cert got selected.

Can you please make a test case available to me? A set of test certs and a server to connect to?

Comment 67

[Gert-Jan]

(In reply to comment #66)
(In reply to comment #66)
The latest build looks good! 
I have tested the build with a smartcard that contains three certificates with the following key usage bits:
1: nonRepudiation
2: digitalSignature
3: keyEncipherment, dataEncipherment, keyAgreement

With automatic certificate selection turned on, Firefox now selects the certificate with digitalSignature.

Comment 68

[Kai Engert (:KaiE:)]

*** Bug 329897 has been marked as a duplicate of this bug. ***

Comment 69

[Michael Olofsson]

(In reply to comment #67)

I have tried it on both 2.0.0.4 and latest nightly Minefield build and it automatically choses the right cert now. I am using the service that the initial reporter of the bug had found the bug through so there is definitely a change for the better now.

Comment 70

[Martin Paljak]

Latest minefield (downloaded today) really does the right thing. 2.0.0.4 not yet (should it? It sure does display the [NR]...)

Comment 71

[Kai Engert (:KaiE:)]

(In reply to comment #70)
> Latest minefield (downloaded today) really does the right thing. 2.0.0.4 not
> yet (should it? It sure does display the [NR]...)


Martin, we assumed the bug is fixed.

Can you please explain more? What is the incorrect behavior that you get in 2.0.0.4?

Comment 72

[Anders Rundgren]

Regardless the fix, FF TLS sucks since it does not honor AIA CA-issuer which means that a FIPS201 user must install CA certificates in order to get the issuer selection working.  Yes, this is outside of TLS...

Remedy:

http://upi-emulator.webpki.org/SchemaViewer/687474703A2F2F786D6C6E732E776562706B692E6F72672F776562617574682F76312E30

Which has a signature counterpart in:

http://upi-emulator.webpki.org/SchemaViewer/687474703A2F2F786D6C6E732E776562706B692E6F72672F776173702F76312E302F636F7265

http://webpki.org/WASP-tutorial.pdf

Comment 73

[Nelson Bolyard (seldom reads bugmail)]

Anders, please refrain from using bugzilla to promote your WASP software.
Thanks.

Comment 74

[Anders Rundgren]

Dear Nelson,
I just skimmed a 400 page document by the Swedish government.  In the document they had among many things asked 22 departments which area in IT which needed more standardization.  The thing that got (by far) most scores was eID.  Since eID is mainly used in conjunction with browsers, there apparently is a disconnect here between what the browser vendors offer and what at least the Swedish government wants.  I believe that

http://openoces.org

is another indication that FF's crypto.signText is not perceived as very useful.  signText does not have any standards status either.  Neither MSFT or Opera supports signText.

==========================================================================
The question that begs for an answer is how Mozilla anticipates that a useful signature solution will eventually become a part of FF?
==========================================================================

BTW, WASP/WebAuth is a standards proposal, not a piece of software.

Just to make it even more complex: There are wide incompatibilities in the on-line provisioning of PKI as well here thinking of Xenroll, KeyGen and generateCRMFrequest ().

Going back to the actual bug, the true culprit is that TLS wasn't designed for the variant eID world which is the reason a lot of eID-using web-applications do not use TLS-client-certificate authentication.  Microsoft's CardSpace is an indication where we are [probably] going; away from protocol-level authentication.

Anders

Comment 75

[(dormant account)]

Note this patch just introduced a prbool violation.

 /security/manager/ssl/src/nsNSSIOLayer.cpp:
 2006:-  return (keyUsage & KU_NON_REPUDIATION);
+  return (0 != (keyUsage & KU_NON_REPUDIATION));

Comment 76

[John Allberg]

The behaviour that the authentication certificate should be choosen before the non-repudiation has been broken in FF 3.0.

I'm trying to re-open this bug report.

Comment 77

[Kai Engert (:KaiE:)]

John, please let's keep this bug closed, as it does not refer to firefox 3.

Can you please file a new bug against ff3 and explain what you do and what fails?

Comment 78

[Martin Paljak]

Just for the record: FF 8.0b1 seems to have finally got this right, non-repudiation only certificates are not even shown as suitable in the certificate selector!

Comment 79

[Wan-Teh Chang]

Yes, that's the result of fixing NSS bug 217721.

Comment 80

[Martin Paljak]

Now it would be cool if bug 511652 could also get a verdict and/or solution. That's the last requirement to drop the "onepin" hack from OpenSC which exists solely for NSS.. :)