439936 - "O" field (organization) from SSL certificate not shown for non-EV websites (unknown, does not supply identity information)

Status: RESOLVED DUPLICATE of bug 429021

(Firefox :: Security, defect)

Description

[Tim Jackson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061712 Fedora/3.0-1.fc9 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061712 Fedora/3.0-1.fc9 Firefox/3.0

Although arguably related, this bug is NOT a duplicate of:

- bug #424182 (which is related, but about wording)
- bug #414627 (which is about display of domain information in the toolbar)

This bug is specifically about display of the Organization (O) field from non-EV SSL certificates in:

a) the immediate (short-form) box which appears when clicking the identity icon at the left of the toolbar
b) the "More information" box which follows on from that

When viewing a non-EV SSL website (e.g. https://bugzilla.mozilla.org at the time of writing), Mozilla claims in (a):

"You are connected to [domain] which is run by (unknown) Verified by [CA]"

and in (b):

"Owner: This web site does not supply identity information."

Both of these are:

i)   factually incorrect
ii)  misleading to the user (because they are false)
iii) inconsistent with the information (rightly) shown when selecting to view the full certificate.

(It is also incidentally gobbledegook as per bug #42418, but that is not the point of this bug)

The web site *does* (in most cases) supply identity information, via the Organization (O) field of the "Issued To" section of the certificate.

To what extent this identity information has been *validated* (cf EV-SSL) is a completely different issue and should be shown separately (for example via a "Trust Level" display - for example "Trust Level: High" for EV-SSL and "Trust Level: Medium" for normal SSL, or - as is currently the case - by only showing the org name in the address bar for EV sites). Ultimately, if the user "trusts" a CA to sign certificates (= their CA certificate is in the "Authorities" list and has the "This certificate can identify web sites" option ticked), then it is nonsensical and contradictory to then ignore the information they supply and even worse to tell the user barefaced lies in the form of "no identity information is supplied"/"run by: unknown".

Reproducible: Always




This bug is not about the politics or policies of CA certificate signing, but if CA's are issuing certificates with fake information, the CA's should be removed from the "trusted" list. If the CA wants to issue a certificate but can't validate the owner, the correct action is to simply not populate the "Organization" field (example of a CA which does this: CACert)

Comment 1

[Kai Liu]

This is intended (though admittedly confusing), as only EV requires that CAs verify the owner name; such a requirement does not exist for regular certificates, and you can get one if you just show that you own the domain.

Comment 2

[Johnathan Nightingale [:johnath]]

Yep - we are not going to start showing the O field for broad-distribution certificates because while some CAs do more or less verification, there is no baseline that we can point to and say "This is the work they do, and we consider it adequate."  When the need for that baseline became painfully apparently, we joined the CABForum and helped draft the baseline guidelines for proper identity verification - that's EV.  I would be happy to hear that there were a bunch of CAs conforming to some other, strongly verified, standardized, and audited, issuing practice - I am not at all wedded to EV-as-EV.

The UI we have in primary chrome is an identity UI, not a certificate viewer.  Certificates have lots of fields in them of questionable utility to the user.  We don't show them the policy OID or the OCSP responder because those things don't help a user make judgements about the identity of the sites they visit.  Neither do O fields of uncertain origin.

I'm sorry if I sound very final here, but this is a deliberate and carefully taken design point that is very unlikely to change in the way you describe.  I think a better approach, if you don't like EV for some reason, but do want O fields to show up, is to find a way to bring about some alternate, high-quality verification regime.  As I say, I am not running with EV blinders on, I just don't consider the balkanized state of verification in non-EV certificates right now to be appropriate to put in front of our users.  Nor do I think there is any implied contradiction in the fact that we trust the certs to do the thing they universally claim to do (domain ownership verification) but not to do the thing they don't universally claim to do (owner identity verification).

Comment 3

[Eddy Nigg (StartCom)]

As I mentioned in bug 424182 the details should be changed perhaps to:

"... run by: domain.com Verified by [CA]"

which represents a validated attribute according to the Mozilla CA policy and perhaps the most important one (that's what the browser really checks first) and it's also meaningful for the user. Additionally it would be consistent with
browser.identity.ssl_domain_display option set to 1, which again shows the validated domain name. Even more, it would be mostly consistent also with common CA practices to either omit the "O" field altogether or more commonly to feature the domain name in the "O" field for domain validated certificates.

I think this is a proposal Mozilla can fully stand behind without compromising on not-for-sure-validated or unknown other attributes.

Comment 4

[Tim Jackson]

Jonathan, I appreciate your detailed reply and am aware this is a bugtracker, not a support forum so I don't want to get into an extensive policy debate here.  However, regardless of policy, the good work done by CABForum or the poor/inconsistent state of (non-EV) SSL signing though, the original bug still stands: 

- Firefox is claiming to show "identity"
- the most useful thing for describing "identity" is the name of the organisation the cert was issued to
- that's what Firefox is showing for EV certs
- that's what the "O" field is for where the more-reliable EV data isn't present
- ergo for otherwise valid non-EV certs Firefox should show the "O" field, albeit with a caveat if necessary.

As you say yourself, the problems are standardisation, auditing etc. - in other words what I called "Trust level".

CAs may have inconsistent policies but they are putting their signature to a document, so there is some level of implied trust (even if some are violating that trust - but that's not Firefox's fault. If they are blatently violating this trust, exclude them from the default CA list.). The "O" field *is* useful for showing identity if you trust the CA, subject to their policy. 

Some ideas as a compromise:

1. Simply add another tickbox to each CA in the trusted list which says "Trust this CA to verify the identity of organisations". That wouldn't address the issue of signing policy consistency, but again the user can use their own judgement on a CA's policy if they trust the CA. (And for the default list supplied with Firefox, there aren't that many CA's so it wouldn't be too hard to ask them "do you verify the "O" field or is it just arbitrary data?").

2. (possibly in combination with (1)): Show the "O" field, but for non-EV certs have a caveat saying something like "The policy used by [CA] to verify the identity of [Org] has not been reviewed by Mozilla", possibly with a link to their signing policy if this is available.

I am not bashing EV or the goal of increasing consistency of identity assurance for certs (indeed I have repeatedly asserted the view offline that the focus on the use of certs for encryption at the expense of identity verification is a huge problem, not least for users that are lured into phishing attacks because they think "padlock=safe") and FF3's UI (coupled with EV) goes a long way to improving the situation but it seems that undermining the existing, technically OK, SSL architecture (especially for CA's that do verify identity, in some cases to a high level) just because of some non-technical policy issues is rather like throwing the baby out with the bathwater. It's ultimately *far* better for users to be using non-EV SSL sites (albeit with uncertain verification of identity) than plain HTTP, which guarantees zero verification of identity and no TLS to boot. In other words, by all means show the benefits of EV, but be fair to non-EV too - just include whatever caveats are appropriate and let users decide rather than strong-arming them by appearing to say "anything but EV is useless".

As Eddy says in comment #3, if my points above *still* don't ring true, at the very least the relevant dialogues should be re-worded so that they just don't say anything about organisational identity and focus on the domain instead, rather than claiming falsely that there isn't one specified. (which is more what bug #424182 is about)

Comment 5

[Eddy Nigg (StartCom)]

Just some technicalities since I'm not going to argue here...

The NSS team does gather information concerning domain validated (DV), identity validated (IV), organization validation (OV) and extended validation (EV). See for example http://www.mozilla.org/projects/security/certs/included/

If none of the suggestions from above are acceptable, than the information should be omitted entirely because as Tim (and me earlier at a different opportunity) mentioned, the information about "unknown" etc. are simply false.

I can understand that using the organization field isn't perhaps the best thing to do, since there are CAs which put this information in certificates even if it's not validated (albeit not many AFAIK). Anyway, better to show the domain name since this would add some real value for the user instead.