CAcert Root Certificate
David Ross
comments) whether CAcert's root certificate belongs in the Mozilla
certificate database. At the present, the only new root
certificates being added to the database have successful WebTrust
audits, which is the primary cause of the debate since CAcert is a
low-budget operation with free user certificates and cannot afford
the audit. Some very lengthy rants have excessively lengthened the
bug report, rants that belong here and not in the report.
A Mozilla Foundation policy has been drafted to address this
issue. The policy provides for alternative approvals for root
certificates, thus not tying Mozilla strictly to WebTrust.
Approval of that policy is pending.
In the meantime, a review of CAcert's policies and operations has
begun in accord with the draft policy. It may be possible that the
review may conclude about the same time the policy is approved and
thus provide a test case of the policy.
PLEASE: Make any further comments on this issue here and not in
the bug report.
Relevant links:
<URL:https://bugzilla.mozilla.org/show_bug.cgi?id=215243> -- Bug
report #215243: CAcert root cert inclusion into browser
<URL:http://www.hecker.org/mozilla/ca-certificate-policy/> --
Mozilla CA Certificate Policy (draft)
<URL:http://www.hecker.org/mozilla/ca-certificate-metapolicy/> --
Mozilla CA Certificate Metapolicy (draft)
<URL:http://www.hecker.org/mozilla/ca-certificate-faq/> -- Mozilla
CA Certificate FAQ
--
David E. Ross
<URL:http://www.rossde.com/>
I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.
Nelson B
> In Mozilla bug #215243, a lengthy debate has begun (via bug
> comments) whether CAcert's root certificate belongs in the Mozilla
> certificate database. At the present, the only new root
> certificates being added to the database have successful WebTrust
> audits, which is the primary cause of the debate since CAcert is a
> low-budget operation with free user certificates and cannot afford
> the audit.
David, IINM, The policy now allows CAs to be admitted if they have
the *equivalent" of a webtrust audit. The CAs admitted to the list
in 2004 may all have had webtrust audits, but a statement about those
"being admitted" (present progressive tense) needs to include those
with equivalent credentials also.
> Some very lengthy rants have excessively lengthened the
> bug report, rants that belong here and not in the report.
I agree completely about that!
> A Mozilla Foundation policy has been drafted to address this
> issue. The policy provides for alternative approvals for root
> certificates, thus not tying Mozilla strictly to WebTrust.
> Approval of that policy is pending.
That policy is mozilla's defacto policy now. Frank's draft policy,
in its various revisions, is the policy that has been followed for
the last year, and is the policy now being followed.
I don't believe there's any formal Mozilla Foundation "approval"
process now underway, on whose outcome this policy is waiting.
Rather, I think Frank has not yet asked the Mozilla Foundation to
stamp it with final approval.
At the present time, there are 179 CA certificates in mozilla software,
representing approximately 45 different CAs. No monopoly there.
The number grew from 129 to 179 (almost 40%) in 2004 alone. So, clearly,
under the draft policy, no monopoly is present, and many CAs who meet
the criteria have been admitted. Quite a few of those CAs now offer
free personal certificates. From those "observations", I conclude that
mozilla's draft policy is serving the community of mozilla users very
well.
> In the meantime, a review of CAcert's policies and operations has
> begun in accord with the draft policy.
Who is undertaking this review?
> It may be possible that the
> review may conclude about the same time the policy is approved and
> thus provide a test case of the policy.
Indeed, it may. Or it may not. But I think the process should be
bounded (finite duration, say 6 months or less) and when it is done,
the bug should be resolved, either "fixed" or "invalid".
If the conclusion is that this (or any) CA does not meet the criteria,
then the bug should not be left open indefinitely. Leaving the bug
open indefinitely leaves readers with the impression that Mozilla is
"dragging its heels" rather than with the understanding that "this CA
does not meet the policy requirements". If the CA does not meet the
requirements, then the advocates for the CA should understand that,
and be working on fixing that, rather than bemoaning the apparent
lack of progress on the bug. It doesn't help anyone for Mozilla to
be afraid to say "no".
> PLEASE: Make any further comments on this issue here and not in
> the bug report.
Amen to that!
--
Nelson B
Nelson B
> At the present time, there are 179 CA certificates in mozilla software,
> representing approximately 45 different CAs. No monopoly there.
> The number grew from 129 to 179 (almost 40%) in 2004 alone.
My numbers were off by a factor of 2 because they included trust records.
The number of CA certs is actually 90, having grown from 65 (nearly 40%)
in 2004. They do represent approximately 45 different CAs.
--
Nelson B
David Ross
>
> I previously wrote [also in part]:
>
> > A Mozilla Foundation policy has been drafted to address this
> > issue. The policy provides for alternative approvals for root
> > certificates, thus not tying Mozilla strictly to WebTrust.
> > Approval of that policy is pending.
>
> That policy is mozilla's defacto policy now. Frank's draft policy,
> in its various revisions, is the policy that has been followed for
> the last year, and is the policy now being followed.
I believe that, until the Mozilla Foundation gives formal approval
to the policy, Frank is approving only CA root certificates that
have the WebTrust seal. This assumption is supported by the
history of recent certificate approvals.
The primary issue is trust. When a secure Web site is selected and
the lock icon changes from open to closed, unsophisticated users
trust that the Mozilla or Firefox browser has correctly identified
and authenticated the site. Until CAcert's practices are reviewed,
the Mozilla Foundation cannot risk its user base by installing
CAcert's root certificate. This review has started even though the
policy has not yet been reviewed. The review itself started using
draft CAcert documents and cannot conclude until CAcert's own
documents are in final form.
In the meantime, all those demanding that CAcert's root certificate
be installed in browsers can readily download and install it
themselves in their own configurations. This way, the users are
accepting all risks without creating any liability for the Mozilla
Foundation.
Simon Anderson
> Until CAcert's practices are reviewed,
> the Mozilla Foundation cannot risk its user base by installing
> CAcert's root certificate.
Yet the Mozilla foundation has risked the security of it's
user base by turning a blind eye to abuses from commercial CA's
such as Verisign.
The double standard expressed by David here epitomises the Mozilla
Foundation's attitude throughout the eighteen months of discussion on this
topic.
After eighteen months of Mozilla's stalling, it's time for CA-Cert to
accept that the Mozilla Foundation is unwilling to work with the free
certificate community and that it's prevarication on this issue wastes
everyone's time.
I advise CA-Cert to utilise it's meagre resources more profitably by
finding other avenues to encourage "free security for all." The Mozilla
Foundation has shown itself to be an unwilling participant in the
community, so it's time for CA-Cert to move on.
For Mozilla, it's not about "trust" or "security." Rather, it's about "who
pays." This stance is incompatible with community certification.
-Simon.
Ian G
>On Mon, 31 Jan 2005 12:41:57 -0800, David Ross wrote:
>
>
>> Until CAcert's practices are reviewed,
>>the Mozilla Foundation cannot risk its user base by installing
>>CAcert's root certificate.
>>
>>
>
>Yet the Mozilla foundation has risked the security of it's
>user base by turning a blind eye to abuses from commercial CA's
>such as Verisign.
>
>
MF is not really capable of judging whether one
CA or another is conducting abuses. That's one
known bug in the model: all CAs are equal, and
the consumer is not given a display of the CA so
as to use her own knowledge and preferences to
make a judgement (c.f., branding ideas). Regardless,
MF will never be able to work out whether a CA is
good or bad, and its current policy is to shifts that
burden of CA vetting over to WebTrust and equivalents.
The fact that this puts the stress on the WebTrust
process to meet users' real needs is a clear and
obvious shortfall. It's also a massive barrier to
entry, but hey! Somehow I doubt that any vague
complaints or grumbles are going to register,
given the weight of evidence against the model
assembled so far (and the losses incurred).
So, if you have some list of abuses, you really
want to post them. You are going to need to
establish two things:
1. a given CA is abusing,
2. the WebTrust system is inadequate to deal
with 1.
You need to establish both things. Now, if you
have any evidence of Verisign abuse, have a
look here:
http://icann.org/tlds/net-rfp/net-rfp-public-comments.htm
Where evidence of abuse might make a difference.
(Did Verisign get their WebTrust renewed?
I wrote WebTrust about the conflict of interest
but they never responded.)
>The double standard expressed by David here epitomises the Mozilla
>Foundation's attitude throughout the eighteen months of discussion on this
>topic.
>
>
David has found a compromise that suits for now.
It's not perfect, but nobody can make the world
perfect.
>For Mozilla, it's not about "trust" or "security." Rather, it's about "who
>pays." This stance is incompatible with community certification.
>
>
I've never seen any evidence that MF cares about
who pays. For the most part, I'd characterise the
situation as slavish subscription to an old security
model that is now shown to be inadequate. That
will change, as the inadequacies mount (losses,
etc). The honeymoon ended a year or two back,
but it's taking a while for people to get to grips
that the browser security model is being breached
by spoofing / MITM attacks.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Simon Anderson
> Simon Anderson wrote:
>
>>On Mon, 31 Jan 2005 12:41:57 -0800, David Ross wrote:
>>
>>
>>> Until CAcert's practices are reviewed,
>>>the Mozilla Foundation cannot risk its user base by installing
>>>CAcert's root certificate.
>>>
>>>
>>
>>Yet the Mozilla foundation has risked the security of it's
>>user base by turning a blind eye to abuses from commercial CA's
>>such as Verisign.
>>
>>
> MF is not really capable of judging whether one
> CA or another is conducting abuses. That's one
> known bug in the model: all CAs are equal, and
> the consumer is not given a display of the CA so
> as to use her own knowledge and preferences to
> make a judgement (c.f., branding ideas). Regardless,
> MF will never be able to work out whether a CA is
> good or bad, and its current policy is to shifts that
> burden of CA vetting over to WebTrust and equivalents.
I'll assume that you're not being obtuse. This is the most well known
issue from Verisign;
http://www.pcworld.com/news/article/0,aid,45284,00.asp
This case allows anyone to make a value judgement on Verisign's services,
MF included. Please don't pretend otherwise.
Verisign's inclusion in mainstream browsers should have been at least
reviewed (if not removed) after such an incident, yet this did not occur.
Why is unearned trust of Verisign given by MF despite such incidents,
while a Community Authority is assumed by MF in the first instance to be
untrustworthy? MF forms a value judgement based on a comparison of market
capitalisation between the two organisations, nothing more.
> The fact that this puts the stress on the WebTrustprocess to meet
> users' real needs is a clear and obvious shortfall. It's also a massive
> barrier to entry, but hey! Somehow I doubt that any vague complaints or
> grumbles are going to register, given the weight of evidence against the
> model assembled so far (and the losses incurred).
>
> So, if you have some list of abuses, you really want to post them. You
> are going to need to establish two things:
>
> 1. a given CA is abusing,
> 2. the WebTrust system is inadequate to deal
> with 1.
>
> You need to establish both things. Now, if you have any evidence of
> Verisign abuse, have a look here:
>
> http://icann.org/tlds/net-rfp/net-rfp-public-comments.htm
>
> Where evidence of abuse might make a difference.
Evidence of abuse (wrong word, "untrustworthyness" would be better) should
make a difference here. The browser is at the coal face of a user's
security.
> (Did Verisign get their WebTrust renewed? I wrote WebTrust about the
> conflict of interest but they never responded.)
>
>>The double standard expressed by David here epitomises the Mozilla
>>Foundation's attitude throughout the eighteen months of discussion on
>>this topic.
>>
> David has found a compromise that suits for now. It's not perfect, but
> nobody can make the world perfect.
Ah, the creed of the apathetic and the lethargic.
>>For Mozilla, it's not about "trust" or "security." Rather, it's about
>>"who pays." This stance is incompatible with community certification.
>>
>>
>>
> I've never seen any evidence that MF cares about who pays. For the most
> part, I'd characterise the situation as slavish subscription to an old
> security model that is now shown to be inadequate. That will change, as
> the inadequacies mount (losses, etc). The honeymoon ended a year or two
> back, but it's taking a while for people to get to grips that the
> browser security model is being breached by spoofing / MITM attacks
MF's approach is this;
"Verisign paid for Webtrust, so they will be included no matter how many
times their security is breached or their processes are shown to be
insecure. CA-Cert in contrast, cannot be included without paying for
WebTrust." I think that you will consider this an oversimplification but I
contend that this is the root of the matter, based on eighteen months
of watching MF prevaricate.
I think that the CA-Cert people should ask themselves why they want to
have their cert included in MF browsers. If they're interested in secure
solutions they would do well to stay away from a browser so willing to
prostitute itself to commercial entities at the expense of true security.
-Simon.
Ian G
>On Wed, 02 Feb 2005 00:17:01 +0000, Ian G wrote:
>
>
>
>>MF is not really capable of judging whether one
>>CA or another is conducting abuses. That's one
>>known bug in the model: all CAs are equal, and
>>the consumer is not given a display of the CA so
>>as to use her own knowledge and preferences to
>>make a judgement (c.f., branding ideas). Regardless,
>>MF will never be able to work out whether a CA is
>>good or bad, and its current policy is to shifts that
>>burden of CA vetting over to WebTrust and equivalents.
>>
>>
>
>I'll assume that you're not being obtuse. This is the most well known
>issue from Verisign;
>
>http://www.pcworld.com/news/article/0,aid,45284,00.asp
>
>This case allows anyone to make a value judgement on Verisign's services,
>MF included. Please don't pretend otherwise.
>
>
The facts outlined in that article are not an
awful lot to hang ones hat on. The made a
mistake, once, and it was 4.9 years ago. So,
it's not a current issue, assuming the cert
has expired.
And in that time, has this cert (or certs) ever
surfaced to cause any damage or cause any
infections or viruses or stolen CCs?
Systems fail. That's why we call them systems,
not religions. Verisign are allowed to make
the odd mistake, which can be considered to
be "proving by exception..." If they made a
pattern of it we'd have much more to worry
about. If they had abused their position, that
would be an issue.
But dishing out the odd false cert? Anyone
who didn't see that coming doesn't understand
systems and corporations and ... well, life.
>Verisign's inclusion in mainstream browsers should have been at least
>reviewed (if not removed) after such an incident, yet this did not occur.
>
>
Right. This is a reflection of the general
failure of governance in the CA and Cert
market. MF don't take the rub for that,
they've started up their program, and what
they want to hear about is current issues.
>Why is unearned trust of Verisign given by MF despite such incidents,
>while a Community Authority is assumed by MF in the first instance to be
>untrustworthy? MF forms a value judgement based on a comparison of market
>capitalisation between the two organisations, nothing more.
>
>
Er, no. That's manifestly wrong. They look
at the WebTrust. That's their metric.
And even if it wasn't, Verisign has a track
record of no failures in 10 years or so. CAcert
has a track record of ... months?
(Now, the reason why there are no failures
is because ... they don't count things like
phishing, which are spoofs that bypass the
certs. But, that isn't Verisign's fault, and
they are quite happily in accord with me on
this point - they are hamstrung in that they
cannot get the browser manufacturers to
listen. So I think they've sort of given up
and gone back to selling nonsense to banks.)
>... The browser is at the coal face of a user's
>security.
>
>
Well I agree with that. That's why phishing sucks.
>>(Did Verisign get their WebTrust renewed? I wrote WebTrust about the
>>conflict of interest but they never responded.)
>>
>>
>>
>>>The double standard expressed by David here epitomises the Mozilla
>>>Foundation's attitude throughout the eighteen months of discussion on
>>>this topic.
>>>
>>>
>>>
>>David has found a compromise that suits for now. It's not perfect, but
>>nobody can make the world perfect.
>>
>>
>
>Ah, the creed of the apathetic and the lethargic.
>
>
I imagine David is working on it in his spare time,
he's not being paid for it so we can't expect too
much. Unless you're referring to me, in which
case I'd invite you to browse http://iang.org/ssl/
and come back and discuss creeds.
>MF's approach is this;
>
>"Verisign paid for Webtrust, so they will be included no matter how many
>times their security is breached or their processes are shown to be
>insecure. CA-Cert in contrast, cannot be included without paying for
>WebTrust." I think that you will consider this an oversimplification but I
>contend that this is the root of the matter, based on eighteen months
>of watching MF prevaricate.
>
>
MF takes WebTrust. Yes it costs. So what? Your point is
that people who can't afford to pay the piper should get
a free ride? Perhaps we should go to the government and
ask for a handout?
You would be much better off concentrating on why a
costly model like WebTrust doesn't serve the browser
user ... rather than throwing out hand-me-down socialistic
misconceptions about The Man and his evil Dollar.
>I think that the CA-Cert people should ask themselves why they want to
>have their cert included in MF browsers. If they're interested in secure
>solutions they would do well to stay away from a browser so willing to
>prostitute itself to commercial entities at the expense of true security.
>
>
There isn't much choice. Simple market economics.
Mozilla's the #2 game in town, and at least they have
a mailing list where you can get shouted down. I
haven't even been able to track down who the Konqueror
people are (although they do have a security person,
albeit highly secure and hidden).
Simon Anderson
> Simon Anderson wrote:
>>"Verisign paid for Webtrust, so they will be included no matter how many
>>times their security is breached or their processes are shown to be
>>insecure. CA-Cert in contrast, cannot be included without paying for
>>WebTrust." I think that you will consider this an oversimplification but I
>>contend that this is the root of the matter, based on eighteen months
>>of watching MF prevaricate.
>>
>>
>
> MF takes WebTrust. Yes it costs. So what? Your point is
> that people who can't afford to pay the piper should get
> a free ride? Perhaps we should go to the government and
> ask for a handout?
>
> You would be much better off concentrating on why a
> costly model like WebTrust doesn't serve the browser
> user ... rather than throwing out hand-me-down socialistic
> misconceptions about The Man and his evil Dollar.
Ah, here we have it; Everyone must pay to play and anyone who wants free
software is a communist. Gates paraphrased here, in a newsgroup for an OSI
approved free software project, by you.
Despite your protestations otherwise elsewhere in this thread, we can
conclude now that you have illustrated the essential point.
-Simon.
Ian G
>On Wed, 02 Feb 2005 01:27:17 +0000, Ian G wrote:
>
>
>
>>>MF takes WebTrust. Yes it costs. So what? Your point is
>>>that people who can't afford to pay the piper should get
>>>a free ride? Perhaps we should go to the government and
>>>ask for a handout?
>>>
>>>You would be much better off concentrating on why a
>>>costly model like WebTrust doesn't serve the browser
>>>user ... rather than throwing out hand-me-down socialistic
>>>misconceptions about The Man and his evil Dollar.
>>>
>>>
>
>Ah, here we have it; Everyone must pay to play and anyone who wants free
>software is a communist. Gates paraphrased here, in a newsgroup for an OSI
>approved free software project, by you.
>
>
That's the meat in your "argument", yes. Now,
if you stopped hyperventilating for a moment,
you could consider why it is that this is a sucky
situation.
1. The presumption is that only a trusted third
party can authenticate people on the net,
2. the authentication is needed for secure
transactions,
3. this trusted third party has to be paid for
their efforts,
4. people are too dumb to know when to go to
this TTP, so they have to be forced to by the
way the software is constructed to not accept
any compromises,
5. the only thing we need is an authenticated
connection to secure credit cards (or was it
banking? maybe that's what it was).
6. as long as everyone does the right thing it
will work.
Now, every one of those statements is more or
less a foundation stone in secure browsing.
(There might be some I missed, it's late here.)
Here's the game: you get points if you manage
to take even one of those and show it to be
true, false, or somewhere in between.
>Despite your protestations otherwise elsewhere in this thread, we can
>conclude now that you have illustrated the essential point.
>
>
Right. The structure is pay to play. Everyone
knows that, I gather. But to shift away from
that current status quo requires more than
... er, what you're offering.
Julien Pierre
>> I'll assume that you're not being obtuse. This is the most well known
>> issue from Verisign;
>>
>> http://www.pcworld.com/news/article/0,aid,45284,00.asp
>>
>> This case allows anyone to make a value judgement on Verisign's services,
>> MF included. Please don't pretend otherwise.
>>
>>
>
> The facts outlined in that article are not an
> awful lot to hang ones hat on. The made a
> mistake, once, and it was 4.9 years ago. So,
> it's not a current issue, assuming the cert
> has expired.
Not only that, but even at the time, methods of revocation checking for
certificates existed, such as CRL and OCSP. None of this was mentioned
in the article.
One should be able to protect from such errors retroactively after they
are discovered once Verisign revokes the certificate, if the application
is configured to do a revocation check.
I'm not trying to defend verisign here, but this type of error needs to
be kept in perspective. If a cert gets improperly issued and is found
out like the above, then the risk is much lower . I'm more worried about
the cases in which nobody noticed. But unfortunately there are no
statistics for those .
Frank Hecker
> I believe that, until the Mozilla Foundation gives formal approval
> to the policy, Frank is approving only CA root certificates that
> have the WebTrust seal. This assumption is supported by the
> history of recent certificate approvals.
Actually, I approved QuoVadis on the basis of having undergone a
"WebTrust-equivalent" audit, and I am prepared to do so again for other CAs.
Frank
--
Frank Hecker
hec...@hecker.org
Frank Hecker
> Yet the Mozilla foundation has risked the security of it's
> user base by turning a blind eye to abuses from commercial CA's
> such as Verisign.
This reminds me of Rich Freeman's comment in bug 215243 about incumbent
CAs being held to lower standards than new entrants. For the record, I
think it would be useful to go through the initial CA list (i.e., the
one inherited from Netscape prior to the Mozilla Foundation getting
involved in this) and re-approve (or disapprove) those CAs. I haven't
done so for two reasons:
First, I have limited time, and what time I do have has been spent
handling new requests and working on the new policy. Second (and more
important) based on the evidence at hand I don't believe that there are
any real security problems related to existing CA certs in Mozilla. With
regard to VeriSign in particular, I agree with Ian Grigg's comments. If
others believe to the contrary that there is a "clear and present
danger" associated with including VeriSign CA certs in Mozilla, then
they're welcome to present evidence of this to the Mozilla security
group, per the process outlined in
http://www.mozilla.org/projects/security/security-bugs-policy.html
(And for the record, I think the evidence has to go beyond four-year old
reports about single incidents. Is there an pattern of such incidents?
Are there known current cases of "rogue" certs -- i.e., not expired? Any
evidence of exploits related to such certs? And so on...)
> For Mozilla, it's not about "trust" or "security." Rather, it's about "who
> pays." This stance is incompatible with community certification.
IMO it's more about "lack of time" and "laziness", in two senses:
First, I personally am to blame for not working on this more than I have
(though this is partly for reasons beyond my control, like family
commitments). But even beyond my personal failings, it's not trivial to
investigate CAs (assuming of course that they need to be investigated,
which we'll take as a given for the purposes of this argument). That's
why it's tempting to simply offload that task to WebTrust and third
parties like the firms authorized to do WebTrust audits, and why that
was done in the past. Going forward the intent is to move away from that.
Ian G
> Simon Anderson wrote:
>
>> Yet the Mozilla foundation has risked the security of it's
>> user base by turning a blind eye to abuses from commercial CA's
>> such as Verisign.
>
>
> This reminds me of Rich Freeman's comment in bug 215243 about
> incumbent CAs being held to lower standards than new entrants. For the
> record, I think it would be useful to go through the initial CA list
> (i.e., the one inherited from Netscape prior to the Mozilla Foundation
> getting involved in this) and re-approve (or disapprove) those CAs. I
> haven't done so for two reasons:
>
> First, I have limited time, and what time I do have has been spent
> handling new requests and working on the new policy.
I agree with all that. For the sake of the credibility
of the policy, this has to remain an agenda item, if
only to warn CAs not to be complacent :) Whether
you *ever* have time is an open question, which is
just another reason why I think inevitably there will
be a drift towards an asymmetric CA policy (where
not all CAs are equal). It's the only way to manage
the divergent requirements, economically speaking.
> IMO it's more about "lack of time" and "laziness", in two senses:
> First, I personally am to blame for not working on this more than I
> have (though this is partly for reasons beyond my control, like family
> commitments). But even beyond my personal failings, it's not trivial
> to investigate CAs (assuming of course that they need to be
> investigated, which we'll take as a given for the purposes of this
> argument). That's why it's tempting to simply offload that task to
> WebTrust and third parties like the firms authorized to do WebTrust
> audits, and why that was done in the past. Going forward the intent is
> to move away from that.
The concept of using a reputable firm to 'check
the books' of a company derives from the old
days where to actually get to the books required
amounts of travelling and quite specialised
knowledge in accounting and so forth.
These days we have the net. We also have a
whole host of idle experts out there. In the
Digital currency world we promote what we
call open governance where the users are
responsible for auditing the institutions. It
is an evolving concept, not without controversy,
but it does do one thing extraordinarily well:
it allows trust to be aggregated and disseminated
without large amounts of money being spent, and
without relying on excessive secrecy.
Frank Hecker
certificate list:
> For the sake of the credibility
> of the policy, this has to remain an agenda item, if
> only to warn CAs not to be complacent :)
For the record, I agree, and I believe I explicitly noted this in the
last draft policy.
> Whether
> you *ever* have time is an open question, which is
> just another reason why I think inevitably there will
> be a drift towards an asymmetric CA policy (where
> not all CAs are equal). It's the only way to manage
> the divergent requirements, economically speaking.
By "asymmetric CA policy" are you referring to the issue of how we treat
incumbent CAs vs. new applicants, or to some other division of CAs into
different classes?
> The concept of using a reputable firm to 'check
> the books' of a company derives from the old
> days where to actually get to the books required
> amounts of travelling and quite specialised
> knowledge in accounting and so forth.
>
> These days we have the net. We also have a
> whole host of idle experts out there. In the
> Digital currency world we promote what we
> call open governance where the users are
> responsible for auditing the institutions. It
> is an evolving concept, not without controversy,
> but it does do one thing extraordinarily well:
> it allows trust to be aggregated and disseminated
> without large amounts of money being spent, and
> without relying on excessive secrecy.
Again for the record, I understand the point you're making, and I am
sympathetic to your vision. However I would make the following
counter-points:
If CAs retain their present role (the world doesn't move to the
self-signed model you advocate) and CA activities are undertaken
primarily by formal commercial entities, then while there may be a
"whole host of idle experts" out there with an interest in how CAs
operate, there won't be sufficient transparency to let them properly
evaluate CAs, and "open governance" will be a non-starter.
Now if in the future we continue to have CAs in the present sense, but
we see CA activities be taken on by more and more non-profit groups like
CAcert, then your vision would have more of a chance of being realized.
However this still would depend on the non-profit groups being more open
than the current commercial entities, and we can't necessarily assume
this a priori. (In the wider world of nonprofits there are groups that
are just as nontransparent as commercial companies.)
Even if there is more transparency with nonprofit CAs then a move to a
more open and less formal model of CA governance and evaluation would be
a major cultural shift given the history of PKI and CAs. As someone who
is by temperament a reformer rather than a revolutionary, and whose
scope of action is limited by the need to achieve at least a rough
consensus, my approach is therefore to move forward incrementally (but
move forward nonetheless).
Ian G
> Ian G wrote re reviewing "incumbent" CAs in the pre-loaded CA
> certificate list:
> ...
>
>> Whether
>> you *ever* have time is an open question, which is
>> just another reason why I think inevitably there will
>> be a drift towards an asymmetric CA policy (where
>> not all CAs are equal). It's the only way to manage
>> the divergent requirements, economically speaking.
>
>
> By "asymmetric CA policy" are you referring to the issue of how we
> treat incumbent CAs vs. new applicants, or to some other division of
> CAs into different classes?
Just a point of clarification, I am referring to the
general division of CAs into whatever class we
pick. Such as trusted or untrusted, American,
Eurooean, other, industry specific or broad based,
expensive or cheap, new or old, reviewed recently
or not.
That is, the notion that "all CAs are the same" is
being replaced with "all CAs are different."
Gervase Markham
> In Mozilla bug #215243, a lengthy debate has begun (via bug
> comments) whether CAcert's root certificate belongs in the Mozilla
> certificate database.
I spent a little time reading CAcert's website, and it seems to me that
their policies mean they would not be a good inclusion in Mozilla.
At the moment, the fact that someone has to make at least some effort to
prove that they are who they say they are, and provide verifiable
contact details, is the only mechanism (however weak it may be) that we
have for tracking sites to people. If a phishing site is forced to buy
an SSL cert to make themselves more genuine, there is at least some sort
of audit trail back to the phisher.
CAcert's policy of giving certs to anyone with a working email address
undermines this. This reduces the amount of verification a cert gives to
"if I see www.amazon.com in the URL bar, I'm on www.amazon.com". And,
with the new punycode-based identical-glyph character attacks, that's
currently no guarantee at all.
Gerv
Gervase Markham
> I'll assume that you're not being obtuse. This is the most well known
> issue from Verisign;
>
> http://www.pcworld.com/news/article/0,aid,45284,00.asp
So any CA which makes a single issuing mistake should be removed from
the database?
Gerv
Frank Hecker
> CAcert's policy of giving certs to anyone with a working email address
Gerv, I'll let others give the definitive answer to this, but a number
of CAs will issue certificates based solely on verification of a working
email address. This is usually done for individual email certificates,
but it's possible that some CAs will do this for SSL server certificates
as well, at least for "free trial" evaluations and "test" certificates.
Gervase Markham
OK, fair enough. Obviously, I can see the point of issuing email certs
based on an email address ;-) But I think issuing any sort of SSL server
cert without some sort of audit trail which allows you to track down the
person responsible for the server is a bad idea. And if existing CAs are
doing it, they should be encouraged to stop.
Gerv
Ian G
> ... But I think issuing any sort of SSL server cert without some sort
> of audit trail which allows you to track down the person responsible
> for the server is a bad idea. And if existing CAs are doing it, they
> should be encouraged to stop.
Why do you think that a phisher would care about
any of that if they needed a cert? Phishers are
already expert at leaving audit trails that go nowhere,
and any industrial scale audit system by the CAs will
be easy meat for them, IMHO.
Jean-Marc Desperrier
> Frank Hecker wrote:
> > Gerv, I'll let others give the definitive answer to this, but a number
> > of CAs will issue certificates based solely on verification of a working
> > email address. This is usually done for individual email certificates,
> > but it's possible that some CAs will do this for SSL server certificates
> > as well, at least for "free trial" evaluations and "test" certificates.
>
> cert without some sort of audit trail which allows you to track down the
> person responsible for the server is a bad idea. And if existing CAs are
> doing it, they should be encouraged to stop.
Major CAs are using separate roots for the test and free trial
certificates, and those are not included in Mozilla's root certificate list.
If other CA are delivering certificate so easily under an approved root,
I think it would be a very valid reason to request removal of their root
CA cert from the list.
Frank Hecker
> Obviously, I can see the point of issuing email certs
> based on an email address ;-) But I think issuing any sort of SSL server
> cert without some sort of audit trail which allows you to track down the
> person responsible for the server is a bad idea. And if existing CAs are
> doing it, they should be encouraged to stop.
Another quick comment, not specific to CAcert but just a general comment
about the role of CAs in relation to phishing:
IMO the issue of authenticating the identity of certificate applicants
is to a large degree orthogonal to the issue of preventing phishing
attacks based on misleading domain names. It's perfectly possible to
imagine a CA granting an SSL certificate to a company with a misleading
domain name (i.e., designed to be confused with a more well-known domain
name) based on documents being provided that appear to validate that the
company in question actually exists and owns the domain in question. I
don't think a CA would be violating either its own policies or the
WebTrust criteria by doing so, and it's certainly possible to imagine
CAs "looking the other way" in accepting and approving such certificate
requests. (It's similar to the problem of domain name registrars issuing
confusing domain names in the first place.)
For that matter, based on my reading of the WebTrust criteria, I don't
believe that they actually require "strong" authentication of the
identity of certificate applicants. IIRC the criteria require simply
that the CA authenticate applicant identity in conformance with its
stated Certificate Policy and Certification Practices Statement, and the
CP and CPS could conceivably specify fairly "weak" authentication. The
onus would then be on the person actually encountering the certificate
(e.g., the Mozilla user surfing to an SSL-enabled site) to verify that
the level of authentication is sufficient for theiri purposes. (This is
formalized in the CA's Relying Party Agreement, which is analogous to an
EULA in some ways.) This is how WebTrust-audited CAs "get away with"
offering individual certificates based solely on authentication via
email, and I don't see why this wouldn't apply to SSL server
certificates as well.
Frank Hecker
> Major CAs are using separate roots for the test and free trial
> certificates, and those are not included in Mozilla's root certificate
> list.
For the record, this is not universally true. For example, I believe
that Comodo issues their "InstantSSL" trial certificates under their
main root. However they do require extra proof of identity when applying
for evaluation certs, I believe the same stuff they require for "real"
certs; they do not issue certs just based on verification of email address.
Ian G
>
> IMO the issue of authenticating the identity of certificate applicants
> is to a large degree orthogonal to the issue of preventing phishing
> attacks based on misleading domain names. It's perfectly possible to
> imagine a CA granting an SSL certificate to a company with a
> misleading domain name...
Right. This is one reason why the branding ideas
of Amir & Ahmad converge with my ideas so that
both the site's logo and the CA's logo appear on
the chrome. It doesn't stop a CA issuing a duff
cert, but if VeriSign were to issue a diff cert spoofing
an existing customer, it would be a much more serious
thing than if Comodo were fooled over a Verisign
customer.
So, if the CA logo is also showed with the site logo,
then the user will police the space between the CAs,
by noticing the CA has changed. And the CA will
police the space within its own cert-buying space,
by matching all requests to its existing customers.
David Stutzman
> At the moment, the fact that someone has to make at least some effort
> to prove that they are who they say they are, and provide verifiable
> contact details, is the only mechanism (however weak it may be) that
> we have for tracking sites to people. If a phishing site is forced
> to buy an SSL cert to make themselves more genuine, there is at least
> some sort of audit trail back to the phisher.
> CAcert's policy of giving certs to anyone with a working email
> address undermines this. This reduces the amount of verification a
> cert gives to "if I see www.amazon.com in the URL bar, I'm on
> www.amazon.com". And, with the new punycode-based identical-glyph
> character attacks, that's currently no guarantee at all.
You're making it seem like CAcert will issue SSL certs for any domain to
"anyone with a working email address".
For them to issue you an SSL cert you have to add the domain to your
account. When you want to add a domain you put in the domain name
(example.com) and then it offers you a choice of verification addresses of:
ro...@example.com
hostmasterexample.com
postm...@example.com
ad...@example.com
webm...@example.com
which it then sends an email to the chosen address. In the browser it says:
The domain 'example.com' has been added to the system, however before
any certificates for this can be issued you need to open the link in a
browser that has been sent to your email address.
The contents of the email are as follows:
Below is the link you need to open to verify your email address. Once
your address is verified you will be able to start issuing certificates
till your hearts' content!
<link snipped cause it was of my actual domains>
Best regards
CAcert.org Support!
This means I can't start getting amazon.com ssl certs unless I have
control over one of the administrative email boxes of amazon.com and if
*that* is the case then either I work for Amazon and this is valid or
Amazon has other things to worry about than rogue sites such as their
email system's security. CAcert's policy with SSL certs is just that you
have to have control of the domain to get certs for it.
As to their email certs, they don't put your real name on the cert until
your identity is verified by at least 2 people in their "web of trust"
PGP style. It just says "CAcert User Cert".
I'm not saying they should or shouldn't be included. I'm just trying to
make sure they're not being mis-represented. I would like them to be
included, but I doubt they ever will be.
-Dave
Frank Hecker
> This means I can't start getting amazon.com ssl certs unless I have
> control over one of the administrative email boxes of amazon.com
I don't want to speak for Gerv, but I don't believe he's concerned about
CAcert or other CAs issuing fraudulent SSL certs for "amazon.com", he's
concerned about CAs issuing SSL certs for misleading domain names like
"amaz0n.com". (This is a "toy" example, a more real-world example would
involve a domain using Unicode characters that are not in the Latin1 set
but happen to look like "a", "m", "z", etc., in terms of their visual
appearance to the user -- the so-called "punycode" attack.)
I think the key issues here are as follows:
1. As a general question, can or should CAs do anything to detect
requests associated with misleading domains of the type that might be
associated with phishing attacks?
2. What (if anything) can and should we (the Mozilla project in general,
and the Mozilla Foundation in particular) do with regard to this? (For
example, would this warrant putting additional requirements on CAs whose
certs are pre-loaded into Firefox, etc?)
In this regard I've already expressed my opinion that our requiring
WebTrust audits or even "strong" verification of applicants by CAs does
not necessarily address the phishing problem in this context. But of
course others are welcome to add their own thoughts on this...
Alex Wight
> 1. As a general question, can or should CAs do anything
> to detect requests associated with misleading domains of
> the type that might be associated with phishing attacks?
I believe the main purpose of any SSL CA is simply to vouch for domain name
ownership (how they do this is beside my point). If any efforts are done to
limit or prohibit misleading domains, I feel it should be done at the
registrar level. Doing it at the CA level will only limit phishing for
sites that use SSL, whereas enforcement at the registrar would limit
phishing on regular HTTP sites, SSL, FTP, etc... In my opinion putting the
onus on the registrars is the right place to enforce it to start a
trickle-down effect that would eventually protect CAs (and users) from
having to worry about things like this.
Frank Hecker wrote:
> 2. What (if anything) can and should we (the Mozilla
> project in general, and the Mozilla Foundation in
> particular) do with regard to this? (For example, would
> this warrant putting additional requirements on CAs whose
> certs are pre-loaded into Firefox, etc?)
I would only suggest that we use our collective influence to try and get a
reasonable policy adopted by ICANN which will define and enforce acceptable
limits of similarity to already registered domains. Tough nut to crack, I
know, but I feel it's the right place to start. Any enforcement at lower
levels (like an SSL CA) is, in my humble opinion, a band-aid-like fix that
doesn't go to the root of the problem.
-Alex
Simon Anderson
reductio ad absurdum.
A CA which has demonstrated mistakes in the past should not receive
preferential treatment.
[Commercial CA + Webtrust + errors] should not outweigh [Community CA + no
errors.]
-Simon.
Ian G
>A CA which has demonstrated mistakes in the past should not receive
>preferential treatment.
>
>[Commercial CA + Webtrust + errors] should not outweigh [Community CA + no
>errors.]
>
>
Time == track record == errors.
!track record == !errors.
Ian G
>It helps if you think of
>phishing as a tax on stupidity ;-)
>
>
LOL! Until the file the class action, that is...
Ian G
> David Stutzman wrote:
>
>> This means I can't start getting amazon.com ssl certs unless I have
>> control over one of the administrative email boxes of amazon.com
>
>
> I don't want to speak for Gerv, but I don't believe he's concerned
> about CAcert or other CAs issuing fraudulent SSL certs for
> "amazon.com", he's concerned about CAs issuing SSL certs for
> misleading domain names like "amaz0n.com".
Yes, I'd say that is the issue. Bear in mind that
this is *not* happening now as it is too easy to
attack without using SSL at all. The name of the
game is to force the phishers into using SSL, in
which case the obvious attack is for phishers to
acquire amaz0n.com as a cert issued by noname.com.
> I think the key issues here are as follows:
>
> 1. As a general question, can or should CAs do anything to detect
> requests associated with misleading domains of the type that might be
> associated with phishing attacks?
I think it reasonable to ask them to detect for
misleading domains amongst their own customers.
> 2. What (if anything) can and should we (the Mozilla project in
> general, and the Mozilla Foundation in particular) do with regard to
> this? (For example, would this warrant putting additional requirements
> on CAs whose certs are pre-loaded into Firefox, etc?)
In terms of requirements, I can't think of one that
a phisher would be dismayed by. If they cared, that
is. Even if they have trouble picking up their own
certs, about 20k boxes are hacked every month,
leading to plenty of stolen valid certs.
> In this regard I've already expressed my opinion that our requiring
> WebTrust audits or even "strong" verification of applicants by CAs
> does not necessarily address the phishing problem in this context. But
> of course others are welcome to add their own thoughts on this...
Simon Anderson
> Simon Anderson wrote:
>
>>A CA which has demonstrated mistakes in the past should not receive
>>preferential treatment.
>>
>>[Commercial CA + Webtrust + errors] should not outweigh [Community CA + no
>>errors.]
>>
>>
>
> Time == track record == errors.
>
> !track record == !errors.
CA-Cert has (despite your assertion to the contrary) been operating for
two years, during which time there has been no equivalent error. In an
equivalent time since conception, Verisign had errors where CA-Cert has
not.
So if you were to take a moment to compare apples with apples and set
aside your anti-free bias, you would conclude that CA-Cert has the better
track record.
But of course this is a pointless discussion. People such as yourself and
others in and around the MF have made (and will continue to make) absurd
statements to continuously 'shift the goal posts' in favour of commercial
CAs and to the disfavour of community CAs. For this reason, CA-Cert is
wasting it's time and scant resources jumping though endless hoops
pursuing browser inclusion with MF.
-Simon.
Simon Anderson
> Simon Anderson wrote:
>> Yet the Mozilla foundation has risked the security of it's
>> user base by turning a blind eye to abuses from commercial CA's
>> such as Verisign.
>
> This reminds me of Rich Freeman's comment in bug 215243 about incumbent
> CAs being held to lower standards than new entrants. For the record, I
> think it would be useful to go through the initial CA list (i.e., the
> one inherited from Netscape prior to the Mozilla Foundation getting
> involved in this) and re-approve (or disapprove) those CAs. I haven't
> done so for two reasons:
>
> First, I have limited time, and what time I do have has been spent
> handling new requests and working on the new policy. Second (and more
> important) based on the evidence at hand I don't believe that there are
> any real security problems related to existing CA certs in Mozilla. With
> regard to VeriSign in particular, I agree with Ian Grigg's comments. If
> others believe to the contrary that there is a "clear and present
> danger" associated with including VeriSign CA certs in Mozilla, then
> they're welcome to present evidence of this to the Mozilla security
> group, per the process outlined in
>
> http://www.mozilla.org/projects/security/security-bugs-policy.html
Removing Verisign is not in CA-Cert's interest. MF treating CA-Cert and
Verisign equitably is.
>> For Mozilla, it's not about "trust" or "security." Rather, it's about
>> "who pays." This stance is incompatible with community certification.
>
> IMO it's more about "lack of time" and "laziness", in two senses: First,
> I personally am to blame for not working on this more than I have
> (though this is partly for reasons beyond my control, like family
> commitments). But even beyond my personal failings, it's not trivial to
> investigate CAs (assuming of course that they need to be investigated,
> which we'll take as a given for the purposes of this argument). That's
> why it's tempting to simply offload that task to WebTrust and third
> parties like the firms authorized to do WebTrust audits, and why that
> was done in the past. Going forward the intent is to move away from that.
That all sounds lovely.
After 18 months, "laziness" and "lack of time" are euphemisms for
"complete disinterest." What you seem to be saying here is "wait a little
longer, things will change." I think that this is unhelpful as it
encourages CA-Cert to continue dealing with MF when, if we're honest about
it, CA-Cert would benefit from focusing their efforts elsewhere.
It will be ironic if it transpires that a commercial browser grants
CA-Cert (or another community CA) with inclusion.
-Simon.
Frank Hecker
> After 18 months, "laziness" and "lack of time" are euphemisms for
> "complete disinterest." What you seem to be saying here is "wait a little
> longer, things will change." I think that this is unhelpful as it
> encourages CA-Cert to continue dealing with MF when, if we're honest about
> it, CA-Cert would benefit from focusing their efforts elsewhere.
I know it's easy to believe that there's some sort of conspiracy (e.g.,
between the Mozilla Foundation and commercial CAs) to keep CAcert's
certificate out of Firefox, etc., but I am not a party to such a
conspiracy. You might say in return, "of course he'd say that, that's
the way conspiracies work". I can only refer you to others who have had
dealings with me -- including the people participating in this forum,
any of whom you are welcome to email privately -- and they can give you
their unvarnished opinions as to the extent to which you can trust me to
speak the truth (at least as I see it).
Now, assuming that you're not totally discounting what I have to say,
here are my personal views on the CAcert issue:
The basic problem is that CAcert is attempting something new and a lot
of people find that disconcerting and potentially dangerous, because it
doesn't necessarily fit into the traditional CA model that they're used
to and have been working with for many years. There's also the issue
that because in some ways CAcert is more transparent than a traditional
commercial CA, people know more about CAcert-internal controversies and
the like, and this further reinforces any concerns they might have
already had.
Again, you may believe this or not, but even though I am designated by
the Mozilla Foundation to handle the task of approving CAs for inclusion
in Firefox, etc., I cannot simply arbitrarily dictate, "yes, CAcert
should be included". The Mozilla project is not a top-down dictatorship
where the Mozilla Foundation issues orders and everyone meekly obeys;
it's also not like a company where the Mozilla Foundation can issue
orders, fire anyone who disobeys, and hire new people to replace them.
If the decision in question is controversial (as is this one) then we
have to work through the controversy to try to build a rough consensus
around some sort of position that's at least minimally acceptable to the
people who care about the issue and have a stake in it.
(Historical note: We went through a analogous exercise trying to decide
what sort of policy we should have with regard to disclosing security
vulnerabilities. I and others were sympathetic to the "full disclosure"
position, but we couldn't simply dictate such a policy, because there
were key Mozilla developers and corporate sponsors who were viscerally
opposed to full disclosure. Instead we had to engage in a long drawn-out
effort to reach a compromise -- which eventually we did.)
I don't think it's any secret (based on my past postings to this group)
that I am sympathetic to the idea of non-profit "community" CAs in
general, because I don't think the traditional PKI approach has
necessarily served typical users well (for various reasons I don't have
time to go into right now), and I think alternative approaches deserve
some consideration. Given that, how should I proceed with regard to
non-traditional CAs in general and CAcert in particular? I can't just
say "yes, let's include CAcert"; I have do things within the framework
of some justifiable policy.
Here are some possibilities for such a policy, in rough chronological
order of my having considered them:
1. We adopt a laissez-faire approach where we include certs for any CA
that requests it, subject only to some minimal requirements (e.g.,
related to CA disclosure). This is similar to Ian Grigg's position on
accepting self-signed certs and "opportunistic crytography". While I
respect Ian's opinions (even when I disagree with him), I can tell you
that this approach is a "non-starter" in the current environment, just
as adopting a 100% full disclosure policy was a non-starter at the time
that we were formulating the policy on handling Mozilla security
vulnerabilities.
2. We don't have a laissez-faire approach, but instead try to come up
with some reasonable set of criteria that we (the Mozilla Foundation and
the project in general) can use to evaluate CAs. I tried this approach,
but the problem was/is that we got bogged down trying to formulate such
criteria, particularly trying to do it from scratch. So this is a
non-starter as well.
3. We go the traditional PKI route, adopt the WebTrust for CAs criteria
as our standard, and require formal WebTrust audits. This is the
position I retreated to when it become clear that creating our own
criteria wasn't working, and I had a growing backlog of CA requests to
deal with.
4. We loosen up a little bit on the WebTrust requirement, and allow for
"WebTrust-equivalent" audits. This is the Microsoft policy, and it's
also the interim policy I'm currently applying.
5. We formalize the "WebTrust or equivalent audit" policy, and do so in
such a way that it allows for the possibility that such audits may be
done by people other than the usual suspects (e.g., E&Y, KPMG, etc.)
This is the approach I'm working on right now, and it's the approach
that's motivating David Ross to look at doing such an audit for CAcert.
The chief obstacles remaining are nailing down the language for such a
policy, and reaching at least a rough consensus on proceeding with it.
(There's also the issue of getting the Mozilla Foundation to formally
adopt it, but I think that will be relatively easy if there's a
consensus around the proposed policy.)
So that's basically where things stand. Some of the delay in getting to
this point has been my lack of time, but some has also been due to my
having to go back to the drawing board multiple times in search of a
workable approach.
A final point: CAcert is not being singled out in having its application
be left in limbo; there are a number of CA requests that are still in
the pending state -- and may remain there for a while -- because they
either haven't undergone audits as required by the current interim
policy, or because I haven't yet had the time to conclude whether their
audits can be considered "WebTrust-equivalent" or not.
That's basically all I have to say at the moment; feel free to post to
this forum if you have further questions or comments.
Ian G
>After 18 months, "laziness" and "lack of time" are euphemisms for
>"complete disinterest." What you seem to be saying here is "wait a little
>longer, things will change." I think that this is unhelpful as it
>encourages CA-Cert to continue dealing with MF when, if we're honest about
>it, CA-Cert would benefit from focusing their efforts elsewhere.
>
>It will be ironic if it transpires that a commercial browser grants
>CA-Cert (or another community CA) with inclusion.
>
>
You seem to be assuming that every other browser
will be in some sense fairer than MF. AFAIK, every
other browser requires WebTrust or some equivalent.
Are any other browser manufacturers working to
open up the CA root list?
iang
--
News and views on what matters in finance+crypto:
Ian G
>
> (Historical note: We went through a analogous exercise trying to
> decide what sort of policy we should have with regard to disclosing
> security vulnerabilities. I and others were sympathetic to the "full
> disclosure" position, but we couldn't simply dictate such a policy,
> because there were key Mozilla developers and corporate sponsors who
> were viscerally opposed to full disclosure. Instead we had to engage
> in a long drawn-out effort to reach a compromise -- which eventually
> we did.)
Side question: the economics of disclosure is a current
research are for myself and Adam Shostack ... are there
any summaries of the positions of the opposing camps
on that debate? I've read the security page you posted
the other day, and it certainly hints at the compromise
you suggest.
iang
http://www.emergentchaos.com/archives/000855.html
http://www.financialcryptography.com/mt/archives/000319.html
Frank Hecker
> I know it's easy to believe that there's some sort of conspiracy (e.g.,
> between the Mozilla Foundation and commercial CAs) to keep CAcert's
> certificate out of Firefox, etc., but I am not a party to such a
> conspiracy.
One more point worth noting: In defending myself against the charge that
I'm part of an "anti-CAcert" conspiracy, I realize that I may leave
myself open to the charge that I'm part of a "pro-CAcert" conspiracy.
For the record, my goal of this whole policy exercise is niether to keep
putting barriers in place to keep CAcdrt out, nor to keep bending the
rules until CAcert can slip in.
Rather my goal is for us to come up with a policy that a) is in line
with the overall goal of promoting security for typical Mozilla users,
b) treats CAs reasonably equally and doesn't unnecessarily discriminate
against new CAs that may not conform to the traditional commercial PKI
model, and c) can achieve at least a rough consensus among the people
who have an interest and stake in this matter.
Ian G
>
> 1. We adopt a laissez-faire approach where we include certs for any CA
> that requests it, subject only to some minimal requirements (e.g.,
> related to CA disclosure). This is similar to Ian Grigg's position on
> accepting self-signed certs and "opportunistic crytography".
Ah, well, *I* wouldn't say it is similar. But related,
yes, within the overall framework of management
of the user's relationships.
The thing to bear in mind is that these aren't
political ideals or visions, they are security proposals.
Each of those proposals leads directly or indirectly
to greater security for users.
Right now, the strategy is all around phishing. It's
roughly this:
* force phishers to have to use an SSL cert.
* be ready to deal with stolen and fraudulently
issued certs.
No browser is ready for the second part. Which is
lucky because no browser does the first part.
> While I respect Ian's opinions (even when I disagree with him), I can
> tell you that this approach is a "non-starter" in the current
> environment, just as adopting a 100% full disclosure policy was a
> non-starter at the time that we were formulating the policy on
> handling Mozilla security vulnerabilities.
:-) It's all about security..
iang
Ian G
> Frank Hecker wrote:
>
>> I know it's easy to believe that there's some sort of conspiracy
>> (e.g., between the Mozilla Foundation and commercial CAs) to keep
>> CAcert's certificate out of Firefox, etc., but I am not a party to
>> such a conspiracy.
>
>
> One more point worth noting: In defending myself against the charge
> that I'm part of an "anti-CAcert" conspiracy, I realize that I may
> leave myself open to the charge that I'm part of a "pro-CAcert"
> conspiracy. For the record, my goal of this whole policy exercise is
> niether to keep putting barriers in place to keep CAcdrt out, nor to
> keep bending the rules until CAcert can slip in.
It shouldn't need to be said, but I suppose it has
to in this world of aggressive bluster and threats
of favouritism leading to court appearances over
specious claims.
> Rather my goal is for us to come up with a policy that a) is in line
> with the overall goal of promoting security for typical Mozilla users,
> b) treats CAs reasonably equally and doesn't unnecessarily
> discriminate against new CAs that may not conform to the traditional
> commercial PKI model, and c) can achieve at least a rough consensus
> among the people who have an interest and stake in this matter.
I would order it a) security for typical users,
then b) the rough consensus. Whereas only
the rough consensus leads to further security
being delivered so these will work together.
On b) treating CAs with equality.
MF is a private organisation, with the goal
of delivering (secure) software to its users.
It owes nothing to CAs, neither fairness nor
responsibility.
The only reason to treat CAs fairly would be
if it assisted in goal a) which it may very well
do.
But there are limits. If I as a CA know that
your goal is to treat all CAs fairly, I can
abuse that (look at some of the shenanigans
that go on with antitrust suits in court in
MF's neighbourhood where ICANN maybe
by nature of its 'public role' may feel the
need to treat all contenders equally).
I don't see it as being unreasonable to drop
a CA on the grounds of it being too much
trouble to treat 'fairly'. CAs may be put out
at this, but let them make a case for why
they should be treated other than as giving
a security benefit to users.
Just IMHO!
iang
PS: For those with a political/economics leaning,
the notion of treating people in business with
equality is a sort of hangover myth from the
days of socialism, where corporations were
given monopolies in service, in exchange for
a guarunteed package of subsidies and a
requirement to treat all customer equally.
In the free market alternative, there is no
requirement to treat anyone fairly, and in
fact there are many benefits in not doing so.
For example one occasionally reads of 'firing
the expensive customers' or supermarkets
using tracking software to provide bad
service to people who are too canny to
deliver a profit.
Ian G
>I believe the main purpose of any SSL CA is simply to vouch for domain name
>ownership (how they do this is beside my point).
>
We wish! But, no, check it out:
"This holiday season, enable customers to transact
securely online, offline and over mobile devices."
SSL was _purposed_ to protect credit card and other
transactions (these days, primarily online banking).
A CA "Issues SSL Certificates to enable authenticated,
128-bit SSL encryption that secure e-commerce and
online payments across the internet."
If it was simply to vouch for domain ownership, then
we could do that the way Tucows and other registrars
do it by sending an email. This would be wonderful,
and would save everyone a lot of money and time.
(Which is what CACert is doing! There's no reason
why anyone can't do it on the fly...)
But that's not what CAs were set up for, originally.
>If any efforts are done to
>limit or prohibit misleading domains, I feel it should be done at the
>registrar level. Doing it at the CA level will only limit phishing for
>sites that use SSL,
>
Recall, phishing is an attack against commerce.
SSL was meant to protect commercial activities.
If SSL is not intended to stop things like spoofing
domains (phishing) to the user, what is it for?
If we fix phishing (and fraud in general) by changes
in the domain system, does that mean we can stop
using SSL?
>I would only suggest that we use our collective influence to try and get a
>reasonable policy adopted by ICANN which will define and enforce acceptable
>limits of similarity to already registered domains. Tough nut to crack, I
>know, but I feel it's the right place to start. Any enforcement at lower
>levels (like an SSL CA) is, in my humble opinion, a band-aid-like fix that
>doesn't go to the root of the problem.
>
>
This is really wierd. The SSL CA promises trust.
Go check it out on the websites of the CAs **.
Yet, you are suggesting that ... anybody but the CAs
should be responsible for controlling of potentially
fraudulent domain activities? To date, anyone can
create any domain. All the domain system does is
create a record for name-IP translation and record
who owns that name. Is that the system you want
to change?
iang
** Whoops! Spoke to soon ... has anyone noticed
that Verisign have dropped the word 'trust' from
their logo and site?
Frank Hecker
> Side question: the economics of disclosure is a current
> research are for myself and Adam Shostack ... are there
> any summaries of the positions of the opposing camps
> on that debate?
I don't believe that there is any single document that contains a
complete summary of the arguments for and against full disclosure of
security vulnerabilities. However I did post at least one message that
both addresses the arguments for full disclosure and also touches on the
sort of "economics of disclosure" issues that you and Adam are
interested in:
http://groups-beta.google.com/group/netscape.public.mozilla.security/msg/f0839d0487a76b9a
(I couched this in probabalistic terms: how do you maximize the chances
of fixing security vulnerabilities while minimizing the damage to users
resulting from such vulnerabilities, with the independent variable being
the number of people to which the vulnerability is disclosed.)
If you're interested in this topic you might check out the following
threads from netscape.public.mozilla.security:
(This is not necessarily a complete record of the discussion, just the
results of a few minutes searching Google.)
Incidentally, note that the initial discussions on this topic took place
in March 2000, and we didn't come to agreement on a final policy until
November 2001, 18 months later.
Frank Hecker
> On b) treating CAs with equality.
>
> MF is a private organisation, with the goal
> of delivering (secure) software to its users.
> It owes nothing to CAs, neither fairness nor
> responsibility.
>
> The only reason to treat CAs fairly would be
> if it assisted in goal a) which it may very well
> do.
Your point has some validity, hence should be addressed. I see treating
CAs equally (as much as that's possible) as useful in part because it
makes it easier to justify policy decisions and reach consensus on them,
vs. adopting a policy that intentionally discriminates against
particular CAs either by name or as a class. It also happens to be the
case that the Mozilla Foundation, while a private organization,
nevertheless as a non-profit organization with special tax status by law
has an obligation to serve some public purpose, and nondiscrimination in
this and other matters is IMO consistent with that.
Gervase Markham
> IMO the issue of authenticating the identity of certificate applicants
> is to a large degree orthogonal to the issue of preventing phishing
> attacks based on misleading domain names.
It is. My point is not that CAs should be refusing certificates to
people with "similar" domains, but that they should be keeping info to
allow the people to be tracked down if they are nefarious. This is not
just about phishing - it's also about dodgy web shops etc.
So it's about retribution, not prevention.
Gerv
Gervase Markham
> Yes, I'd say that is the issue. Bear in mind that
> this is *not* happening now as it is too easy to
> attack without using SSL at all.
Indeed. There has to be a minimum level of user education - that's
unavoidable. What we are trying in Firefox is to get people to look at
the status bar. Currently, the UI to look at is the lock and the domain
name. In the future, there may need to be a little more, but we should
keep the amount to a bare minimum.
> The name of the
> game is to force the phishers into using SSL, in
> which case the obvious attack is for phishers to
> acquire amaz0n.com as a cert issued by noname.com.
Indeed. Once people are checking for SSL and glancing at domain names,
at least, this will be where the phishers move.
Gerv
Gervase Markham
> I believe the main purpose of any SSL CA is simply to vouch for domain name
> ownership (how they do this is beside my point). If any efforts are done to
> limit or prohibit misleading domains, I feel it should be done at the
> registrar level. Doing it at the CA level will only limit phishing for
> sites that use SSL, whereas enforcement at the registrar would limit
> phishing on regular HTTP sites, SSL, FTP, etc...
While this is true, economic arguments make it extremely unlikely that
this will ever happen at the registrar level.
.com domains cost < $5 per year in bulk, and it's a market with massive
competition and lots of automation. $5 is not sufficient for a registrar
to do any serious checking. It's probably not enough to even have a
human scan the name and see if it matches a 'famous' site they know of.
SSL certificates cost $400, are issued by a smaller number of companies,
and are used to protect financial transactions. There is a stronger onus
on the CAs to know who they are handing them out to.
In addition, any scheme is realistically going to be a post-hoc one -
where phishes are identified, and the perpetrators tracked down from
information on file. Denying domains or certificates to people "because
it's too similar to an existing domain" would cause an outcry. And how
do you measure "too similar"?
The chance of getting to a world where the CA keeps the info necessary
to go after phishers is much, much higher than the chance of getting the
registrars to do something.
Anyway, if you don't have SSL, you are vulnerable to DNS spoofing
anyway, so you can never be certain you are at the right site, whatever
the URL bar says.
Gerv
Gervase Markham
> Right. This is one reason why the branding ideas
> of Amir & Ahmad converge with my ideas so that
> both the site's logo and the CA's logo appear on
> the chrome.
I don't want to get into the branding debate again, but if Verisign
issue a cert to "www.amaz0n.com" and people lose money, they'll get a
slap round the chops in the media, browser UI or none.
Gerv
Gervase Markham
> I don't want to speak for Gerv, but I don't believe he's concerned about
> CAcert or other CAs issuing fraudulent SSL certs for "amazon.com", he's
> concerned about CAs issuing SSL certs for misleading domain names like
> "amaz0n.com".
Not about them issuing them - but about being able to track down the
owners if they start abusing the domain for phishing.
Ideally, there would also be some agreed set of "too close" criteria
(the punycode attacks lend themselves to this, if you draw up a list of
identical glyphs at different code points) where the request would be
automatically refused. But outside of punycode, judging closeness is a
hard problem. And a site like www.paypal-ebay.com would probably not
meet any closeness criteria, but is a valid phishing site.
Gerv
Alex Wight
offline please let me know and I'll happily do so)
Ian G wrote:
> We wish! But, no, check it out:
> "This holiday season, enable customers to transact
> securely online, offline and over mobile devices."
> SSL was _purposed_ to protect credit card and other
> transactions (these days, primarily online banking).
> A CA "Issues SSL Certificates to enable authenticated,
> 128-bit SSL encryption that secure e-commerce and
> online payments across the internet."
> If it was simply to vouch for domain ownership, then
> we could do that the way Tucows and other registrars
> do it by sending an email. This would be wonderful,
> and would save everyone a lot of money and time.
> (Which is what CACert is doing! There's no reason
> why anyone can't do it on the fly...)
> But that's not what CAs were set up for, originally.
As I'm sure you're aware, all of the marketing quotes you mention can all
occur without SSL certificates. It's the SSL protocol that enables these
things to happen (with or without certs). Don't let the marketing hype fool
you, the bottom line is the SSL cert vouches for the authenticity of a given
key-pair belonging to the same entity that owns the domain. SSL may have
been purposed to protect transactions, but again, that's the protocol that
provides the protection, not the cert. The cert simply addresses a
usability issue of SSL in that implicitly trusting every public key for
every SSL service one has to interact with would be burdensome. Better to
trust an authority who can say that this public key belongs to this domain,
that one belongs to that one etc, then the user can decide if they trust the
domain for e-commerce.
If we went the Tucows/email route, that would be fine and dandy except
that everyone would still have to implicitly trust every public key for
every SSL server they want to interact with. They would still have the
protection of SSL, but not the ease of use that a public SSL CA brings by
binding domain name to public key.
> Recall, phishing is an attack against commerce.
> SSL was meant to protect commercial activities.
> If SSL is not intended to stop things like spoofing
> domains (phishing) to the user, what is it for?
> If we fix phishing (and fraud in general) by changes
> in the domain system, does that mean we can stop using SSL?
Maybe my definition of phishing is flawed, but I've always thought of it
as an attack against peoples' trust, not an attack against commerce.
Commerce is a sub-set of what people put their trust in on the Internet,
although I will certainly concede that the vast majority of attacks against
peoples' trust on the Internet is commercial in nature.
SSL is *not* intended to stop things like phishing, it's intended to
protect data en route between two applications.
Server certificates *are* intended to stop things like phishing, but that
will only work if we eliminate every possible avenue of phishing on servers
that don't have an SSL server certificate from a publicly trusted CA (good
luck on that one). If we don't, then phishers will just use non-certified
avenues of attack.
When I said that registrars should disallow certain levels of domain name
similarity, I said it in the hopes that we would realize that we're not
going to get SSL certs on every site in the world, and that we have to
address phishing on non-SSL sites too. Doing it at the registrar level
seemed like a logical place to start.
> This is really wierd. The SSL CA promises trust.
Maybe so, but so does the Nigerian Prince in my Inbox who has a 'trustworthy
business deal to propose'.
> anybody but the CAs should be responsible for controlling
> of potentially fraudulent domain activities?
You're kidding yourself if you think CAs are or will be responsible for
controlling potentially fraudulent domain activities. It just won't happen.
Even if it did, very few people/browsers are checking revocation status of
the SSL cert, so it's a moot point until all the browsers of the world are
modified to always validate SSL certs and all the users in the world stop
entering passwords into non-SSL-enabled sites.
> To date, anyone can create any domain. All the domain system
> does is create a record for name-IP translation and record who
> owns that name. Is that the system you want to change?
Absolutely. I want to see the registrar automatically sign up amazon.com to
have all of the possible phishing permutations of that domain so that no one
can buy one similar enough to result in successful phishing attacks. This
can be easily automated, the hard part is coming up with the rules on what
is similar enough and what isn't. It would be a societal study to come up
with such a rule set, but it's human nature and human society that we're
dealing with when it comes to phishing isn't it?
-Alex Wight
Ian G
Absolutely. That's the point. But the only reason
it would matter is if Jane-user saw Verisign's logo
on her browser and managed to relate that logo
to the bad news she heard vaguely in passing.
At the moment, if Verisign issued amaz0n.com,
who's know? Just us techies. And Verisign knows
that means pretty much nought, otherwise it
wouldn't have pulled that DNS switching trick.
But Jane and Jo user? Now that's a brand that
has to be protected. And (I claim) the only way
you are ever going to get Verisign to pay more
than the normal lip service to security is if you
put their brand on the line.
iang
Gervase Markham
> Absolutely. I want to see the registrar automatically sign up amazon.com to
> have all of the possible phishing permutations of that domain so that no one
> can buy one similar enough to result in successful phishing attacks. This
> can be easily automated, the hard part is coming up with the rules on what
> is similar enough and what isn't. It would be a societal study to come up
> with such a rule set, but it's human nature and human society that we're
> dealing with when it comes to phishing isn't it?
It's not a societal problem, it's one of perception.
To a dyslexic, www.paylap.com might seem very close to www.paypal.com,
but a non-dyslexic person might easily notice that one.
Are you going to register every possible transposition of two letters
when you register a domain? Are BMI music going to have to give their
domain to IBM?
IMO, the only workable system is a post-hoc one, which means that either
domain name registrars have to keep enough info to track down domain
owners in real life, or CA cert issuers are. And I know which group it's
more likely that we'll persuade to do that.
Gerv
Alex Wight
> It's not a societal problem, it's one of perception.
What I meant by that was that with other character sets, certain characters
are more similar than others and each society will have differing levels of
similarity. But you are right it ultimately boild down to perception (even
if perception is different between societies).
> Are you going to register every possible transposition
> of two letters when you register a domain? Are BMI music
> going to have to give their domain to IBM?
I'm purposefully trying not to go down the road of actually stating how
similar these rules would have to be, since to me IBM and BMI could never be
mistaken, but to a dyslexic that may not be the case. All I'm saying is
that imho this is the place to do it, because doing it with certs only
addresses a slice of the phishing pie (HTTPS).
> IMO, the only workable system is a post-hoc one...
By post-hoc do you mean after the site has been identified as fraudulent?
-Alex
Ian G
>
>All I'm saying is
>that imho this is the place to do it, because doing it with certs only
>addresses a slice of the phishing pie (HTTPS).
>
>
Hmmm... I don't see the problem myself with
limiting phishing protections to HTTPS. It
does make for a much simpler lesson to the
users: Make sure you are using HTTPS and
check the site...
But, to explore that notion some, what do you
see the phishing pie as being outside HTTPS?
Are you just referring to HTTP? Or also to
IM, mail, etc?
Ian G
> Ian G wrote:
>
>> Yes, I'd say that is the issue. Bear in mind that
>> this is *not* happening now as it is too easy to
>> attack without using SSL at all.
>
>
> Indeed. There has to be a minimum level of user education - that's
> unavoidable. What we are trying in Firefox is to get people to look at
> the status bar. Currently, the UI to look at is the lock and the
> domain name. In the future, there may need to be a little more, but we
> should keep the amount to a bare minimum.
'bare minimum' ... your thinking is possibly influenced
by the popup experiences of the past. Which were of
course pushed into the direction of "less is better."
Consider logos. Consider pictures. And above all,
consider their presence as not being dominating like
a popup, but more like a banner add that users just
let the back of their minds absorb, and the front of
their minds ignore.
One way to consider it is more like the new Flash
bar that pops into play whenever I hit a Flash site.
It's a funny colour, but it's not a popup and I don't
need to pay attention to it. My mind has already
absorbed that information and knows to just ignore
it and carry on browsing.
So, if a Flash plugin can demand some real estate,
why can't an SSL connection?
iang
PS: I run FreeBSD, there is no Flash plugin or none
likely to work... But at least now I'm not slapped
around the face every time I hit a site that insists
on pumping Flash at me. Thanks guys!
--
News and views on what matters in finance+crypto:
Alex Wight
> But, to explore that notion some, what do you see the
> phishing pie as being outside HTTPS?
> Are you just referring to HTTP? Or also to IM, mail, etc?
Well yah HTTP, IM, email, FTP, anything that uses DNS is somewhat
susceptible, although the other protocols are less prone to phishing for
reasons I'm sure we can all deduce, but the threat is there.
Something else I find interesting, is that if you tell users to look for
HTTPS, you'll get either a lot of confused users or a lot of HTTPS web site
redesigns or both. I feel this way because many sites have an HTTP
username/password login page that POSTS the login information to an HTTPS
site, it's still just as secure but is pretty much transparent to the user
unless they view source and know what to look for. It's this way for Bank
of America, American Express, Hotmail, etc, etc, etc... Simply telling users
to look for HTTPS isn't good enough imho.
-Alex
David Stutzman
> CA-Cert has (despite your assertion to the contrary) been operating for
> two years, during which time there has been no equivalent error. In an
> equivalent time since conception, Verisign had errors where CA-Cert has
> not.
>
> So if you were to take a moment to compare apples with apples and set
> aside your anti-free bias, you would conclude that CA-Cert has the better
> track record.
I wouldn't compare 2 years of CAcert operating to 2 years of Verisign
operating. The large difference is that noone important enough (that
I've heard of) is actually using CAcert. To my knowledge, please
correct me if I'm wrong in my assumptions, no major corporation is using
Cacert's certificates. They are paying however much per year to
Verisign/Thawte/Baltimore/Etc so their user's don't get a "THIS WEBSITE
IS ABOUT TO STEAL YOUR BABY" warning about the untrusted cert. As I
said in a different reply, I am on your side and would like CAcert to be
included and while the above comparison may be apples to apples...it
certainly isn't red delicious to red delicious.
Dave
Duane
You're making some pretty big assumptions here, especially if dealing
with countries outside of the US, etc that don't keep very good records,
or don't make them very accessible to others... After all a piece of
paper with some official looking symbol from some US university can be
sent to me for only $500, saying I have a degree in whatever I want...
Further more I don't believe it will be possible for similar name
searches, how do you expect a company in South America with xyz name and
a similar name of a company in Africa to be even found, let alone
compared or evaluated for being justified?
Not to mention most open source projects will never become official
entities under their respective governing laws, so it will be impossible
for them to get SSL certs from traditional CAs...
So while forcing phising scams into using SSL and forcing the labour
onto others, I don't see how it will do anything then hurt people that
are already being discriminated against, after all the SSL market verse
the web server market is becoming exponentially worlds apart, forcing
people to setup websites with encryption due to cost and or lack of
opportunity is worst then the stupid tax...
--
Best regards,
Duane
http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers
"In the long run the pessimist may be proved right,
but the optimist has a better time on the trip."
Gervase Markham
> What I meant by that was that with other character sets, certain characters
> are more similar than others and each society will have differing levels of
> similarity. But you are right it ultimately boild down to perception (even
> if perception is different between societies).
And between users - see my dyslexic example.
>>IMO, the only workable system is a post-hoc one...
>
> By post-hoc do you mean after the site has been identified as fraudulent?
Yes.
Gerv
Gervase Markham
> 'bare minimum' ... your thinking is possibly influenced
> by the popup experiences of the past. Which were of
> course pushed into the direction of "less is better."
Not really. It seems fairly self-evident to me that the more security UI
there is, the more likely users are to ignore it.
Taking it to the extreme demonstrates the point: if users have to look
for a lock, check a domain name, make an assessment of their trust value
in a symbol, confirm a checksum, make sure that a colour is the same,
and whistle Dixie every time they make a secure connection, then they
aren't going to bother with any of it.
The key is to allow them to establish as good a confirmation of the
security of the connection as possible, with the minimum of mental
effort. This is why some sort of logo-based trust assessment is never
going to work.
"Whose logo is that? Have I seen it somewhere before? Is it that one
that someone told me was dodgy? If it is, does it matter? If I've never
seen it before, what do I do? I want to shop here anyway... Is it really
going to matter?"
Far, far too much mental effort.
> One way to consider it is more like the new Flash
> bar that pops into play whenever I hit a Flash site.
> It's a funny colour, but it's not a popup and I don't
> need to pay attention to it. My mind has already
> absorbed that information and knows to just ignore
> it and carry on browsing.
So you want the security information we present to be ignored like the
Flash bar?
Gerv
Gervase Markham
> Well yah HTTP, IM, email, FTP, anything that uses DNS is somewhat
> susceptible, although the other protocols are less prone to phishing for
> reasons I'm sure we can all deduce, but the threat is there.
No-one (statistically speaking) buys stuff over IM, email or FTP.
Gerv
Gervase Markham
> Domain registrars seem to accept just about any fake name provided you
> pay on time.
>
> CAs however earn their living by confirming the identity of people -
> therefore they HAVE to check the identity - apart from the Class1-
> certificates issued for free, they have to check your identity
> personally or by using a process that cannot be circumvented (in
> Germany, one such process is "PostIdent").
My point exactly.
Gerv
Duane
> This means I can't start getting amazon.com ssl certs unless I have
> control over one of the administrative email boxes of amazon.com and if
> *that* is the case then either I work for Amazon and this is valid or
> Amazon has other things to worry about than rogue sites such as their
> email system's security. CAcert's policy with SSL certs is just that you
> have to have control of the domain to get certs for it.
> As to their email certs, they don't put your real name on the cert until
> your identity is verified by at least 2 people in their "web of trust"
> PGP style. It just says "CAcert User Cert".
Hmmmm re-reading these emails I think I'd just like to point our for the
record I've stated for a very long time that I'd like to see the people
not-assured be severely limited in terms of certificates being issued,
however this is a chicken an egg problem for us, how does a community
effort with limited resources (time and money, although in this case
money buys you time) verify the identity of the world.
So from the beginning this was a trade off to gain enough people that
were identified by others to help the system grow, especially in light
that we (lack money) to do a world tour and personally inspect the ID of
more people.
So basically I agree with what is being said about identifying people,
note here that I don't think identifying companies only, as this
discriminates and has lead to the current system of something like
100,000,000 websites and about 50,000 to 100,000 valid ssl certificates.
Basically some compromise has to be reached or only those that register
companies will be "eligible" to have the privilege of not getting a
warning box pop-up on people hitting their website, after all it's not
just credit card information people should be protecting, how many
webservers out there collect passwords with no ssl because they didn't
want to scare users away and didn't want to get ssl certs because of
cost or eligibility?
Ian G
Germany is ... Germany! You cannot rely on this
situation existing anywhere else. Many parts of
the world do not deal in hard identity, including
the US.
So in a sense there is a choice offered here:
Either browsers work with the whole world, and
deal with the fact that identity is just too soft a
metric to rely on,
Or, browsers require hard identity in order to
deliver security, and discriminate against those
parts of the world not able to meet the requirements.
iang
David Stutzman
> Hmmmm re-reading these emails I think I'd just like to point our for the
> record I've stated for a very long time that I'd like to see the people
> not-assured be severely limited in terms of certificates being issued,
> however this is a chicken an egg problem for us, how does a community
> effort with limited resources (time and money, although in this case
> money buys you time) verify the identity of the world.
>
> So from the beginning this was a trade off to gain enough people that
> were identified by others to help the system grow, especially in light
> that we (lack money) to do a world tour and personally inspect the ID of
> more people.
BTW...there's also a way to jumpstart yourself into the system via the
trusted third party method:
Trusted Third Parties
A trusted 3rd party is simply someone in your country that is
responsible for witnessing signatures and ID documents. This role is
covered by many different titles such as public notary, justice of the
peace and so on. Other people are allowed to be authoritative in this
area as well, such as bank managers, accountants and lawyers.
You can become a CAcert Assurer by seeking out trusted 3rd parties. You
will also need to download and print out a copy of the TTP.pdf and fill
in your sections. You will need to produce a photo copy of your ID,
which the person assuring you will inspect against the originals. Once
they are satisfied the documents appear to be genuine they need to sign
the back of the photo copies, and fill in their sections of the TTP
document. Once you have had your ID verified by 2 different people, pop
the copies + forms in an envelope and post them to:
CAcert Inc.
P.O. Box 75
Banksia NSW 2216
Australia
Ian G
> Ian G wrote:
>
>> 'bare minimum' ... your thinking is possibly influenced
>> by the popup experiences of the past. Which were of
>> course pushed into the direction of "less is better."
>
>
> Not really. It seems fairly self-evident to me that the more security
> UI there is, the more likely users are to ignore it.
In simplistic terms, if nothing else was considered,
that would be true.
...
> The key is to allow them to establish as good a confirmation of the
> security of the connection as possible, with the minimum of mental
> effort. This is why some sort of logo-based trust assessment is never
> going to work.
A century of marketing science - specifically,
that part known as branding - disagrees. At
least 2 research teams have independently
trialled these notions in Mozilla and the results
seem to indicate that graphical-based trust
assessment does in fact work.
In fact, precisely this sort of branding is used
in security systems all over the place. Have
a look at an ATM or a POS system next time
you plug your card in - an integral part of
many systems is that the device should be
branded. Have a look at the holographic
logo on your credit card ... that's a brand
that is hard to copy that the *merchant*
can check.
> "Whose logo is that?
The specific answer is "mine" if the question
is in the context of the TrustBar paper.
> Have I seen it somewhere before?
Yes, I chose it to suit that site.
> Is it that one that someone told me was dodgy?
(see above...)
> If it is, does it matter? If I've never seen it before, what do I do?
If you didn't select that site logo, then you
are not at that site. Consumers know what
to do then, they take more care.
> I want to shop here anyway... Is it really going to matter?"
That's what we want consumers to ask. If
it is their banking site, and it's been spoofed,
most will understand that this is ... an issue!
>
> Far, far too much mental effort.
Well, bear in mind ... the good logos only
disappear when there is a problem like
spoofing, so asking for more mental effort
is what we actually want.
When the good logos are there the amount
of mental effort is optomised because the
brain is able to cache and compress logos
into very small efforts of processing.
>> One way to consider it is more like the new Flash
>> bar that pops into play whenever I hit a Flash site.
>> It's a funny colour, but it's not a popup and I don't
>> need to pay attention to it. My mind has already
>> absorbed that information and knows to just ignore
>> it and carry on browsing.
>
>
> So you want the security information we present to be ignored like the
> Flash bar?
Er, no. That was just an example to indicate
how my brain has already created an "ignore"
bit for the Flash bar. If the bar was related
to say a security purpose, my brain would
create a "watch & process" path.
The brain is very powerful. It can do wonderful
things with imagery. All we have to do is present
it with the right images, and I grant that this does
require a bit of experimentation. But, the science
of imagery and ergonomics is well advanced, there
is no reason to believe this wouldn't be a very
quick experiment.
All the hard work has been done:
http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm
Also, see Ye and Smith, I don't have the URL to
hand.
iang
Ian G
I'm not sure why "buying stuff" is being brought
up here. Phishing as an attack is generally about
extracting information. The whole class of identity
fraud covers a huge range of tricks that the phisher
uses to get the information. It just so happens that
the user is trained to enter in their details in a
HTTP form, so that's a great way to trick her. That
doesn't mean she's buying anything at the time,
though.
(There was once a notion that HTTPS was invented
for the purpose of protecting credit cards ... which
I suppose one could consider to be a historical
footnote. But, no security discussion should rely on
that. As an example, the design of SSL+HTTPS
specifically ignores issues of payments and buying
security.)
David Stutzman
> Have a look at the holographic logo on your credit card ... that's a
> brand that is hard to copy that the *merchant* can check.
But even they don't. I stopped signing my debit/credit cards about 6
months ago. I use my debit card heavily and only ONCE was I asked to
show ID. Doesn't give me a warm/fuzzy feeling if I ever lose my cards.
If they're not even bothering to check for a signature I doubt they're
checking the authenticity of the hologram. In practice, it's too much
to ask some minimum-wage earning fool at the supermarket (I can say that
because I was once one) to not become complacent. The problem is that
given enough time and repetitiveness of something just about everyone
will become complacent.
-Dave
Ian G
> Ian G wrote:
>
>> Have a look at the holographic logo on your credit card ... that's a
>> brand that is hard to copy that the *merchant* can check.
>
>
> But even they don't. I stopped signing my debit/credit cards about 6
> months ago. I use my debit card heavily and only ONCE was I asked to
> show ID.
I think you'll find smaller merchants - those
that have to pay out of their own pockets - will
look and check more closely. Larger merchants
will simply write it off. Try paying at small
remote restaraunts where you are "out of
town."
> Doesn't give me a warm/fuzzy feeling if I ever lose my cards.
The whole mess is much worse than a lack
of warm/fuzzy feeling, check out:
http://www.msnbc.msn.com/id/6814673/
> If they're not even bothering to check for a signature I doubt they're
> checking the authenticity of the hologram. In practice, it's too much
> to ask some minimum-wage earning fool at the supermarket (I can say
> that because I was once one) to not become complacent. The problem is
> that given enough time and repetitiveness of something just about
> everyone will become complacent.
Sure. That's something to deal with in the
future. But bear in mind here that you are
looking at the edge cases, not the whole
cycle. The logo on the credit card works
well to raise the costs of a card forger. It
is just one of a whole range of little tricks,
which includes PIN numbers, security
codes, smart chips and what have you.
Just because you don't see it working
doesn't mean it serves no purpose. The
specific case of the logo was that it helped
enourmously back in the 80s to slow forged
card producers. These days, though, as the
identity info is hotter, a stolen card gets
used over the net, not in the shop. So the
logo has lost its importance over time.
Gervase Markham
> Hmmmm re-reading these emails I think I'd just like to point our for the
> record I've stated for a very long time that I'd like to see the people
> not-assured be severely limited in terms of certificates being issued,
> however this is a chicken an egg problem for us, how does a community
> effort with limited resources (time and money, although in this case
> money buys you time) verify the identity of the world.
You don't, necessarily. But if you don't, you can't expect others to
trust your limited verifications.
Being blunt, the totality of your email makes it clear that you started
from the viewpoint of "it's unfair that only companies have the ability
to prove their identity and get SSL certs" and decided to reduce
verification enough to let everyone else in, rather than starting from
the viewpoint of "we need to be equally secure and verifiable; how do we
do that in a not-for-profit context?".
Gerv
Gervase Markham
>> "Whose logo is that?
>
> The specific answer is "mine" if the question
> is in the context of the TrustBar paper.
Ah; we're talking at cross-purposes. I was referring to the plan to make
it clear in the UI which CA issued a particular cert.
>> Have I seen it somewhere before?
>
> Yes, I chose it to suit that site.
But, regarding the plan for users to choose logos for their favourite
sites, I'm not convinced by that one, either. It's far too much work,
and they overwhelmingly won't bother.
I do have an alternative solution to that problem I'm thinking about;
I'll post it soon.
Gerv
Ian G
> Ian G wrote:
>
>>> "Whose logo is that?
>>
>>
>> The specific answer is "mine" if the question
>> is in the context of the TrustBar paper.
>
>
> Ah; we're talking at cross-purposes. I was referring to the plan to
> make it clear in the UI which CA issued a particular cert.
OK. Well, both are required. The Logo that the
user selects *and* the logo for the CA. Ideally,
the logo for the CA should be encoded into the
Cert / signed by it. This limits a false cert attack
to the site's cert supplier, and thus paves the
way to force the CAs to start checking who they
are issuing the certs to.
For the CAs it means that users will start to
recognise the various CAs. This is no difficulty
as they already recognise the existance of
Ford, Intel, Nokia, Virgin, ....
>>> Have I seen it somewhere before?
>>
>>
>> Yes, I chose it to suit that site.
>
>
> But, regarding the plan for users to choose logos for their favourite
> sites, I'm not convinced by that one, either. It's far too much work,
> and they overwhelmingly won't bother.
To be honest, I personally haven't tried it. The
Trustbar codes it up and it has been researched
and trialed on real people (I mean, users, not
techies). The authors reported that the trials
supported their conclusions.
If you have firefox, try installing it and playing
around with it: it is at trustbar.mozdev.org
> I do have an alternative solution to that problem I'm thinking about;
> I'll post it soon.
This is the place! One of the things to realise about
any of these suggestions is that we need some
amount of experimentation to find the right subset.
Ian G
> "we need to be equally secure and verifiable; how do we do that in a
> not-for-profit context?".
I'd challenge the 1st part of that. Why does
a CA need to be "equally secure and verifiable?"
And, even if there is a good reason why this
is desirable, how do we cope when it is an
impossibility?
J. Wren Hunt
Hash: SHA1
Ian G wrote:
<snip!>
|> Ah; we're talking at cross-purposes. I was referring to the plan to
|> make it clear in the UI which CA issued a particular cert.
|
|
|
| OK. Well, both are required. The Logo that the
| user selects *and* the logo for the CA. Ideally,
| the logo for the CA should be encoded into the
| Cert / signed by it. This limits a false cert attack
| to the site's cert supplier, and thus paves the
| way to force the CAs to start checking who they
| are issuing the certs to.
This sounds pretty expensive to embed a graphics object in each and
every cert; perhaps a URL would suffice? (I don't have the relevant
specs handy to see if that's already earmarked or not...)
Wren
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCB632A/qR4Uok1vQRAj0wAJ4sPN71O7k//3AgfSQP2ZjLn7JqTQCg/d24
stZr4Q5RqQvbBUKWuXjfrlA=
=fiir
-----END PGP SIGNATURE-----
Ian G
>
> This sounds pretty expensive to embed a graphics object in each and
> every cert; perhaps a URL would suffice? (I don't have the relevant
> specs handy to see if that's already earmarked or not...)
Point. Probably easiest just to sign the logo with the
cert. Logically that's the same thing.
Duane
> You don't, necessarily. But if you don't, you can't expect others to
> trust your limited verifications.
In reality, how is our system any worst then any other? (before you
answer that read the rest of my email) (sorry to others that have heard
it before, but it's still holds true now as much as any time in the past)
> Being blunt, the totality of your email makes it clear that you started
> from the viewpoint of "it's unfair that only companies have the ability
> to prove their identity and get SSL certs" and decided to reduce
> verification enough to let everyone else in, rather than starting from
> the viewpoint of "we need to be equally secure and verifiable; how do we
> do that in a not-for-profit context?".
It was also 2 or 3 am (it's now 5am and I'm in a worst frame of mind but
I'll try again to get my point across) also I'm not the best at
articulating into words what I am trying to get across.
goal: formalised and verifiable global verification system for the
purpose of encryption deployment.
Basically this goal is unobtainable by any CA for the reason both Ian
and I pointed out, no uniform ID systems exist that is a 1 size fits all
across the entire planet. To make matters worst identity theft is
rampant, even in the US (as noted by Ian's link), so if you have
governments pro-actively working against tying up loopholes** in their
own systems*, what hope do CAs have of actually vetting anyone in any
existence, really is the person they're claiming to be? (If it's rampant
in the US, imagine how bad it really is in countries that have much
bigger issues then identity fraud)
In Boston last year, there were guys telling us how it took very little
effort to get Dunn and Bradstreet to update information on companies to
get certificates issued... So if you know how the system works, how hard
is it to abuse it in reality?
Companies are getting code signing certificates for spyware, while
technically this is valid, surely these are ethically and morally wrong?
Isn't this what code signing was supposed to prevent?
When it boils down to it***, all a CA can do is view the evidence (bits
of paper), record some of it, and pray their snake oil**** isn't
discovered for what it really is, saying this company has this domain
and they seem to have a piece of paper saying they have a right to use
the domain. There of course is the bit you pointed out about not being
fair... Why shouldn't a legal entity (not just companies, companies in
most places are also considered legal entities as well) be entitled to
the same protections just because they don't have a piece of paper
issued by their respective governments saying they have a right to use
even their own last names? Security last time I checked revolved around
more then simple money matters, and the amount of uses of PKI
certificates is increase well beyond simple websites. IMAPS, POP3S,
SMTPTLS, IRCS, all valid uses (most/all have a password component) that
don't want 3rd parties listening in, and it's already fact about
different govt. agencies snooping on and treading all over the ability
for us to ever hold a private conversation with another human being ever
again.
I started out this venture a little naive, and have since gained a
remarkable insight into what the PKI industry is all about, it's
certainly not security, because you can't judge intent, just deal with
it after the fact... As is most crimes such as identity theft, fraud
etc... If you look at the patterns emerging it seems to me that
everything is going the way of the domain industry several years ago...
High prices and monopoly, to more open market and cheaper certificates,
does this mean reduced checking or was there ever any decent checking in
the first place?
Questions that should be asked is what people think CAs really should be
doing and what they really are doing generally are 2 different things,
CAcert being a slightly different case in the fact that virtually
everything is so out in the open and for most part it's the general
consensus that we go with.
So basically is CAcert facing more scrutiny and having to jump a higher
bar then every other CA because we don't have the funds to put toward a
webtrust audit? I'd be inclined to say it certainly perceived that way
by an outsider.
Realistically I have lost count of the number of times people put
questions to me "Why should we trust CAcert?" etc and these aren't
people that have never used certificates of one kind or another before,
but they are so well brain washed they never ever stopped to consider
why they trust any other CA, it's just always been that way and how most
people were told to accept it. So I reflect the question back to them
and you can almost see a light bulb going off above their head at how
the whole system is based on marketing a lot more then security. It's
all a smoke and mirrors show put on to try and milk large gobs of money
out of large corporates. This however is a failed marketing campaign to
print money and the sum total of the SSL market is really quite poor if
the truth be known (I know I was shocked at how tiny it really is!)
* Most ID is circular, in most countries you start off with a birth
certificate, get a drivers license from your birth certificate, then
passport, so on and so forth.
** 2 of the 9/11 terrorists held valid Virginia drivers licenses in fake
names.
*** 10 myths of PKI, one of them is that the word "trust" with CAs
really only means the CA is trust worthy enough to protect it's private
key, it has no ability to really judge intent of a person requesting a
certificate.
**** Another myth (the snake oil) is the fact that if you do get wrongly
issued a certificate for a server unless you hijack the domain the
certificate is basically useless. Obviously this doesn't apply to code
signing or email certificates. So while it's harder to abuse a server
certificate people were more inclined to accept weaker email certificates...
There is a million other discrepancies in the PKI industry, 10 myths of
PKI is a good place to start...
Ian G
> .... To make matters worst identity theft is rampant, even in the US
> (as noted by Ian's link),... (If it's rampant in the US, imagine how
> bad it really is in countries that have much bigger issues then
> identity fraud)
Actually, to be fair, identity theft is rampant
especially in the USA, and less so elsewhere.
The reason for this is fundamentally the USA
is the most advanced credit society. Others
will/may catch up in time, but right now they
are facing phishing and identity fraud losses
of 1% - 10% as severe as the US.
In short, it's an American Disease (tm). Sorry
about that!
So you could ask why all these foreigners are
banging the drum to protect yanks against
phishing.... and I have no good answer for that ;-)
( Slight amusing aside: I was talking to an
american woman yesterday on the phone, and
suggested that she should insert her photo
into the credit reports. She didn't understand
how that would help, until I explained that
then she would have to be *present* to get
credit extended. "Never!" I could hear her
disgust at this notion over the other end of
the phone, she ruled this concept so out of
court it made me feel as if I was some primitive
from another continent. Which, in some senses,
I was! )
iang
Ian G
> There is a million other discrepancies in the PKI industry, 10 myths
> of PKI is a good place to start...
Anyone who travels down the path of really
doing the research into the PKI structure
ends up losing a lot of respect for the
security industry, and security principles
in general. A good analogy is perhaps
Bismark's on the law: the PKI structure is
like sausages, you really don't want to see
how it was made.
Having said that, I'm not sure which document
you meant about "10 myths of PKI" but here is
a link to a sort of evolving list of criticisms I
keep:
http://iang.org/ssl/pki_considered_harmful.html
iang
PS: Unlike some documents that you will see posted
(including by myself), I try and keep that one
scholarly and reputable by including full academic
references. If you are looking at something that
is purporting to address a security issue, one
way to see if it is a robust well thought out
proposal is to look at how many like and preceeding
documents it refers to. No documents signals
that the author has not thought it out, or at least
not tied it in to other people's work, so it is quite
probably a waste of time to read it.
Duane
> The reason for this is fundamentally the USA
> is the most advanced credit society. Others
> will/may catch up in time, but right now they
> are facing phishing and identity fraud losses
> of 1% - 10% as severe as the US.
That wasn't what the link to MSN was suggesting, it was because of
illegal immegrants trying to get work, hell you don't even need a
matching name and SSN to work, but this has a side effect of giving the
US govt a bunch of tax income it will never have to repay.
Credit is a minor side effect issue in comparision with employment from
the article you posted :) (Article quoted $56bil in tax the US govt
won't have to pay back, I don't think there's that much fraud at this
stage...)
Ian G
> Ian G wrote:
>
>> The reason for this is fundamentally the USA
>> is the most advanced credit society. Others
>> will/may catch up in time, but right now they
>> are facing phishing and identity fraud losses
>> of 1% - 10% as severe as the US.
>
>
> That wasn't what the link to MSN was suggesting, it was because of
> illegal immegrants trying to get work, hell you don't even need a
> matching name and SSN to work, but this has a side effect of giving
> the US govt a bunch of tax income it will never have to repay.
> Credit is a minor side effect issue in comparision with employment
> from the article you posted :) (Article quoted $56bil in tax the US
> govt won't have to pay back, I don't think there's that much fraud at
> this stage...)
>
Re-reading back in those quotes ... I see that
I was jumping the gun there and switching
from identity theft to identity fraud without
thinking...
iang
Gervase Markham
> Basically this goal is unobtainable by any CA for the reason both Ian
> and I pointed out, no uniform ID systems exist that is a 1 size fits all
> across the entire planet.
But that's what we have. Either the browser has a lock, or it doesn't.
You may not like it, but it's true. And, as I mentioned in my other
reply, even if we had a more fine-grained system, most users don't have
the time, inclination or information to make fine judgements about
security. The expect us, the browser makers, to protect them.
Gerv
Gervase Markham
> OK. Well, both are required. The Logo that the
> user selects *and* the logo for the CA. Ideally,
> the logo for the CA should be encoded into the
> Cert / signed by it. This limits a false cert attack
> to the site's cert supplier, and thus paves the
> way to force the CAs to start checking who they
> are issuing the certs to.
>
> For the CAs it means that users will start to
> recognise the various CAs. This is no difficulty
> as they already recognise the existance of
> Ford, Intel, Nokia, Virgin, ....
"No difficulty"? You don't see any difference between the Virgin brand
and the Verisign brand? Do you really think users have the brain space
to remember and understand 20 different CA brands, and make judgements
based on that understanding?
Also, even if they do, they have no choice. A particular shop is only
protected by a cert from one company. It's trust that company, or shop
somewhere else. Those are the only options. And we are not in a million
years going to persuade users, if they've found a product they like, to
leave that shop and find it somewhere else just because the CA has a
slightly tarnished reputation.
>> I do have an alternative solution to that problem I'm thinking about;
>> I'll post it soon.
>
> This is the place! One of the things to realise about
> any of these suggestions is that we need some
> amount of experimentation to find the right subset.
See http://www.gerv.net/hacking/security/phishing.html .
Gerv
Gervase Markham
> I'd challenge the 1st part of that. Why does
> a CA need to be "equally secure and verifiable?"
Because, like it or not, we have a binary security model. And, even if
we didn't, most users aren't in a position to correctly judge relative
levels of risk.
Gerv
Ian G
> Ian G wrote:
>
>> OK. Well, both are required. The Logo that the
>> user selects *and* the logo for the CA. Ideally,
>> the logo for the CA should be encoded into the
>> Cert / signed by it. This limits a false cert attack
>> to the site's cert supplier, and thus paves the
>> way to force the CAs to start checking who they
>> are issuing the certs to.
>>
>> For the CAs it means that users will start to
>> recognise the various CAs. This is no difficulty
>> as they already recognise the existance of
>> Ford, Intel, Nokia, Virgin, ....
>
>
> "No difficulty"? You don't see any difference between the Virgin brand
> and the Verisign brand?
Good, I'm glad you understand what is meant by
branding. By forcing VeriSign to brand themselves
like Virgin, they are laid bare to their trusting public.
Who knows, maybe they will surprise us all.
Either way, right now, Mozilla is hiding the fact that
Verisign is being used to create relationships that
are falsely presented as trust. In fact, Firefox lies
about it by saying that the user trusts this cert and/or
provider.
What I'm suggesting is that the truth be revealed to
the users: Verisign is the one who made the relationship,
and that should be on the chrome. (insert long rant here
about the merits of TrustBar...)
> Do you really think users have the brain space to remember and
> understand 20 different CA brands, and make judgements based on that
> understanding?
Do you really think MF should purport to make the
decision that the user should trust 20 different CAs
without a choice?
Yes, users can remember the brands needed. Huge
numbers of branding studies have shown the user
has a capability to deal with brands. The entire
western commerce system runs on it, and relies
on it to get bread to your door, petrol in your car,
your car itself, and beer at the end of the car
journey. Quick, how many beer brands do you
know and recognised?
Don't let your hatred of brands and marketing and
endless adverts blind you. Behind that process is
the creation of trusted relationships - and that's
where you will find the security needed to overcome
the current bugs that let things like Shmoo go forth
without any easy solution.
And this is a security question, right? Tell me why
it is that you trust Saunalahden? You do trust them,
that's what Firefox has decided. Now, why is that?
(Search for it here for the context...)
http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm
> Also, even if they do, they have no choice. A particular shop is only
> protected by a cert from one company. It's trust that company, or shop
> somewhere else. Those are the only options.
Yes, this is a bug in the PKI. Oh well, we can't fix
everything in one day.
> And we are not in a million years going to persuade users, if they've
> found a product they like, to leave that shop and find it somewhere
> else just because the CA has a slightly tarnished reputation.
Oh, then that's fine. No problem. The consumer has
a choice. She sees that Verisign protects Paypal. She
stays. That's at least a correct trust calculation by the
interested parties, instead of right now where Firefox
tells her that she trusts Verisign, but hides it from
her when Verisign is not used (a la Shmoo).
But, I wouldn't underestimate the power of brand.
Right now, the reason VeriSign doesn't care is because
the users don't know who they are. Once users know
who Verisign is, I think they'll have a chance to show
how much they want to care about security ;-)
> See http://www.gerv.net/hacking/security/phishing.html .
Excellent... reading soon.
Ian G
> Ian G wrote:
> > I'd challenge the 1st part of that. Why does
>
>> a CA need to be "equally secure and verifiable?"
>
>
> Because, like it or not, we have a binary security model.
Right. Like it or not, we have that.
> And, even if we didn't, most users aren't in a position to correctly
> judge relative levels of risk.
That is an assumption that goes back to the
beginning of PKI time. I wonder where it
comes from?
There may be support for this statement,
but I've never been able to find its scientific
basis, in cryptography, user design, nor in
economics. In particular, the last 10 years
of experience only bear it out to the extent
that users were denied the chance to make
a choice. So it may well be that the reason
they are not in a position to correctly judge
relative levels of risk is because they are
not permitted to do so.
In contrast, in most fields of endeavour,
users can correctly judge relative levels of
risk. Especially, they tend to be quite good
at knowing when to go to a specialist and
when not.
It may be nice and comforting to say that the
users can't judge for themselves, but:
a) very few people support the notion that
they should be denied the choice to judge, and
b) relatively few support the notion that there
is somewhere an elected elite that can make
the judgement better.
That is, the history of those elite who said that
the people should be denied that choice, and
they the elite know better, is not a happy one.
J. Wren Hunt
Hash: SHA1
Ian G wrote:
| <snip!>
|
| Do you really think MF should purport to make the
| decision that the user should trust 20 different CAs
| without a choice?
|
| Yes, users can remember the brands needed. Huge
| numbers of branding studies have shown the user
| has a capability to deal with brands. The entire
| western commerce system runs on it, and relies
| on it to get bread to your door, petrol in your car,
| your car itself, and beer at the end of the car
| journey. Quick, how many beer brands do you
| know and recognised?
|
There is a difference between brands of products that you use and have
experience with, vs. those that you may simply have no basis for knowing.
With your analogy I know that millions enjoy Guinness; me, I can't get
the stuff down! ;-) That's not to say it's bad, which it seems like
where your argument is going: recognized brand = good thing(tm).
Un-recognized brand = bad thing.
In the Schmoo thing, we both saw the cert details and knew rather
quickly that something was afoot because it was *not* Verisign. But I
see no way whatsoever that joe6pack on the street (joe6pack being
defined as a non-crypto geek) would have the faintest clue or even know
why he should care? It's like me taking my car in for service. When
the mechanic says I need brake pads, I merely nod and say yes; we don't
even bother going through which brand he slaps on there because we both
know it would be meaningless to me. The only thing that's likely to get
my attention is when he asks "Do you want the $10 or $100 pads?". But
when I drive off the lot and my car successfully brakes, I quickly
forget the entire brake pad converation, not just the brand. For me it's
just not important. Just like most people haven't a clue what that damn
padlock is for anyway. Not on their radar. Un-unh. Nope. Not gonna happen.
We the crypto-geek community have to ensure that we give consumers the
necessary tools but that doesn't mean we need or should attempt to make
them experts. For no matter what clever hack we code, RFC we write, or
GUI we display, it boils down to Abe Lincoln's "You can fool all of the
people some of the time, some of the people all of the time, but you
can't fool all of the people all of the time". We can only address
parts of the argument IMO, not the whole thing.
Wren
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
iD8DBQFCC4L6A/qR4Uok1vQRAoCaAJkBNHPfFguYWz9NeldvR8z346F2nwCfXpOV
QUzaxrL35vCPWs49zqVSNHs=
=8m0s
-----END PGP SIGNATURE-----
Ian G
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Ian G wrote:
>
> | <snip!>
> |
> | Do you really think MF should purport to make the
> | decision that the user should trust 20 different CAs
> | without a choice?
> |
> | Yes, users can remember the brands needed. Huge
> | numbers of branding studies have shown the user
> | has a capability to deal with brands. The entire
> | western commerce system runs on it, and relies
> | on it to get bread to your door, petrol in your car,
> | your car itself, and beer at the end of the car
> | journey. Quick, how many beer brands do you
> | know and recognised?
> |
>
> There is a difference between brands of products that you use and have
> experience with, vs. those that you may simply have no basis for knowing.
Yes. If you are dealing with a brand you have
no basis for, ... Take Care!
> With your analogy I know that millions enjoy Guinness; me, I can't get
> the stuff down! ;-) That's not to say it's bad, which it seems like
> where your argument is going: recognized brand = good thing(tm).
> Un-recognized brand = bad thing.
mmm... Close! Recognised brand - know whether it is
a good thing or bad thing. Un-recognised? Well, take
more care.
> In the Schmoo thing, we both saw the cert details and knew rather
> quickly that something was afoot because it was *not* Verisign.
Right. But that was only the techies who know how
to do that. Firstly it was obviously not Paypal, because
it said Meoow, and we were all told in advance it was
a bug. Secondly, we all knew that we had to go looking
for the cert (which took me minutes to find).
Yet, our average user does not know that. She has no
tools to know anything about Verisign. If she is in the
top 10% of average users she might look at the lock.
> But I
> see no way whatsoever that joe6pack on the street (joe6pack being
> defined as a non-crypto geek) would have the faintest clue or even know
> why he should care?
This is how brand works - ask your mates. If
you are asked about which phone to buy, you
ask your mates. If you ask about what mp3
player to buy, you ask your mates. You don't
need to know the brands, or even have the
faintest clue about any of them, you just need
to have plenty of mates.
> It's like me taking my car in for service. When
> the mechanic says I need brake pads, I merely nod and say yes; we don't
> even bother going through which brand he slaps on there because we both
> know it would be meaningless to me. The only thing that's likely to get
> my attention is when he asks "Do you want the $10 or $100 pads?". But
> when I drive off the lot and my car successfully brakes, I quickly
> forget the entire brake pad converation, not just the brand. For me it's
> just not important. Just like most people haven't a clue what that damn
> padlock is for anyway. Not on their radar. Un-unh. Nope. Not gonna
> happen.
Yes, users go to Mozilla like you go to your mechanic.
Now your mechanic, he knows his reputation is
on the line if he puts in duff brake pads. In a
sense, so is Mozilla's. It's worse for the mechanic
because he can be sued and people will flee from
his shop. Mozilla doesn't have that to worry about.
But, get this: When the dodgy brake pads of the
Shmoo cert came out recently, few said it was
Mozilla's fault. Some people said it was the
registrar's fault. Others (surprisingly few) said
it was the CA's fault. Some say it is ICANN's
fault. I forgot what I said....
So you say the user has no capability to decide
these issues. I think we've seen here this week
that it's not as if anyone here has the answers.
Giving the user more control over their CA -
whether to vote them up or down - can't then
do more damage than has already been done!
> We the crypto-geek community have to ensure that we give consumers the
> necessary tools but that doesn't mean we need or should attempt to make
> them experts. For no matter what clever hack we code, RFC we write, or
> GUI we display, it boils down to Abe Lincoln's "You can fool all of the
> people some of the time, some of the people all of the time, but you
> can't fool all of the people all of the time". We can only address
> parts of the argument IMO, not the whole thing.
Having an opinion on Verisign doesn't make
anyone an expert. It's like going to a football
game. You don't have to understand the rules
to form an impression.
To double up on your Abe, it all boils down to
what Ludwig van Mises said:
"centralised planning making might work
in a small community like a village. But, for a
community and economy like a big country, it
is impossible to build the computer big enough
to analyse all the information. **"
iang
PS: That's a paraphrase, I don't know the original
quote, but it's the one that destroyed communism
(centralised planning) as a viable model. It's called
the von Mises calculation argument.
Gervase Markham
> Good, I'm glad you understand what is meant by
> branding. By forcing VeriSign to brand themselves
> like Virgin, they are laid bare to their trusting public.
> Who knows, maybe they will surprise us all.
You expect Verisign to start taking out brand-building ads based on a
change we make to Firefox?
And if they do, do you expect any negative publicity they may get to
trump the positive publicity from those ads, such that users have an
overall negative assessment of the company?
> Either way, right now, Mozilla is hiding the fact that
> Verisign is being used to create relationships that
> are falsely presented as trust. In fact, Firefox lies
> about it by saying that the user trusts this cert and/or
> provider.
The user trusts us (implicitly by downloading the software and running
it), and we trust the provider.
>> Do you really think users have the brain space to remember and
>> understand 20 different CA brands, and make judgements based on that
>> understanding?
>
> Do you really think MF should purport to make the
> decision that the user should trust 20 different CAs
> without a choice?
Absolutely. Because of all the people who could make that decision, we
are the most qualified.
> Yes, users can remember the brands needed. Huge
> numbers of branding studies have shown the user
> has a capability to deal with brands.
That second sentence does not imply the first.
> The entire
> western commerce system runs on it, and relies
> on it to get bread to your door, petrol in your car,
> your car itself, and beer at the end of the car
> journey.
None of these things rely on branding, they rely on people manufacturing
products, and them ending up in shops. I don't give a stuff what brand
of petrol I get - it's all the same.
You've really bought the Nike vision, haven't you? The brand is
all-important. :-)
> Quick, how many beer brands do you
> know and recognised?
Are you suggesting that CAs will be taking out television adverts like
beer brands? They aren't _selling_ anything to the general public.
> And this is a security question, right? Tell me why
> it is that you trust Saunalahden? You do trust them,
> that's what Firefox has decided. Now, why is that?
Because mozilla.org trusts them, because they've met the criteria
necessary for inclusion. (Yes, we should be running the criteria over
legacy CAs.)
>> And we are not in a million years going to persuade users, if they've
>> found a product they like, to leave that shop and find it somewhere
>> else just because the CA has a slightly tarnished reputation.
>
> Oh, then that's fine. No problem. The consumer has
> a choice. She sees that Verisign protects Paypal. She
> stays. That's at least a correct trust calculation by the
> interested parties,
No, it's not. It's an "I want to use Paypal" calculation.
The only way displaying the CA brand will ever have an effect is if
users know enough about CAs and are wary enough of particular ones that
they refuse to shop with shops protected by them. This is just not going
to happen. Ever. Putting logos in the UI won't even come close to
generating the amount of awareness among the general user population
that you'd need.
And, when it comes down to it, users just don't care enough to take the
time to acquire that level of knowledge. IE doesn't make them learn all
this stuff and make all these trust estimates. Microsoft just says
"Don't worry, we've taken care of it." We should be able to say the same.
Gerv
Gervase Markham
> There may be support for this statement,
> but I've never been able to find its scientific
> basis, in cryptography, user design, nor in
> economics. In particular, the last 10 years
> of experience only bear it out to the extent
> that users were denied the chance to make
> a choice. So it may well be that the reason
> they are not in a position to correctly judge
> relative levels of risk is because they are
> not permitted to do so.
Let's try and find an analogy. Users choose banks to deal with. One
criteria they could potentially use in choosing a bank is what
percentage of customers lose money through some sort of fraud (in a
situation where the bank disclaims responsibility).
Now a user could try and find and collect statistics on which banks tend
to disclaim responsibility in fraud cases, and which didn't, and on
which banks tended to be targets of fraud, and which don't. But they
don't do that. They choose a bank account based on the free Walkman and pen.
Gerv
Ian G
I just read your page, great stuff. Now, are comments
solicited for this group, a bugzilla page, or in private?
Gervase Markham wrote:
> Ian G wrote:
>
>> Good, I'm glad you understand what is meant by
>> branding. By forcing VeriSign to brand themselves
>> like Virgin, they are laid bare to their trusting public.
>> Who knows, maybe they will surprise us all.
>
>
> You expect Verisign to start taking out brand-building ads based on a
> change we make to Firefox?
No, but I suppose it is an option. I'm not
interested that much in how VeriSign
respond in the market place, except
where it effects security.
> And if they do, do you expect any negative publicity they may get to
> trump the positive publicity from those ads, such that users have an
> overall negative assessment of the company?
There will be a reckoning. I would imagine
that it would be quite a tricky campaign, but
for reasons beyond today's post, they want to
do it too.
>> Either way, right now, Mozilla is hiding the fact that
>> Verisign is being used to create relationships that
>> are falsely presented as trust. In fact, Firefox lies
>> about it by saying that the user trusts this cert and/or
>> provider.
>
>
> The user trusts us (implicitly by downloading the software and running
> it), and we trust the provider.
Trust is a very difficult word. If you were to
ask the user whether they trusted VeriSign
(as did that recent survey) then I don't think
the answers would be all that positive.
Even if you explained the above logic to the user,
and *then* asked the question, I suspect the
user will still say "no."
>>> Do you really think users have the brain space to remember and
>>> understand 20 different CA brands, and make judgements based on that
>>> understanding?
>>
>>
>> Do you really think MF should purport to make the
>> decision that the user should trust 20 different CAs
>> without a choice?
>
>
> Absolutely. Because of all the people who could make that decision, we
> are the most qualified.
! See below.
>
> You've really bought the Nike vision, haven't you? The brand is
> all-important. :-)
LOL... I wouldn't be seen dead in a pair of Nikes ;)
No, I happen to have studied both marketing *and*
technology. I understand their relative importance,
and am capable of identifying the security within
branding. (As well as the insecurity within other
systems purporting to be secure, but are not
integrated with the users of those systems.)
>> Quick, how many beer brands do you
>> know and recognised?
>
>
> Are you suggesting that CAs will be taking out television adverts like
> beer brands?
( I'll answer that one in private if you like ;)
> They aren't _selling_ anything to the general public.
Somebody's selling trust to the general public.
I suggest that MF figures out just who is selling
trust to the general public ... before the courts
do it for you. You identify above that MF is
asserting that it is the decider of trust. This
makes it the seller of trust (for no money, but
still...).
Personally, that's the last place in the world where
I would rather be, given that phishing is a billion
dollar per annum year loss.
(The first phishing case against a non-attacker
has been launched, just this last week. Just so
you know this isn't FUD, which I know y'all think
I'm good at.
http://www.financialcryptography.com/mt/archives/000337.html
It's for real, it started last week. In the legal
community, everyone is looking at that and
thinking to themselves ... Hmmm.... Fees.... )
>> And this is a security question, right? Tell me why
>> it is that you trust Saunalahden? You do trust them,
>> that's what Firefox has decided. Now, why is that?
>
>
> Because mozilla.org trusts them, because they've met the criteria
> necessary for inclusion.
OK. Try it on some users. You do recognise that
this is an "educated answer" that has been part
of the "PKI" model for a decade, and the users
may not have actually subscribed to the notion?
> (Yes, we should be running the criteria over legacy CAs.)
>
>>> And we are not in a million years going to persuade users, if
>>> they've found a product they like, to leave that shop and find it
>>> somewhere else just because the CA has a slightly tarnished reputation.
>>
>>
>> Oh, then that's fine. No problem. The consumer has
>> a choice. She sees that Verisign protects Paypal. She
>> stays. That's at least a correct trust calculation by the
>> interested parties,
>
>
> No, it's not. It's an "I want to use Paypal" calculation.
>
> The only way displaying the CA brand will ever have an effect is if
> users know enough about CAs and are wary enough of particular ones
> that they refuse to shop with shops protected by them. This is just
> not going to happen. Ever.
I'm not sure what you are saying here. If it is "branding
doesn't work" then check the Nikes. If it is that "branding
doesn't work for security" then check Volvo. If it is that
branding will never work for security and for software,
then check out what's happening to Microsoft. In short,
their brand is currently being trashed on security.
> Putting logos in the UI won't even come close to generating the amount
> of awareness among the general user population that you'd need.
It will, the day VeriSign issues a cert to Paypall.com ...
It will, the day Alice gets phished and there wasn't a
Comodo icon on the page then...
It will, when USERTrust issues another Paypall.com
and a thousand users start demanding that something
be done because they say the CA change and they
want to know what's going on.
Consider this: Shmoo wasn't anything we didn't
already know. Yet it caused a firestorm. Why?
Because information only spreads about security
when someone gets hurt. Or where there is the
fear of someone getting hurt.
So, allied to all that we are seeing and saying, we
can expect nothing to change ... except when people
get hurt.
> And, when it comes down to it, users just don't care enough to take
> the time to acquire that level of knowledge. IE doesn't make them
> learn all this stuff and make all these trust estimates. Microsoft
> just says "Don't worry, we've taken care of it." We should be able to
> say the same.
Look where Microsoft is right now... Their user
base is shifting under them, and because there
are no good stats and the media doesn't report
on this, we do not know how much user share
they are losing.
Why? Because of Branding and lousy security.
Why are users shifting to Firefox? Because of
good security *and* a good brand. What tips the
balance between Konqueror and Firefox? Brand
is a big part of it...
Did you buy the Firefox vision?
Brand is integral to Mozilla. All I'm suggesting
is you dish some of that medicine to VeriSign.
And Comodo, and Entrust and the rest. Yeah,
CACert had better pull up their socks too ;)
Ian G
Not a bad analogy. The vision of creating
the CA as an analogue to the Bank was
something that inspired the early implementors
of the PKI (and scared the banks no end).
Hence, they also spent a lot of time writing
legislation and getting it passed (the "Utah
model").
So you might say that we can make the
case that CAs are like banks and MF is
like the central bank, and the users are
told just like with banks that they are all
safe. (That's why they don't bother to
collect statistics.)
This analogy holds quite well!
Unfortunately, there is no good basis
in economics for the case that the user
cannot be trusted to choose a good bank.
Let me skip a few hundred books and
theses and put it in these terms:
If you had to ask the head of the Bundesbank
whether he is best equipped to tell users
where to safely bank, he would say:
Absolutely!
But if you asked the head of the Federal
Reserve the same question, he would say
Absolutely Not!
Duane
> But if you asked the head of the Federal
> Reserve the same question, he would say
>
> Absolutely Not!
I lost track of the number of people telling me how they stripped their
browsers bare of almost all CAs except for Verisign and one or two
others because they simply don't trust all CAs firefox/mozilla says they
should trust...
Ian G
> These same arguments played around and around at Netscape (back when
> it mattered to Verisign) about wether or not to include the signer's
> brand. In the end it was UI realestate (or the lack thereof given to
> security) argument that won the day. In the arena where realestate was
> less of an issue, but security was, the signer's logo and name *WERE*
> included (remember the 'Grant' dialogs for signed apps). They still
> contain those logos today.
Wow. Thanks for reminding me - someone else
on this list told us a while back that this was
indeed the case.
Back then, there were no attacks on browsers,
and the screen UI realestate was a dominating
issue. I would have done the same.
Where are these 'Grant' dialogs? Are they
available under Firefox / Thunderbird?
So, if we were to file a bug asking to revert
back to the security model of the signer's
brand, that would be an easier sell?
Just musing here...
Ian G
> I lost track of the number of people telling me how they stripped
> their browsers bare of almost all CAs except for Verisign and one or
> two others because they simply don't trust all CAs firefox/mozilla
> says they should trust...
People do that? Hmmm... as you wrote this,
Steve Bellovin (a well known crypto guy) posted
this over on the cryptography list:
-------- Original Message --------
Subject: Re: A cool demo of how to spoof sites (also shows how TrustBar
preventsthis...)
Date: Thu, 10 Feb 2005 18:24:46 -0500
From: Steven M. Bellovin <s...@cs.columbia.edu>
In message <420B1453...@cs.biu.ac.il>, Amir Herzberg writes:
>Steve, my point was not the trivial fact that TrustBar would not display
>the homograph; suppose it did... even then, the user is _asked_ about
>the certificate, since it was signed by an unusual CA that the user did
>not specify as `to be trusted always`; this should certainly be a good
>warning for most users (and of course, a good situation to check for
>tricks such as homographs...).
>
>And even if some user allowed this CA as `always trusted`, there is
>still a fair chance he'll notice that the brand of CA on his bank's site
>has suddenly changed... which may also raise the alarm.
>
"Unusual CA"? I'm not sure what a *usual* CA is.
Just for fun, I opened up the CA list that came with my copy of
Firefox. There are no fewer than 40 different entities listed, many of
whom have more than one certificate. I personally know less than half
of them to be trustworthy -- and that's assuming that, say, Thawte,
Thawte Consulting, and Thawte Consulting cc are all the same company
and I can count that as three different ones. I had no idea that that
the U.S. Postal Service had a CA that was trusted by my browser -- and
I dare say that many non-Americans wouldn't trust it at all, on the
assumption that it would do whatever the U.S. government told it to do.
(For such people: the relationship between the USPS and the government
is complex. Let it suffice to say that they moved from .gov to .com,
and they had quasi-valid reasons for doing so.) Baltimore is listed;
last I heard, they were out of business. Is a private root key (or the
equivalent signing device) an asset that can be acquired under
bankruptcy proceedings? Almost certainly. The following text appears
in the December 2004 Shareholder Circular I found at www.baltimore.com:
The Company sold the last of its remaining operating
businesses in 2003, and has not engaged in operating
activities since that time. Since taking office in July
2004, the Company's new Board of Directors has been working
to resolve all significant legacy issues, to identify a
means of utilising the Company's remaining non-cash assets,
toreduce costs so as to maximise the cash available for
future deployment and to review appropriate business
opportunities to enhance shareholder value. Paragraph 5 of
Part II of this document describes, among other things,
the current position relating to the utilisation of the
Company's non-cash assets.
Apart from the question of whether or not EvilHackerDudes.Org, a sub rosa
corporation, purchased that key, the fact that this CA is out of business
is certainly good cause for a bank to change its CA. Would you like
to be the supervisor of customer service when people start calling
about this problem their browser is complaining about? Remember that
99.99% of people have no idea what a certificate is, what a CA is, or
how to judge whether or not a given CA exercises due diligence when
issuing a cert.
One member of this mailing list, in a private exchange, noted that
he had asked his bank for their certificate's fingerprint. My
response was that I was astonished he found someone who knew what
he was talking about.
I'm not saying your toolbar is a bad idea; in fact, I think it's a good
one. But the problem of verifying certificates is a very deep one,
and simple answers will not solve the phishing or MITM problem.
Duane
> I'm not saying your toolbar is a bad idea; in fact, I think it's a good
> one. But the problem of verifying certificates is a very deep one,
> and simple answers will not solve the phishing or MITM problem.
Hmmm I think I did make this point the other day :P I tend to agree with
Gerv's thinking along the lines of a points score system, just like
spamassassin works on spam, hell give users control over setting points
for each item and points for a site to be thought of as spam, perhaps
you could even bayes filter the incoming content... Just thinking out
loud...
Nelson B
> Where are these 'Grant' dialogs?
They were part of the browser when the Java engine was part of
the browser, as in Netscape 4.x. They were used when a java
applet requested extra privilege. Netscape had defined some
certificate extensions that were used by one or more CAs to
facilitate the display of CA logos. NSS contained some code
to help the browser find the relevant logo URLs. That code
is now "dead code", meaning that it is there in NSS, but nothing
ever calls it (or indeed can call it, since it's not exposed
outside of the shared library).
> Are they available under Firefox / Thunderbird?
I don't believe so. Today, the Java engine is separate from the
browser, and has its own dialogs that ask the user about permissions.
> So, if we were to file a bug asking to revert
> back to the security model of the signer's
> brand, that would be an easier sell?
I don't think so. Today the browser UI decisions are made by a
different set of folks than 8 years ago. Or to put it another
way, it would be an easier sell to people who don't work on
mozilla now. :)
--
Nelson B
Nelson B
> Good, I'm glad you understand what is meant by
> branding. By forcing VeriSign to brand themselves
> like Virgin, they are laid bare to their trusting public.
> Who knows, maybe they will surprise us all.
By now you've read that this branding idea was actually implemented,
at least partially, for a limited set of CAs, in the old
Netscape 4.x browsers. The Netscape security managers wanted
the users to know that it was the CA, and not Netscape, that
was vouching for the authenticity of the site. It didn't go
very far due to a tight screen real-estate market.
> Either way, right now, Mozilla is hiding the fact that
> Verisign is being used to create relationships that
> are falsely presented as trust. In fact, Firefox lies
> about it by saying that the user trusts this cert and/or
> provider.
When you run a program, you are trusting it. You may have no idea
what's in it, or what it does, but when you turn it loose on your
computer, you surely are trusting it. It may be trustworthy,
or it may abuse your trust, but you're trusting it.
Mozilla lets you decide to stop trusting parts of it (e.g. certs
that were marked trusted by default). When you turn off the trust
flags on some certs, you're trusting mozilla to honor your settings.
I think the most accurate statemtent you could make in response to
a mozilla dialog about you trusting a cert is "oh, I didn't *know*
I was trusting *that* cert". But until you change it, you are
trusting it. It's part of the software that you trusted on your
computer.
> What I'm suggesting is that the truth be revealed to
> the users: Verisign is the one who made the relationship,
> and that should be on the chrome.
Lots of former Netscape security people agree with you, I think,
including your's truly. Maybe you can succeed in fighting the
chrome real-estate battles. In my view, the people who are the
controllers of the chrome real-estate have historically not viewed
the security info as worth the space. Maybe now they'll change
their view, but it won't be easy. And few of them participate here.
>> Also, even if they do, they have no choice. A particular shop is only
>> protected by a cert from one company. It's trust that company, or shop
>> somewhere else. Those are the only options.
No they're not. (well, maybe in FF, which I don't use.)
In seamonkey 1.x, when I visit a web site with a cert from an
unknown or untrusted issuer, I get a big dialog that gives me the
choice of trusting that specific server's cert, even though the
issuer is (and remains) untrusted. Now, *I* generally choose not
to override this. But users have this choice.
>> And we are not in a million years going to persuade users, if they've
>> found a product they like, to leave that shop and find it somewhere
>> else just because the CA has a slightly tarnished reputation.
Or even if the CA has no reputation at all, and is invalid. I remember
back in early 2000 reading a LONG blue rant from a user who had found a
web site that offered absurdly low prices on something he wanted.
When he went to "check out", his browser alerted him to many problems
with the cert: name didn't match, invalid signature, unknown issuer,
and some other things I don't now recall. All of these things should
have been setting off alarm bells in his head, but he was determined to
get those low prices. His browser let him override all of those issues,
except one. He was FURIOUS! How dare the browser get in the way of his
shopping happiness! But he showed us! He went and fired up another
browser and got past all the warnings (just one from that other browser)
and entered his credit card info! I never heard from him again.
I'd bet that he ended up reporting his credit card "lost or stolen" some
time later when he discovered that his card number had somehow gotten
into the hands of the bad guys. I'll bet he never got the merchandise
that he ordered, either.
I thought this actually made a pretty good case for removing alltogether
the abililty to override security errors.
I think that if the browser is going to continue to let the user
override security errors, then when the user does so, it should tell
the user in no uncertain terms that the user has overridden security,
and that the user will have NO security thereafter, and should turn
off the lock to make the point.
> Right now, the reason VeriSign doesn't care is because
> the users don't know who they are. Once users know
> who Verisign is, I think they'll have a chance to show
> how much they want to care about security ;-)
Hmmm. I think Bob already explained this, but ... it was Verisign
who led the way requesting branding logos in Communicator 4.x.
Really, stop all the Verisign bashing. It doesn't enhance your
credibility. Especially when history contradicts your hypothesis.
--
Nelson B