3. Domain name. Firefox extracts the domain name reliably and displays
it separately in the status bar, thereby circumventing user errors
in parsing the URL. But the domain name is only shown for SSL pages,
This may change in the future; I'm talking to dveditz about it.
and the status bar isn't always visible; though it cannot be turned
off by an attacker, it can still be turned off by the user,
Yes - we still allow the user that choice. But then it's their action.
and it
always disappears if the window height is reduced to less than about
150 pixels.
There is a minimum size for popup windows; we need to make sure the status bar is visible even at that size. If it's not, please file a bug.
It is slightly unfortunate that the domain name is shown
in a sans-serif typeface where the lowercase "l" is indistinguishable
from an uppercase "I", though this isn't an issue if the user trusts
that domain names are always shown in lowercase.
IMO, we should always show domain names in lowercase. This mitigates th e major O/0 and I/l ASCII homograph spoofing problems. If this is currently not true in some circumstance, please file a bug.
4. Organization name. Finally we get to an identifier that may not be
completely controllable by an attacker. In order to use a particular
organization name in a certificate, the attacker must convince a CA
to issue a certificate with that name.
Indeed. But there is no guarantee that such strings are unique even across a single CA, let alone across all of them.
How does a user know that Paypal GmbH or Paypal Ltd is not the same as Paypal, Inc, without being able to compare the two? Company names are not global.
If the CAs are scrupulous and
competent, they should refuse to issue certificates with confusing or
misleading names.
But the name can be truthful and still misleading.
Moreover, the organization name is a much more familiar identifier
("Wells Fargo and Company") than a domain name ("wellsfargo.com")
to a user, especially a user who is trying to bootstrap from trust
in the real world to trust in an online entity.
I don't agree that it's much more familiar - wellsfargo.com is what appears on the strapline of all of their million dollars of advertising, and it's what the user typed into their browser.
Furthermore, the CAs are mostly unknown to the user. Whereas the
user can be expected to have some kind of trust relationship with
the government, the user has no trust relationship with the CAs, has
no basis on which to judge their reliability, and shouldn't be forced
to assume trust in an unknown entity just to do business online.
Many users would object more to a Government CA than any other sort.
5. Petname. A "petname" is a user-assigned name (usually associated
with the site's public key). From a user's point of view, a petname
is by far the simplest mechanism to identify a site -- no domain
registrars, governments, or certificate authorities are involved.
Yes they are, if the name is associated with a site's public key, which is a cert tied to its domain name.
Seeing a particular petname is direct and unspoofable assurance that
the site being viewed now is the same site that was being viewed
when that particular petname was assigned.
I'd agree with that, as long as the site is connected to over SSL.
These five choices lie on a spectrum from no user control to total
user control, with each step yielding a more secure browser.
This is suspect analysis, because it assumes that petnames are the only possible progression beyond step 4.
Gerv _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
