On Tue, 1 Mar 2005, Gervase Markham wrote:
> > 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.
True, though this is something we would *like* CAs to do. I don't
really trust them to do it, but isn't that ideally supposed to be
part of their job?
> 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.
It depends on the CA's policies. It would be nice to have a
trustworthy CA tell me that i'm dealing with the company that's
registered the name Paypal in the United States, for example.
If CAs can't provide a reliable binding between a certificate
and a real-world entity, then in my opinion they're pretty useless.
(I'm sorry to say that i have little knowledge of what guarantees
CAs currently make -- if any. I will try to learn more about this.)
> > 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.
Yes, i agree. Then you can argue one of two things:
(a) CAs are at fault and should be pressured to do a better job.
(b) We should enable users to not have to depend on CAs.
> > 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.
The user may or may not have typed in the domain name they see in the
status bar, depending on a variety of things. But maybe i should scale
down my claim (from "much more familiar") and just say that users
and our legal system have more experience dealing with company names
than with domain names. There's an established legal mechanism for
dealing with confusingly similar company names; such mechanisms for
domain names are missing or much less mature.
> > 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.
Okay, sure. But would you agree with the statement that it would be
better not to expect users to place trust in CAs they don't know?
And would you agree that most users don't know most of the CAs they
are currently relying on?
> > 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.
No, the public key is all that is necessary. If i establish an SSL
connection with you and i can verify your public key, i know for sure
that i'm talking to you (unless you have given away your private key).
I know the public key because of the encryption, not because of what
it says on your cert. What it says on the cert doesn't matter anymore.
> > 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.
Great.
> > 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.
Sorry, that was not my intention. These five items just happen to be
the methods that i know. If you have other identification methods to
add to the list, please do. Note that in the original message, i said:
| I can think of five possible ways ...
| (Feel free to suggest other possibilities to add to the list.)
My overall point is that we should look at these methods of identification
in terms of a spectrum from attacker control to user control, and try
to head in the direction of user control, to the extent feasible.
attacker control user control
<<<----------------------------------------------------------->>>
* page
* URL
* domain name
* CA-signed company name
petname *
-- ?!ng
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
