dropping the root is useless

5 views
Skip to first unread message

Ian G

unread,
Dec 28, 2008, 7:46:16 AM12/28/08
to mozilla's crypto code discussion list
On 28/12/08 12:13, Kai Engert wrote:

> If we'd like to be strict, we could remove CAs from our approved list if
> they have shown to be non-conforming in the above way.


Yes, we could! But this is what we call a blunt weapon. It is also a
dangerous weapon. Consider (all) the consequences in the current case.

First, losses we will incur, regardless:

1. Certs: All end-users who rely on these certs will lose. That
probably numbers in the millions. All subscribers will lose, probably
in the thousands. The CA will lose; potentially it will lose its
revenue stream, or have it sliced in half (say), which is what we would
call in business circles a plausible bankrupcy event.

2. Mozo: Mozilla will lose because of all the undelivered security
(all those good certs and subscribers and end-users). It may be sued by
the CA and the CA's investors and/or the receiver/liquidator for a bad
decision.

3. Industry: All other CAs will lose because they will now have to
include in their business plans the possibility of a root being dropped
by a bad decision.

4. Security will go down, because less certs are delivered and in
use. (It's hard to calculate the secondary losses here, but not
impossible.)

Second, the losses we seek to stop:

1. Against that you can weigh the damages done so far and the harm to
protect against. We know it is down to 11 or so certs, all revoked.
Therefore, we know that the damage is stopped now, and there is only an
unknown window of 11 certs from their issuance to last week.

In practice, this calculates as zero damages, because the likely
scenario is that no harmful certs were issued [1].

2. There is the possible benefit to the other CAs as a punishment tool,
in the case where the decision is good (see 3. above). There could be a
knock-on effect in convincing CAs to tighten their game. However, this
needs to be balanced against other costs and loss of certs, and in
practice, the dominant factor is this: more certs is more security,
less certs is less security.

Until we get new info, this is the estimate on the table. Therefore
dropping the root will cause large losses, and will stop nothing, in the
current case.

The wider policy problem here for Mozilla, for this forum, and for the
whole PKI is that no matter which way you analyse, it, we've got nothing
in the way of a punishment. Stick any numbers you like in the above
example, and watch what happens. Removing the root is useless as a
punishment. It only has downside, for all. It will likely never
happen, and we should stop talking about it.


iang


[1] no harmful certs == unreliable certs issued to people to do bad
things. E.g., we ignore false certs that are already controlled.

Eddy Nigg

unread,
Dec 28, 2008, 8:21:55 AM12/28/08
to
On 12/28/2008 02:46 PM, Ian G:

>
> 1. Certs: All end-users who rely on these certs will lose. That probably
> numbers in the millions. All subscribers will lose, probably in the
> thousands. The CA will lose; potentially it will lose its revenue
> stream, or have it sliced in half (say), which is what we would call in
> business circles a plausible bankrupcy event.

Not relevant.

> 2. Mozo: Mozilla will lose because of all the undelivered security (all
> those good certs and subscribers and end-users). It may be sued by the
> CA and the CA's investors and/or the receiver/liquidator for a bad
> decision.

I suggest to you refrain from now on to give legal advice on these
matters, Mozilla has a legal department and lawyers for that. But if we
are at it, Mozilla has no legal or any other requirement (as far as I
know) to include or keep a root. The Mozilla CA Policy clearly reserves
the right to remove any of the roots (including all of them) at any
time. If this isn't the case we all should know about it. Additionally
it's Mozilla which also has the right to sue the CA and not the other
way around. Just for your knowledge, Microsoft and other vendors reserve
the same right.

> 3. Industry: All other CAs will lose because they will now have to
> include in their business plans the possibility of a root being dropped
> by a bad decision.

Very good! Even though I'm not the proponent of the proposal to remove
Comodo's root (instead work towards a real improvement, with the removal
as a stick), this is exactly what possible removal should achieve.
Refrain CAs from making bad decisions. More than that, some CAs are on
disadvantage when competing with CAs which are willing to take high
risks. This must be clearly recognized and I'm all in favor of having to
compete on equal footing. This isn't the case today.

>
> 4. Security will go down, because less certs are delivered and in use.
> (It's hard to calculate the secondary losses here, but not impossible.)

That's easy to revert, I'm certain there are a bunch of CAs ready to
issue new certs to them.

> 1. Against that you can weigh the damages done so far and the harm to
> protect against. We know it is down to 11 or so certs, all revoked.

That's absolutely not correct. Right now nobody knows - including Comodo
- how many certs are really unvalidated because of the lack thereof.
This is what I know at the moment and it would be good if Comodo could
dispute that claim and advice differently or confirm it.

> 2. There is the possible benefit to the other CAs as a punishment tool,
> in the case where the decision is good (see 3. above). There could be a
> knock-on effect in convincing CAs to tighten their game.

Right! I'm all in favor of that, lets go for it!

> However, this
> needs to be balanced against other costs and loss of certs, and in
> practice, the dominant factor is this: more certs is more security, less
> certs is less security.

Less unvalidated certs is more security, not less. An unknown number of
unvalidated certs is no security at all.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org

Ian G

unread,
Dec 28, 2008, 8:23:28 AM12/28/08
to mozilla's crypto code discussion list
On 28/12/08 12:13, Kai Engert wrote:

> From my perspective, it's a CA's job to ensure competent [stuff].

OK.

> The auditing required for CAs is supposed to prove it.

This might be a bit too strong. Let's look at that.

What audits do is confirm criteria, and provide an opinion that the
criteria are met, according to the opinion of the Auditor [1].

Now let's look at some of the limitations or caveats or bugs in that
process:

1. It is up to you to read the criteria and decide if they are
appropriate to your needs.

2. It is also up to you to decide whether the opinion letter is "good
enough" whatever that means.

2.b. And, it is also up to you to investigate and understand the
various languages and procedures that an Auditor uses, customarily, to
weaken an apparently strong claim.

3. It is also up to you to check that the Audit verifies the Mozilla
policy. I don't know, but my understanding was that Audits are
generally done to WebTrust or ETSI criteria, and not to the policy.
There would need to be a specific comment from the Auditor to say that
the policy was included in scope.

Has anyone here read the opinions and confirmed inclusion of the policy
in the audit opinions?

4. It is also up to you to decide whether the Auditor has
characteristics that speak highly of the opinion. Without getting into
that debate, suffice to say, the singularity of the process is a
weakness in and of itself.

Where does this get us?

It should be clear that Audits don't "prove" anything. At all. If you
take an audit to prove something then *you have made a mistake* ;
although we might agree that that this is a mistake that many people are
comfortable for you to make, and they are unlikely to correct you in.

The question is more likely placed as whether you can rely on an Audit.
If you get through all the above, your answer is probably "maybe." If
you have a friend in the business, feel free to pose this question to
them. Ask around, get some opinions.

(And, if we accept the above, if you don't get through all of your above
checks, how can your answer be any better than "maybe" ?)

Perhaps more broadly, we could ask whether we as a community get any
benefit from an audit at all, given the rather drastic nature of an
individual "maybe." I think the answer is yes, cautiously: it probably
ensures that a CA is up to a known and reasonable level of practices [2].

So, at least we know where a CA is "likely" at, once they've passed
their audit. Whereas before, we would be simply relying on advertising,
which is hopeless.

The good news is that we can actually cover a lot of these weaknesses by
moving to more open disclosures. The Internet has given us wonderful
opportunities to move more information more reliably, something that is
not factored into current Audit thinking.

So it may not be a huge issue that classical Audits have flaws (c.f.,
they are not perfect, nor prove what you want) as long as we look at
where the flaws are found in practice and identify ways to use the open
source approach to overcome those flaws [3].

iang

[1] disclosure, I work as an auditor

[2] I am ignoring costs analysis here, so it may be that the benefit
described does not return on investment.

[3] we sometimes call this open governance.

Eddy Nigg

unread,
Dec 28, 2008, 8:57:22 AM12/28/08
to
On 12/28/2008 03:23 PM, Ian G:

> [1] disclosure, I work as an auditor

Since you are making a claim here of being an auditor - and specially in
the context of WebTrust or similar criteria, can you please also
disclose which formal training and titles you have? For which audit firm
are you working currently and/or have you worked in the past? Thanks.

Ian G

unread,
Dec 28, 2008, 9:24:15 AM12/28/08
to mozilla's crypto code discussion list
(following is just for the record so as to deal with the response. No
new info is in here for other readers.)

On 28/12/08 14:21, Eddy Nigg wrote:
> On 12/28/2008 02:46 PM, Ian G:
>>
>> 1. Certs: All end-users who rely on these certs will lose. That probably
>> numbers in the millions. All subscribers will lose, probably in the
>> thousands. The CA will lose; potentially it will lose its revenue
>> stream, or have it sliced in half (say), which is what we would call in
>> business circles a plausible bankrupcy event.
>
> Not relevant.


Well! If they are not relevant, then perhaps we can turn SSL off, with
no consequences?


> I suggest to you refrain from now on to give legal advice on these
> matters, Mozilla has a legal department and lawyers for that. But if we
> are at it,


Let's deal with this self-contradictory statement.

To ignore the obvious legal ramifications (agreements in RPAs,
disclaimers to end-users, potential lawsuits ...) would be negligence, IMHO.

We know the ramifications exist. We know they may be serious. We know
that assertations of security are being made to end-users. Hence to
continue making these assertations, and not treat them seriously would
be negligence.

I personally choose not to follow that path into negligence, and will
continue to consider the legal ramifications, which leads to the
question of how we consider them.

We could simply refer them to the legal department, as you suggest.
Mozilla has a legal department, as you kindly point out, but they are
silent. They may have entirely good reasons for being silent, but that
makes them more or less useless for the work of this forum. So
referring them to that legal department is not an option for now.

We could simply refer them to our own legal department. But, we are all
here as volunteers, and while some of the businesses may like to put
their counsel at the service of this group, this won't work because of
conflicts of interest. This is therefore not an option.

Which leaves the final option: we have to deal with it, ourselves, and
we have to work with the known and understood caveats that none of us
are lawyers.

Others may have other views, but I would suggest that in this forum, we
have to consider the legal ramifications.


> Mozilla has no legal or any other requirement (as far as I
> know) to include or keep a root.


No, I'm afraid there is an agreement to list the root, under a policy.
Once listed, Mozilla has to operate according to its side of the bargain.

This is a general consequence of business, there is nothing special
about it. Ask any experienced business person.


> The Mozilla CA Policy clearly reserves
> the right to remove any of the roots (including all of them) at any
> time. If this isn't the case we all should know about it.


The problem being, that even if it reserves the right to make a choice
for any reason, this does not give Mozilla carte blanche. If it makes a
bad choice, a judge can imply a "reasonableness" test.

This is one of those areas where we really do need lawyers in the
conversation, but I will short circuit that with a prediction of mine, only:

the lawyers will likely say, "we will find out in court."

Great answer, huh? It sure keeps the lawyers in work, and it provides
little help for us. See earlier analysis.


> Additionally
> it's Mozilla which also has the right to sue the CA and not the other
> way around. Just for your knowledge, Microsoft and other vendors reserve
> the same right.


Everyone has the right to walk into court. That point is empty of
practical value.


>> 3. Industry: All other CAs will lose because they will now have to
>> include in their business plans the possibility of a root being dropped
>> by a bad decision.
>
> Very good! Even though I'm not the proponent of the proposal to remove
> Comodo's root (instead work towards a real improvement, with the removal
> as a stick), this is exactly what possible removal should achieve.


Please read it carefully. a root being dropped by a BAD decision.


> Refrain CAs from making bad decisions.


Oh, ok. No, I meant MOZILLA making a bad decision. E.g., a mistake.


> More than that, some CAs are on
> disadvantage when competing with CAs which are willing to take high
> risks. This must be clearly recognized and I'm all in favor of having to
> compete on equal footing. This isn't the case today.


Indeed. You won't achieve it by dropping a root, and you won't achieve
it by _threatening_ to drop a root.

I suggest you will achieve precisely the reverse, because some CAs will
have an advantage in that negotiation, and they will overcome any
positive benefit in a way that has little bearing on security for the users.

Standard business stuff, really.


>> 4. Security will go down, because less certs are delivered and in use.
>> (It's hard to calculate the secondary losses here, but not impossible.)
>
> That's easy to revert, I'm certain there are a bunch of CAs ready to
> issue new certs to them.


That's hopeful marketing talk, not security analysis!


>> 1. Against that you can weigh the damages done so far and the harm to
>> protect against. We know it is down to 11 or so certs, all revoked.
>
> That's absolutely not correct. Right now nobody knows - including Comodo
> - how many certs are really unvalidated because of the lack thereof.


They stated how many, IIRC. I recall it was something like 111 certs
issued and 11 outstanding that had not been re-verified within around 48
hours (these numbers are not accurate, but indicative) and were
therefore revoked.

Are we disputing their stated claims? Or are you making a wider claim
that their entire cert base is unverified? Or?


> This is what I know at the moment and it would be good if Comodo could
> dispute that claim and advice differently or confirm it.
>
>> 2. There is the possible benefit to the other CAs as a punishment tool,
>> in the case where the decision is good (see 3. above). There could be a
>> knock-on effect in convincing CAs to tighten their game.
>
> Right! I'm all in favor of that, lets go for it!


Well, that is the expectation of some people. I suggest it is
hopelessely unfounded, in business terms, and may achieve more damage
than good.


>> However, this
>> needs to be balanced against other costs and loss of certs, and in
>> practice, the dominant factor is this: more certs is more security, less
>> certs is less security.
>
> Less unvalidated certs is more security, not less. An unknown number of
> unvalidated certs is no security at all.


Yes, we are now getting into the difficult area of estimating the
overall benefit of different models of security. This game is well
known to be controversial. Let's leave that aside for now.


iang

Ian G

unread,
Dec 28, 2008, 9:36:17 AM12/28/08
to mozilla's crypto code discussion list
On 28/12/08 14:57, Eddy Nigg wrote:
> On 12/28/2008 03:23 PM, Ian G:
>
>> [1] disclosure, I work as an auditor
>
> Since you are making a claim here of being an auditor - and specially in
> the context of WebTrust or similar criteria,


OK, to answer the implied question here, the criteria are those written
by David Ross, and are known sometimes as DRC. They are listed here:

http://rossde.com/CA_review/

For the interested readers: DRC were developed following a review of
WebTrust by David Ross, and his criteria cross-reference to WebTrust for
ease of comparison. Those are my words, see the link for his own words.


> can you please also
> disclose which formal training and titles you have?


BSc(hons) Computer Science, University of NSW.
MBA, London Business School.


> For which audit firm
> are you working currently and/or have you worked in the past? Thanks.

None.


Interested readers might now relate this to point 9, 10 of the policy.

http://www.mozilla.org/projects/security/certs/policy/


iang

Eddy Nigg

unread,
Dec 28, 2008, 9:42:25 AM12/28/08
to
On 12/28/2008 04:24 PM, Ian G:

>>> 1. Certs: All end-users who rely on these certs will lose. That probably
>>> numbers in the millions. All subscribers will lose, probably in the
>>> thousands. The CA will lose; potentially it will lose its revenue
>>> stream, or have it sliced in half (say), which is what we would call in
>>> business circles a plausible bankrupcy event.
>>
>> Not relevant.
>
>
> Well! If they are not relevant, then perhaps we can turn SSL off, with
> no consequences?
>

I was clearly replying to the later part:

The CA will lose; potentially it will lose its revenue stream, or have
it sliced in half (say), which is what we would call in business circles
a plausible bankrupcy event.

It's not relevant.

>
> No, I'm afraid there is an agreement to list the root, under a policy.
> Once listed, Mozilla has to operate according to its side of the bargain.
>

Apparently you are reading something I haven't.

> The problem being, that even if it reserves the right to make a choice
> for any reason, this does not give Mozilla carte blanche.

Mozilla can make a bad decision, no doubt. This case is most likely not
one of those you are referring to.

>
> Please read it carefully. a root being dropped by a BAD decision.

A root isn't removed before careful considerations. A bad decision
doesn't warrant not to remove any roots at all if necessary. Mozilla can
also reinstate a root.

>
> They stated how many, IIRC. I recall it was something like 111 certs
> issued and 11 outstanding that had not been re-verified within around 48
> hours (these numbers are not accurate, but indicative) and were
> therefore revoked.

That's for the specific certstar case. Domain validation isn't performed
by Comodo on a wide scale apparently and perhaps no validation is
performed at all.

Ian G

unread,
Dec 28, 2008, 10:13:31 AM12/28/08
to mozilla's crypto code discussion list
Hi Kai,

long reply, I appreciate the grounding in actual policies and practices!
This allows us to explore what we really can and cannot do.

(I've cut two of your comments out to other posts where they might be
generally intersting for the wider audience.)


On 28/12/08 12:13, Kai Engert wrote:

> After having read the posts related to the "unbelievable" event, I
> understand the event involved an approved CA and an external entity they
> work with.


Seems about right.


> From my perspective, it's a CA's job to ensure competent verification
> of certificate requests. The auditing required for CAs is supposed to
> prove it.

[see other post]

> The verification task is the most important task. All people and
> processes involved should be part of the assuring audit.

> The current Mozilla CA Certificate Policy says:
> "6. We require that all CAs whose certificates are distributed with our
> software products: ... provide attestation of their conformance to the
> stated verification requirements ..."


OK! And, we can reasonably suggest that pt 7 covers verification, as
per the above.

> In my opinion, it means, a CA must do this job themselves.


No, to me, it means the CA must provide attestation of conformance by an
independent party. That means they must show how they meet the things
that Mozilla lists in pt 7.

Which language suggests they have to do verification *themselves* ?

BTW, it would be quite problematic to insist that the CAs do this job
themselves.

CAs are not generally experts on the issues raised. Traditionally, CAs
outsource the processess within verification to a range of different
organisations: government registries, commercial credit agencies,
credit card companies, passport offices, birth registries, etc. That
is, to insist they "do it themselves" would mean that they would have to
develop skills that might be better handled elsewhere, and might in the
end reduce to moving the deckchairs around.


> The policy currently does not appear to handle the scenario where a CA
> delegates the verification job to an external entity. So it's unclear
> whether it's "forbidden" or "allowed if the external entity has received
> equivalent attestation of their conformance".


I conclude it is allowed. However, whichever way it is done, the policy
still insists that conformance to pt 7 is required.

So, following that policy, a reasonable investigation to pursue in the
current case is what that form of the attestation was, and how precise
it was, etc.


> In my personal opinion, a CA violates the Mozilla CA Certificate Policy
> if they delegate the verification job to an external entity not owning
> "attestation of their conformance to the stated verification requirements".


I'm not sure I parse that, but I think you mean:

If the CA delegates,
and does not "own" the "conformance" requirement,
then they have violated the policy.

If so, ok. I see the following simplification:

If the CA does not "own" the
"conformance to verification" requirement,
then they have violated the policy.


> If we'd like to be strict, we could remove CAs from our approved list if
> they have shown to be non-conforming in the above way.


[see other post]

> In any case, the CA policy should get clarified about involving external
> entities in the verification and issueing process.


There are normal business and PKI assumptions in operation here:

The CA will involve external entities for as many things as possible.

The CA will document the external entities.

The CA will take responsibility for the result.

(The CA will express its liability and warranty in its RPA.)

It may be that you want to surface and state these assumptions.

However, to turn it into a criteria or policy point, you would need to
much more clearly refine your point, *and* you should clearly relate it
to how this will improve security. I suggest this is much tougher than
it sounds.

E.g., Which external entities are OK? Why? How are they checked?

Is it ok to accept an audit? Which audit?

Where is the line drawn? Is a passport an outsourcing? If not, is a
credit card? Is a website?

Why consider external entities when we don't describe documents? If we
care to regulate external entities, shouldn't we also regulate use of
credit cards, which are known to be poor identity documents?

Is one check enough? Two? Correlated? Serial or parallel?

And add a thousand other questions. It gets complex!

It is for this reason of complexity that we normally apply a
"reasonableness" test. It is reasonable to use external entities, and
as long as it is stated in the CPS, then it is up to each party to
decide whether they accept that for their individual circumstances.

(Those parties include: the CA, auditor(s), vendors, downstream
vendors, relying parties, and ultimately end-users.)


> All existing CAs
> should be required to make a statement about their current business
> practices with regards to external entities.


Right, but I would say that a statement in the CPS covering the external
parties is assumed. From my personal view, this would fall in the
general bucket of a material statement that should be disclosed, just
from normal business, auditing, and quality approaches.

Does anyone see any different?

The problem you may be facing is that you have not read the CPS, each
CPS, and you are only now being surprised at the subtleties and
complexity that may be lurking there. See my other comment about the
(audit) reliance issues facing you and every other end-user.

Complexity here provides a serious limit on the value of the process.
We do not improve matters by making things more complex.


iang

Ian G

unread,
Dec 28, 2008, 10:37:07 AM12/28/08
to mozilla's crypto code discussion list
On 28/12/08 15:42, Eddy Nigg wrote:
> On 12/28/2008 04:24 PM, Ian G:
> I was clearly replying to the later part:
>
> The CA will lose; potentially it will lose its revenue stream, or have
> it sliced in half (say), which is what we would call in business circles
> a plausible bankrupcy event.
>
> It's not relevant.


Well, that part may not be a loss that effects a security discussion.
But I've made the point before that economic interests are much more
important and may be dominant. See below the discussion of lawyers.

So perhaps you won't mind if I keep bringing them up. We might simply
disagree as to their practical relevance to the real world discussion.


>> No, I'm afraid there is an agreement to list the root, under a policy.
>> Once listed, Mozilla has to operate according to its side of the bargain.
>>
>
> Apparently you are reading something I haven't.


Statements (policy, etc) plus actions gives rise to an agreement. The
agreement doesn't have to be written in one document to exist, it can
exist without anything to read, or with many things to read.


>> The problem being, that even if it reserves the right to make a choice
>> for any reason, this does not give Mozilla carte blanche.
>
> Mozilla can make a bad decision, no doubt. This case is most likely not
> one of those you are referring to.


Well, who is going to warrant that for Mozilla?


>> Please read it carefully. a root being dropped by a BAD decision.
>
> A root isn't removed before careful considerations. A bad decision
> doesn't warrant not to remove any roots at all if necessary. Mozilla can
> also reinstate a root.


If in court, we can be sure that the CA will argue that the decision is
bad. The judge will bend over backwards to let the CA make that case;
that's what the court is there for.

(This then turns on who has the burden, and what question has to be
answered. Er, now we need the lawyers.)

What I'm about here is that: in any wider business analysis, the answer
is that, short of total collapse, do not remove the root. And if there
is total collapse, you will be wrong regardless, so it doesn't really
matter what you do.

I am not saying I *like* it. In fact, I don't like it.

I'm saying the tool is bankrupt. Think of other tools, this one will
not work for you.

Let me put it another way: one phone call from the CA's lawyer to
Mozo's lawyer is probably sufficient to solve this problem *for the CA*.

Ask yourself whether you have a lawyer. Ask your lawyer whether he can
make the phone call. Ask your lawyer how the phone call will go (he
doesn't need to make it).

Let us know what he says, for the education of us all.


>> They stated how many, IIRC. I recall it was something like 111 certs
>> issued and 11 outstanding that had not been re-verified within around 48
>> hours (these numbers are not accurate, but indicative) and were
>> therefore revoked.
>
> That's for the specific certstar case. Domain validation isn't performed
> by Comodo on a wide scale apparently and perhaps no validation is
> performed at all.


Oh, that's a new claim, beyond this reseller.

Is there any evidence? If so, then maybe there should likely be a new
investigation, and widespread revocations by the CA of the non-verified
certs. OK, as discussed earlier, actual investigations are outside
scope of here (which begs the important question of where it is in scope
of!) so let's not speculate further on Comodo's exact position.

Back to the damages estimate: we still need to form an estimate of how
many certificates were issued to people of malintent.

Without that, we are still left with a damages estimate of zero, albeit
one multiplied by a much larger number of users, with a much greater
range of possible error.

iang

David E. Ross

unread,
Dec 28, 2008, 11:06:25 AM12/28/08
to
On 12/28/2008 4:46 AM, Ian G wrote [in part]:
> On 28/12/08 12:13, Kai Engert wrote:
>
>> If we'd like to be strict, we could remove CAs from our approved list if
>> they have shown to be non-conforming in the above way.
>
>
> Yes, we could! But this is what we call a blunt weapon. It is also a
> dangerous weapon. Consider (all) the consequences in the current case.
>
> First, losses we will incur, regardless:
>
> 1. Certs: All end-users who rely on these certs will lose. That
> probably numbers in the millions. All subscribers will lose, probably
> in the thousands. The CA will lose; potentially it will lose its
> revenue stream, or have it sliced in half (say), which is what we would
> call in business circles a plausible bankrupcy event.
>

So when a CA behaves badly, we should still be concerned that the CA
might lose money? Because a CA might go bankrupt, we should do nothing?

How about the users of Mozilla products who might lose money or even go
bankrupt because they trusted a root certificate from such a CA? No,
such losses are not known (yet). What did happen, however, indicates
that such losses are indeed possible and not only through Certstar.

--
David E. Ross
<http://www.rossde.com/>

Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.

David E. Ross

unread,
Dec 28, 2008, 11:17:26 AM12/28/08
to

Because of the recent discussions in this newsgroup, I updated my
criteria. See the "Document Versions" page. Specifically, I added the
requirement: "The CP details how the CA verifies that RAs operate in
accord with the CA's policies."

Note that, in my criteria, I lump external reselllers with RAs.

Ian G

unread,
Dec 28, 2008, 12:28:25 PM12/28/08
to mozilla's crypto code discussion list
On 28/12/08 17:06, David E. Ross wrote:
> On 12/28/2008 4:46 AM, Ian G wrote [in part]:

>> First, losses we will incur, regardless:
>>

>> ... The CA will lose; potentially it will lose its


>> revenue stream, or have it sliced in half (say), which is what we would
>> call in business circles a plausible bankrupcy event.
>>
>
> So when a CA behaves badly, we should still be concerned that the CA
> might lose money? Because a CA might go bankrupt, we should do nothing?


No, that's not my conclusion. I simply listed some losses. Now add it
to the other comment I made to Eddy's response:


> Let me put it another way: one phone
> call from the CA's lawyer to Mozo's
> lawyer is probably sufficient to
> solve this problem *for the CA*.


The problem is, that particular cost will have impacts. We can talk all
we like about the proper or right thing to do, but Mozilla's general
counsel will likely think differently, will likely urge caution.

(That's just general business knowledge...)


> How about the users of Mozilla products who might lose money or even go
> bankrupt because they trusted a root certificate from such a CA? No,
> such losses are not known (yet). What did happen, however, indicates
> that such losses are indeed possible and not only through Certstar.


Yes, indeed. That's a big question.

What I am suggesting is that "dropping the root" will not address that
question. It is too blunt a weapon to be used reliably.

iang

Kyle Hamilton

unread,
Dec 28, 2008, 6:37:34 PM12/28/08
to mozilla's crypto code discussion list
On Sun, Dec 28, 2008 at 9:28 AM, Ian G <ia...@iang.org> wrote:
> On 28/12/08 17:06, David E. Ross wrote:
>> How about the users of Mozilla products who might lose money or even go
>> bankrupt because they trusted a root certificate from such a CA? No,
>> such losses are not known (yet). What did happen, however, indicates
>> that such losses are indeed possible and not only through Certstar.
>
> Yes, indeed. That's a big question.
>
> What I am suggesting is that "dropping the root" will not address that
> question. It is too blunt a weapon to be used reliably.

Considering that "trustability" is viewed as a binary state, it's the
only weapon that Mozilla has.

-Kyle H

Ian G

unread,
Dec 28, 2008, 6:42:34 PM12/28/08
to mozilla's crypto code discussion list
On 29/12/08 00:37, Kyle Hamilton wrote:
> On Sun, Dec 28, 2008 at 9:28 AM, Ian G<ia...@iang.org> wrote:
>> On 28/12/08 17:06, David E. Ross wrote:
>>> How about the users of Mozilla products who might lose money or even go
>>> bankrupt because they trusted a root certificate from such a CA? No,
>>> such losses are not known (yet). What did happen, however, indicates
>>> that such losses are indeed possible and not only through Certstar.
>> Yes, indeed. That's a big question.
>>
>> What I am suggesting is that "dropping the root" will not address that
>> question. It is too blunt a weapon to be used reliably.
>
> Considering that "trustability" is viewed as a binary state, it's the
> only weapon that Mozilla has.


Yes. This is reason for concern.

iang

Kyle Hamilton

unread,
Dec 28, 2008, 6:45:32 PM12/28/08
to mozilla's crypto code discussion list
On Sun, Dec 28, 2008 at 7:37 AM, Ian G <ia...@iang.org> wrote:
>> That's for the specific certstar case. Domain validation isn't performed
>> by Comodo on a wide scale apparently and perhaps no validation is
>> performed at all.
>
>
> Oh, that's a new claim, beyond this reseller.

You're only just now figuring that the security community (those who
care about real security, anyway) is claiming that this is a SYSTEMIC
problem in Comodo's operations?

> Is there any evidence? If so, then maybe there should likely be a new
> investigation, and widespread revocations by the CA of the non-verified
> certs. OK, as discussed earlier, actual investigations are outside scope of
> here (which begs the important question of where it is in scope of!) so
> let's not speculate further on Comodo's exact position.

No, there isn't. That's the problem -- as has been stated elsewhere
in the discussion, security must by its nature be default-deny, not
default-accept. This is upheld in the Mozilla products' prevailing
view that "unknown_issuer is BAD".

> Back to the damages estimate: we still need to form an estimate of how many
> certificates were issued to people of malintent.

We can't know that, because Robin/Comodo won't tell us. As such, they
are hiding material information that we need to make a decision on
whether to continue trusting them.

> Without that, we are still left with a damages estimate of zero, albeit one
> multiplied by a much larger number of users, with a much greater range of
> possible error.

I'm actually stuck with a damages estimate of a finite number
greater-than-zero-but-less-than-all. If one RA can do it and did do
it, chances are that in order to stay competitive another one did as
well.

CertStar was found out, only due to the diligence of someone on this
list. How many other RAs haven't been found out yet? We can't know,
because Comodo won't say. This affects the confidence I have in their
system (i.e., it removes ALL confidence that Mozilla extended on my
behalf).

-Kyle H

Kyle Hamilton

unread,
Dec 28, 2008, 6:47:33 PM12/28/08
to mozilla's crypto code discussion list

FWIW, I agree.

Alright, I propose that, in a new thread, we open the table for
discussion of the problems inherent in the binary-state model, and
ways to mitigate these problems?

-Kyle H

Ian G

unread,
Dec 28, 2008, 8:09:27 PM12/28/08
to mozilla's crypto code discussion list
On 29/12/08 00:36, Kyle Hamilton wrote:
> On Sun, Dec 28, 2008 at 6:24 AM, Ian G<ia...@iang.org> wrote:


> Unlike you, Eddy actually runs a certifying authority. This means
> that he has operational experience with not only the technical sides
> of things, but also the legal sides of things.


I support your right to an opinion, but can you please ground your
criticisms in facts of relevance, rather than ad hominims.


> Just because you also happen to be an advocate for CAcert

Strawman. An Auditor is perhaps an advocate in the sense that he writes
an opinion. I have not done that, and won't for another 6 months at
current progress. Here's *just* the local dirt:

https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158

I think the advocacy claim looks a little silly, no? Absurd, even.


> (and --
> unlike Eddy -- feel the urge to hide that affiliation) does not mean
> that you actually run it, or have the depth or breadth of knowledge
> necessary to do so. This message shows me that you honestly don't
> care about what "security" actually is, you just care about "the
> end-user experience". This is NOT the same thing. As such, my
> opinion of your authority on the subject matter has diminished
> severely.


You are entitled to your opinion, but I would ask you to consider that
this is a policy forum, not an ad hominem shooting match.


> True "security" involves knowing what the risks are. Mozilla's policy
> for root inclusion tries to reduce the uncertainty for end-users;
> unfortunately, as has been pointed out repeatedly, there is still far
> too much uncertainty for end-users in Comodo's operations.


The point I have made is that the discussion of Comodo's operations is
outside scope of this forum. You may feel that you have an opinion, and
you have a right to it. However, this forum is not for the
investigation of breaches or failures to comply with policies.

If you dislike that, don't start a war against me. Suggest a policy
change to Mozilla. If you want wordings, try this:

x. Any breaches of security or failures to comply will be
discussed in the policy forum of Mozilla, a ruling by consensus
delivered, and will be binding on the CA.

Don't disagree with me in a post, do something. Write the proposal,
change the policy. Words are less important than acts.


> They have
> lost my trust, the same way that you have.


Now over to you. Act, not talk. Make a dispute resolution forum happen.


>> On 28/12/08 14:21, Eddy Nigg wrote:

>>> On 12/28/2008 02:46 PM, Ian G:
>>>> 1. Certs: All end-users who rely on these certs will lose. That probably
>>>> numbers in the millions. All subscribers will lose, probably in the
>>>> thousands. The CA will lose; potentially it will lose its revenue
>>>> stream, or have it sliced in half (say), which is what we would call in
>>>> business circles a plausible bankrupcy event.
>>> Not relevant.
>>

>> Well! If they are not relevant, then perhaps we can turn SSL off, with no
>> consequences?
>

> If Nelson can upbraid me for ad hominem attacks, I'm going to upbraid
> you for ad absurdem arguments.
>
> TLS (can we PLEASE stop using "SSL", since the last version of SSL
> that got ratified by any standards organization was SSLv2, and SSLv3
> is a hack that reached internet-draft phase but was never formally
> recognized?) has the option of negotiating a secure connection without
> the use of any certificates at all. (Further, SSLv3 also had the same
> mechanism.)
>
> There's still the "endpoint confidentiality" concept -- nobody between
> the client and the server that the client is talking to can hear
> what's being said between them. The problem that certificates (or key
> continuity management) is designed to solve is the problem where the
> client thinks it's talking to one server, when it's really talking to
> another (the "fraudulent endpoint" attack in the case where the
> server-endpoint doesn't pass any data to the real server, and the "man
> in the middle" attack in the case it does).


Er, Kyle, you are off on a tangent here. My point with Eddy was fully
addressed by him pointing out that he was only dealing with the last
sentance, I thought he was referring to the earlier sentances. A
reasonable clarification.


>> To ignore the obvious legal ramifications (agreements in RPAs, disclaimers
>> to end-users, potential lawsuits ...) would be negligence, IMHO.
>>
>> We know the ramifications exist. We know they may be serious. We know that
>> assertations of security are being made to end-users. Hence to continue
>> making these assertations, and not treat them seriously would be negligence.
>>
>> I personally choose not to follow that path into negligence, and will
>> continue to consider the legal ramifications, which leads to the question of
>> how we consider them.
>

> In my mind (and this is not legal advice, merely a statement of
> thought presented for the purposes of argument), Mozilla has a duty to
> me as an end-user to uphold the letter and spirit of its CA
> Certificate Policy. I've already presented my thought on how a full
> tort could be brought against Mozilla by the operator of any CA
> already in the trust list. If a Comodo-issued certificate causes any
> user damage after the initial disclosure on the list, a tort could be
> brought against Mozilla by that end-user.


I do not disagree! My point was that Mozilla also has a duty (however
arrived at) towards the CA.

Let me cast in simple terms. In this particular question, the CA talks
to the Mozo. The user doesn't even know to talk. The CA wins.

This is reality. I don't like it. I've been talking about what you say
for the last 4 years, and it hasn't happened.


>>> Mozilla has no legal or any other requirement (as far as I
>>> know) to include or keep a root.

>> No, I'm afraid there is an agreement to list the root, under a policy. Once
>> listed, Mozilla has to operate according to its side of the bargain.
>

> The policy explicitly provides for Mozilla removing a root, at its
> option. Section 4 of the CA Certificate Policy: "We reserve the right
> to not include a particular CA certificate in our software products,
> to discontinue including a particular CA certificate in our products,
> or to modify the "trust bits" for a particular CA certificate included
> in our products, at any time and for any reason."


(By the way, I was there when that section was written. I may even have
suggested some of the text? Now I don't like it. I want it changed. I
want it strengthened. What wrong is that?)


> It gives examples of the situations that it could do so in, but it
> also explicitly states that its appropriate reasons for doing so ARE
> NOT LIMITED TO those examples.
>
> Please also recognize that the right and protection of the many tends,
> at least in the US court system that Mozilla and Comodo are subject
> to, outweighs the right and protection of the few or one (the company
> which operates the CA).


This is where we make a judgement call. You call your estimated risks
and costs. I call mine.

None of us win this game. It only gets won in court.

Agree to disagree; think about the other side's point.


>> This is a general consequence of business, there is nothing special about
>> it. Ask any experienced business person.
>

> It may be -- but since this is a case where this certificate in
> Mozilla's root store was included for the purposes of identifying
> websites for the purpose of enabling commerce, and thus it had to
> operate under the WebTrust Principles and Criteria for Certification
> Authorities -- and in this case, since the root is also EV-enabled,
> WebTrust for Certification Authorities—Extended Validation Audit
> Criteria... well, any conduct which provides reasonable doubt as to
> the viability of its certificate issuance policies (and, in this case,
> such reasonable doubt exists) suggests that people who rely on
> Mozilla's adherence to its CA Certificate Policy in deciding to trust
> Mozilla's root list are relying on bad information.
>
> It's not much of a stretch to imagine that Mozilla is essentially
> violating a fiduciary duty if it doesn't remove the trust bits or the
> CA itself from the trust list.


I agree.

The problem is, the other theory exists as well. They get to be argued
out in the next forum: court.


> As a particular point, it states that it reserves the right to remove
> CAs for any reason. It does NOT state that it reserves the right to
> NOT remove a CA.


Mozilla can certainly reserve the right to remove the root. It can even
remove the root.

This however doesn't mean that it is protected from damages.

There is no disclaimer. No statement of warranty.

Join me in fixing these problems; don't shoot me because I bear an
uncomfortable message. If you shoot me, it isn't me that loses, it is
Mozilla.


>>> The Mozilla CA Policy clearly reserves
>>> the right to remove any of the roots (including all of them) at any
>>> time. If this isn't the case we all should know about it.
>>

>> The problem being, that even if it reserves the right to make a choice for

>> any reason, this does not give Mozilla carte blanche. If it makes a bad
>> choice, a judge can imply a "reasonableness" test.
>

> Is it reasonable to expect that a CA which is theoretically audited to
> financial certification standards, and is shown to have insufficient
> controls to maintain those standards, can stay in a position where it
> can cause financial harm to relying parties?


Look, we can all have our day in court, and argue as long as our legal
budget holds out .... the point is, is this what you are going to argue?
Does Mozilla wish to have its day in court?

This is not about what is RIGHT but about what happens in COURT. These
are two completely different things.


> As it stands, we do not know how many RAs Comodo has engaged. We do
> not know what types of certificates those RAs can submit requests for.
> We do not know how many of these have chosen to ignore the
> contractual obligation.
>
> And it's entirely possible that Comodo is relying on the "must
> internally audit at least 3% of EV-enabled issued certificates" as the
> standard for its "representative sample" (a charmingly vague term
> which suggests that a single request could be reviewed as a
> "representative sample"). The audit requirement only applies to
> ISSUED certificates, and there's no requirement that even 3% of
> requests received from each RA be reviewed/audited. (not to mention,
> even if they did audit 3% of each RA's submissions, it just means that
> out of 100 submitted requests, only 3 need to be reviewed. Put
> another way, 97 out of every 100 submitted requests could be bogus and
> Comodo wouldn't have any idea.)
>
> This is why I advocate more openness as regards the processes.
> Without that openness, I have absolutely no reason to trust Comodo.


I agree. It sucks. But, all of your complaint directly above is OUT OF
SCOPE. We are not invited here to audit, check, confirm or review any
RA or any CA. That right is reserved to MOZILLA and the CA's AUDITOR,
in the policy.

We are only here to talk policy. And in the "week of review", comment
about the CA of the week.

Yes, propose we open up the audit process. I'm all for it, and I do it.

But there is no way that I can compromise Mozilla's process by
overstepping the line. I am an "interested party," an opinion of mine
will one day be here. I must read the policy and follow it. I cannot
support an unfair attack on the process.

You have to change the policy and practices before you have any standing
in addressing the Comodo question.

That's my opinion of course. Until we find different. I'm waiting and
ready to be corrected by someone who does have authority over the forum.


>>>> 3. Industry: All other CAs will lose because they will now have to
>>>> include in their business plans the possibility of a root being dropped
>>>> by a bad decision.
>>> Very good! Even though I'm not the proponent of the proposal to remove
>>> Comodo's root (instead work towards a real improvement, with the removal
>>> as a stick), this is exactly what possible removal should achieve.
>>

>> Please read it carefully. a root being dropped by a BAD decision.
>
> My opinion is that this instant case would not be a "bad" decision.
> However, this would also be something that I'd suggest talking to the
> lawyers about. (I also tend to think that a waiver of attorney-client
> privilege would be appropriate, in this case, to promote the goals of
> "public process". However, my opinion does not control, and it
> doesn't come from a lawyer anyway.)


Yes, talk to the lawyers. "BAD" is subjective of course, until the
judge rules, and then it is fact.

[competitive / marketing talk deleted]

[dispute with comodo deleted]


>>>> 2. There is the possible benefit to the other CAs as a punishment tool,
>>>> in the case where the decision is good (see 3. above). There could be a
>>>> knock-on effect in convincing CAs to tighten their game.
>>> Right! I'm all in favor of that, lets go for it!
>>

>> Well, that is the expectation of some people. I suggest it is hopelessely
>> unfounded, in business terms, and may achieve more damage than good.
>

> This is, by the by, one reason why X.509's single-certificate-issuer
> model is (in practical terms) severely flawed. If a given certifier
> becomes untrusted (especially since there's a prevailing view that
> trust is 100% or 0%, evidenced in an argument against the creation of
> a "trustability in doubt" flag), there is no way for an affected
> certified entity who has followed all the rules to mitigate the damage
> caused by their certifier's state-change from "trusted" to
> "untrusted".


Right. Hence overly massive attention on what is a BAD decision, and
what is a good decision.


>>>> However, this
>>>> needs to be balanced against other costs and loss of certs, and in
>>>> practice, the dominant factor is this: more certs is more security, less
>>>> certs is less security.
>>> Less unvalidated certs is more security, not less. An unknown number of
>>> unvalidated certs is no security at all.

>> Yes, we are now getting into the difficult area of estimating the overall
>> benefit of different models of security. This game is well known to be
>> controversial. Let's leave that aside for now.
>

> I don't believe that we can.
>
> Mozilla's CA Certificate Policy includes the language "[...]based on
> the benefits and risks of such inclusion to typical users of those
> products" in point 1. That means that it's an essential aspect of
> this debate.
>
> Everything beyond that is subject first and foremost to that criterion.


Well. I don't disagree. But I try to avoid battles that cannot be won
by either side :)


iang

Eddy Nigg

unread,
Dec 28, 2008, 11:11:50 PM12/28/08
to
On 12/29/2008 03:09 AM, Ian G:

>
> The point I have made is that the discussion of Comodo's operations is
> outside scope of this forum. You may feel that you have an opinion, and
> you have a right to it. However, this forum is not for the investigation
> of breaches or failures to comply with policies.
>
> If you dislike that, don't start a war against me. Suggest a policy
> change to Mozilla. If you want wordings, try this:
>
> x. Any breaches of security or failures to comply will be
> discussed in the policy forum of Mozilla, a ruling by consensus
> delivered, and will be binding on the CA.
>

I don't think you are entirely correct, Ian. The community has its say,
is free to discuss, suggest, propose, vent its anger and more. The
ultimate decision lies with Frank and Mozilla's management, however
discussions, suggestions, opinions, proposals are an important part of
shaping those decisions I think. I'm saying this from experience as many
times the mentioned above influenced decisions and/or resulted directly
in actions. I think this is what makes Mozilla incredible unique.

Not every objection, suggestion or proposal results in a standing
ovation obviously, but overall I'm quite pleased. And it's a two way
street many times, as members of Mozilla and the community made
suggestions or voiced their opinion, which directly lead to changes at
the company *I* run. Sometimes this happened in the public forums,
sometimes in private. The decisions are taken obviously elsewhere,
however this forum directly influenced some them.

In that respect I disagree that this forum isn't the right place to
discuss, disclose, propose, exchange thoughts and even investigate. I
wouldn't know a better place. And in the same time, I'd disagree that
the community should make the ultimate decision, the responsibility is
clearly with the Mozilla Foundation (?) and must be decided there.

David E. Ross

unread,
Dec 29, 2008, 12:40:06 AM12/29/08
to
On 12/28/2008 3:45 PM, Kyle Hamilton wrote [in part]:
> CertStar was found out, only due to the diligence of someone on this
> list. How many other RAs haven't been found out yet? We can't know,
> because Comodo won't say. This affects the confidence I have in their
> system (i.e., it removes ALL confidence that Mozilla extended on my
> behalf).

Actually, Eddy discovered the problem only through the fortuitous
receipt of spam from CertStar. If he had not received the spam -- even
if others had received it -- it is possible the problem would never have
been discovered. This is why the discovery is so frightening.

Now that it is known that a subordinate reseller operating under one CA
issued certificates without authenticating the identity of the
subscribers, we know that the theoretical concern expressed (before all
this) about resellers is no longer theoretical. NOW is the time to
require that all CAs supervise the operations of their RAs and
resellers. This must be done in a way that independent audits of the
CAs examine the implementation of such supervision, which can be
accomplished by requiring (at least with respect to the Mozilla
database) that CPs explicitly address how that supervision is performed.

Either a CA's CP must explicitly state that there are NO external RAs or
resellers, or else the CP must describe how external subordinates are
monitored. Without this, a CA's request to have its root certificate
included in the Mozilla database should be denied. Since an audit will
generally report on the implementation of such a policy but not
necessarily on the policy's adequacy, the internal and public reviews of
CA requests must examine the adequacy of the CA's policy for monitoring
external subordinates.

Nelson B Bolyard

unread,
Dec 29, 2008, 1:59:47 AM12/29/08
to mozilla's crypto code discussion list
David E. Ross wrote, On 2008-12-28 21:40 PST:

> Now that it is known that a subordinate reseller operating under one CA
> issued certificates without authenticating the identity of the
> subscribers, we know that the theoretical concern expressed (before all
> this) about resellers is no longer theoretical. NOW is the time to
> require that all CAs supervise the operations of their RAs and resellers.
> This must be done in a way that independent audits of the CAs examine the
> implementation of such supervision, which can be accomplished by
> requiring (at least with respect to the Mozilla database) that CPs
> explicitly address how that supervision is performed.
>
> Either a CA's CP must explicitly state that there are NO external RAs or
> resellers, or else the CP must describe how external subordinates are
> monitored. Without this, a CA's request to have its root certificate
> included in the Mozilla database should be denied.

+1

Perhaps the policy should even go so far, as Kai has suggested, as to
require that whatever entity performs the verification of subject
identity for the CA must be audited.

Section 6 of the policy requires that "all CAs whose certificates are
distributed with our software products" must "prior to issuing certificates,
verify certificate signing requests in a manner that we deem acceptable",
and "provide attestation of their conformance to the stated verification
requirements and other operational criteria by a competent independent party
or parties with access to details of the CA's internal operations."

I think that last part clearly assumed that the "verification requirements"
were part of "the CA's internal operations", an assumption that we now know
is untrue. So, I would suggest changing it from "access to details of the
CA's internal operations" to "access to the details of the operations that
verify the certificate signing requests, whether internal or external"

> Since an audit will generally report on the implementation of such a
> policy but not necessarily on the policy's adequacy, the internal and
> public reviews of CA requests must examine the adequacy of the CA's
> policy for monitoring external subordinates.

Yes. Agreed. I think the policy should define some parameters (bounds)
for determining the adequacy of CSR verification. It is acceptable to
have hundreds of parties each responsible for verifying CSRs for a
single CA (single issuer)? If not, what limit should apply?

I'd like to see any statements made by Mozilla at the beginning of the
week of public review to explicitly speak to the CSR verification process,
and whether it is internal or external, and how many RAs (or parties
entrusted with verifying CSRs) exist for the particular CA (organization),
and the number of CSR verification parties per subordinate CA.

Grey Hodge

unread,
Dec 29, 2008, 2:41:38 AM12/29/08
to
On 12/28/2008 9:42 AM Eddy Nigg cranked up the brainbox and said:
> On 12/28/2008 04:24 PM, Ian G:
>> No, I'm afraid there is an agreement to list the root, under a policy.
>> Once listed, Mozilla has to operate according to its side of the bargain.
> Apparently you are reading something I haven't.

Apparently, but that doesn't mean it's invalid. Mozilla can't act arbitrarily
and without cause and expect to retain any shred of respect or
trustworthiness. A policy not adhered to is worthless.

> That's for the specific certstar case. Domain validation isn't performed
> by Comodo on a wide scale apparently and perhaps no validation is
> performed at all.

Yes, perhaps, and perhaps they send out certs to anyone who asks nicely, but
we have little evidence to support these suppositions.

Rather than having a kneejerk reaction of removing Comodo from the root list,
why don't we examine the situation. This reseller was not acting according to
proper procedure. Comodo immediately revoked their reseller status, and
reviewed their certs. Further, they've said they're reviewing their policies
to ensure this doesn't happen again. Given their candor and quick response,
what more do you require that you feel you're not getting that justified
removing them as a root CA?

I really think you're going overboard. Form what I see, I'm not alone in that
assessment. You did a good job in bringing this to light. Having the issues
you uncovered addressed and fixed should be sufficient. Why do we need to take
punitive action that will do nothing but punish tens of thousands of other
Comodo customers and millions of users?

--
Grey Hodge
email [ grey @ burntelectrons.org ]
web [ http://burntelectrons.org ]
tag [ Don't touch that! You might mutate your fingers! ]
motto [ Make everything as simple as possible, but no simpler. - Einstein ]

Kyle Hamilton

unread,
Dec 29, 2008, 3:47:02 AM12/29/08
to mozilla's crypto code discussion list
Uhm...

how did you arrive at the "tens of thousands of other Comodo
customers" figure? I don't believe that Comodo has disclosed the
number of unique domain names served by certificates that it has
issued.

And since the number one reason for having a CA in the root list is
for Mozilla-software user security, how do you arrive at "punish [...]
millions of users"?

TLS is geared very obviously toward security-of-the-user (among other
things, a server that does not provide a certificate cannot ask for
client authentication), and the user is who we're trying to protect
(since the user is the one who interacts with Mozilla apps) -- NOT the
server.

As far as I can tell, there is no easy way for users to self-identify
whether the web sites that they're going to are using Comodo
certificates. As far as I can tell, there is no reporting of what CAs
are used by sites browsed to by any given installation of Mozilla
software.

This leads me to believe that there are three possibilities:

1) You have communication from Robin about the number of certificates
that Comodo has issued that the rest of us are not privy to, OR
2) You have some way of knowing what CAs are in use by the servers
that users of the Mozilla applications use (which concept rather
scares me, since it hasn't been disclosed as part of the software
operations), OR
3) You're pulling numbers out of thin air.

-Kyle H

> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

Ian G

unread,
Dec 29, 2008, 6:17:32 AM12/29/08
to mozilla's crypto code discussion list
On 29/12/08 09:47, Kyle Hamilton wrote:
> Uhm...
>
> how did you arrive at the "tens of thousands of other Comodo
> customers" figure? I don't believe that Comodo has disclosed the
> number of unique domain names served by certificates that it has
> issued.


http://www.securityspace.com/s_survey/sdata/200611/certca.html

Security Space figures are now sold not openly published, that is 2
years old. To save the click, December 2006, Security Space reports
that Comodo had 13,715 certs in live.

1. I'll leave to others to address the various fudge factors.
2. If anyone has any view on a new, current report, they could help
reduce the FUD by letting us know that CA's current numbers.


> And since the number one reason for having a CA in the root list is
> for Mozilla-software user security, how do you arrive at "punish [...]
> millions of users"?


In my earlier post, I took the certs and multiplied by 100. It's a
finger in the air, a hand waving. I have no idea, but it is probably
more than 10. If it was 10, the server would likely go for a SSC. :)


> 2) You have some way of knowing what CAs are in use by the servers
> that users of the Mozilla applications use (which concept rather
> scares me, since it hasn't been disclosed as part of the software
> operations), OR

As above.

> 3) You're pulling numbers out of thin air.

Yes, start with what we know. 13,715 two years back. Then add some
estimates of what we don't know. Call it 20k now. Multiply by 100
users to get 2m.

The number at the end is flaky, but it is better than no number. Refine
as more info comes to hand.

iang

Eddy Nigg

unread,
Dec 29, 2008, 8:45:00 AM12/29/08
to
On 12/29/2008 09:41 AM, Grey Hodge:

>
> Apparently, but that doesn't mean it's invalid. Mozilla can't act arbitrarily
> and without cause and expect to retain any shred of respect or
> trustworthiness.

Nobody suggested that I think. There is however real cause for concern.

>
> Yes, perhaps, and perhaps they send out certs to anyone who asks nicely, but
> we have little evidence to support these suppositions.

Please read the other thread "Facts about Comodo Resellers and RAs" at
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/e2755401a7dec203

Please do not add comments to that thread without relevance, thanks.

>
> Rather than having a kneejerk reaction of removing Comodo from the root list,
> why don't we examine the situation. This reseller was not acting according to
> proper procedure. Comodo immediately revoked their reseller status, and
> reviewed their certs. Further, they've said they're reviewing their policies
> to ensure this doesn't happen again. Given their candor and quick response,
> what more do you require that you feel you're not getting that justified
> removing them as a root CA?
>
> I really think you're going overboard. Form what I see, I'm not alone in that
> assessment. You did a good job in bringing this to light. Having the issues
> you uncovered addressed and fixed should be sufficient. Why do we need to take
> punitive action that will do nothing but punish tens of thousands of other
> Comodo customers and millions of users?
>


--

Eddy Nigg

unread,
Dec 29, 2008, 8:46:49 AM12/29/08
to
On 12/29/2008 07:40 AM, David E. Ross:

> On 12/28/2008 3:45 PM, Kyle Hamilton wrote [in part]:
>> CertStar was found out, only due to the diligence of someone on this
>> list. How many other RAs haven't been found out yet? We can't know,
>> because Comodo won't say. This affects the confidence I have in their
>> system (i.e., it removes ALL confidence that Mozilla extended on my
>> behalf).
>
> Actually, Eddy discovered the problem only through the fortuitous
> receipt of spam from CertStar. If he had not received the spam -- even
> if others had received it -- it is possible the problem would never have
> been discovered. This is why the discovery is so frightening.

I will suggest that Mozilla allocate some funds for random checking of
the performance of CAs.

>
> Now that it is known that a subordinate reseller operating under one CA
> issued certificates without authenticating the identity of the
> subscribers, we know that the theoretical concern expressed (before all
> this) about resellers is no longer theoretical. NOW is the time to
> require that all CAs supervise the operations of their RAs and
> resellers. This must be done in a way that independent audits of the
> CAs examine the implementation of such supervision, which can be
> accomplished by requiring (at least with respect to the Mozilla
> database) that CPs explicitly address how that supervision is performed.
>
> Either a CA's CP must explicitly state that there are NO external RAs or
> resellers, or else the CP must describe how external subordinates are
> monitored. Without this, a CA's request to have its root certificate
> included in the Mozilla database should be denied. Since an audit will
> generally report on the implementation of such a policy but not
> necessarily on the policy's adequacy, the internal and public reviews of
> CA requests must examine the adequacy of the CA's policy for monitoring
> external subordinates.
>

+1

Grey Hodge

unread,
Dec 29, 2008, 3:23:50 PM12/29/08
to
On 12/29/2008 3:47 AM Kyle Hamilton cranked up the brainbox and said:
> And since the number one reason for having a CA in the root list is
> for Mozilla-software user security, how do you arrive at "punish [...]
> millions of users"?

If all of Comodo's certs cease to be trusted, millions of web surfers will see
errors on potentially thousands of sites.

> This leads me to believe that there are three possibilities:
> 1) You have communication from Robin about the number of certificates
> that Comodo has issued that the rest of us are not privy to, OR
> 2) You have some way of knowing what CAs are in use by the servers
> that users of the Mozilla applications use (which concept rather
> scares me, since it hasn't been disclosed as part of the software
> operations), OR

The fact you think these are even reasonably conclusions tells me a lot about
your reasoning skills.

> 3) You're pulling numbers out of thin air.

Indeed, I am, as an educated guess. Comodo is a root CA. You don't get root
status by having a handful of customers. It's hard business to break into, and
Comodo has been around a while. I find it hard to believe a company of their
size and age has any fewer than ten thousand certs out there, and that's a
lowball guess. There are many hundreds of millions of web users, and millions
of websites. Do you really find it hard to believe at least 1% of those secure
sites might be using a Comodo cert?

Grey Hodge

unread,
Dec 29, 2008, 3:26:13 PM12/29/08
to
On 12/29/2008 8:45 AM Eddy Nigg cranked up the brainbox and said:
> Please do not add comments to that thread without relevance, thanks.

Excuse me, I've had enough or your arrogant attitude. I've seen the way you've
been treating people and I can name half a dozen off the top of my head you've
been rude to. Knock it off, you're not in any position to tell anyone where to
post and not to post. Further, I've been following the threads for a while
now, thank you very much. I'll thank you to treat people with more respect or
kindly shove off. You did a good deed unveiling Certstar, don't blow that good
will with obnoxiousness.

Eddy Nigg

unread,
Dec 29, 2008, 4:46:06 PM12/29/08
to
On 12/29/2008 10:23 PM, Grey Hodge:

> Indeed, I am, as an educated guess. Comodo is a root CA. You don't get root
> status by having a handful of customers.

The amount of customers never was a known criteria of CAs business
practices ever.

> It's hard business to break into, and
> Comodo has been around a while. I find it hard to believe a company of their
> size and age has any fewer than ten thousand certs out there, and that's a
> lowball guess. There are many hundreds of millions of web users, and millions
> of websites.

Isn't the responsibility of a CA this size much greater and breach of
trust going to affect many? Is a breach of trust justified and
acceptable because of the size of a CA or shouldn't that CA provide
extra care?

(For your knowledge, Netcraft confirms these days about one million
secured web sites altogether, 10-15 percent belonging to Comodo I think,
which is of course still a lot. But it's not millions of web sites.
Additionally Comodo has many different roots and as I understood from
Kyle, he suggested to look at the affected ones.)

David E. Ross

unread,
Dec 29, 2008, 5:48:47 PM12/29/08
to
On 12/29/2008 12:23 PM, Grey Hodge wrote:
> On 12/29/2008 3:47 AM Kyle Hamilton cranked up the brainbox and said:
>> And since the number one reason for having a CA in the root list is
>> for Mozilla-software user security, how do you arrive at "punish [...]
>> millions of users"?
>
> If all of Comodo's certs cease to be trusted, millions of web surfers will see
> errors on potentially thousands of sites.
>
>> This leads me to believe that there are three possibilities:
>> 1) You have communication from Robin about the number of certificates
>> that Comodo has issued that the rest of us are not privy to, OR
>> 2) You have some way of knowing what CAs are in use by the servers
>> that users of the Mozilla applications use (which concept rather
>> scares me, since it hasn't been disclosed as part of the software
>> operations), OR
>
> The fact you think these are even reasonably conclusions tells me a lot about
> your reasoning skills.
>
>> 3) You're pulling numbers out of thin air.
>
> Indeed, I am, as an educated guess. Comodo is a root CA. You don't get root
> status by having a handful of customers. It's hard business to break into, and
> Comodo has been around a while. I find it hard to believe a company of their
> size and age has any fewer than ten thousand certs out there, and that's a
> lowball guess. There are many hundreds of millions of web users, and millions
> of websites. Do you really find it hard to believe at least 1% of those secure
> sites might be using a Comodo cert?
>

For my own installation of SeaMonkey, I disabled all Comodo roots as
soon as I understood the problem. I disabled all UserTrust roots some
years ago, for reasons I don't remember. I have yet to encounter a
problem with any Web site because of this.

The several financial institutions where I access accounts via the Web
-- the Web sites for which I'm most concerned -- all seem to use either
VeriSign or Equifax for their SSL site certificates. My ISP's Web-mail
interface uses Equifax as does the domain registry where I maintain two
domains. Amazon.com uses VeriSign.

I'm beginning to wonder what important Web sites do use Comodo.

Ben Bucksch

unread,
Dec 29, 2008, 6:01:40 PM12/29/08
to
On 29.12.2008 07:59, Nelson B Bolyard wrote:
> Perhaps the policy should even go so far, as Kai has suggested, as to
> require that whatever entity performs the verification of subject
> identity for the CA must be audited.
>

Yes. Not perhaps.
The verification is one of the two core operations of the CA (the other
is to sign the certs and keep the key secure). The verifications are
what the audit is all about. Of course the verifications, and whoever
does that, have to be audited. That means watching the actual, real
people, who do the verifications. That's what we need - we need
*somebody* (preferably many, even) independent to verify that the CA
actually does what it says it does, actually, in real world, everyday
business.

A paper is useless, if nobody verifies that it's actually followed.

Everything else is just talk, hot air.

Grey Hodge

unread,
Dec 29, 2008, 8:44:15 PM12/29/08
to
On 12/29/2008 4:46 PM Eddy Nigg cranked up the brainbox and said:
> The amount of customers never was a known criteria of CAs business
> practices ever.

I also don't know how many Credit cards Bank of America issues, but I can
guess with reasonable accuracy.

> Isn't the responsibility of a CA this size much greater and breach of
> trust going to affect many? Is a breach of trust justified and
> acceptable because of the size of a CA or shouldn't that CA provide
> extra care?

Considering the KNOWN size of the breach, a maximum of 111 certs, less than
ten percent of which could not be verified in 2 days, only 2 of which were
confirmed to be fraudulent (both your attempts), I don't think this requires a
revocation. If we /can/ resolve this issue without revoking, why shouldn't we?

> (For your knowledge, Netcraft confirms

There's a reason "netcraftconfirmsit" is a tag on Slashdot, and it's not
because Netcraft is a bastion of statistical rigor.

My point still stands. Revoking Comodo certs would be a needlessly messy and
painful endeavour, and should be avoided if the situation can be resolved
elsewise. So far, I have no reason to believe Comodo can't tighten up their
practices without nuking millions of web surfers.

Kyle Hamilton

unread,
Dec 29, 2008, 8:52:50 PM12/29/08
to mozilla's crypto code discussion list
I would LOVE for Comodo to clean up its practices.

Including "decertifying the CA that does not adhere to financial
levels of control that is certified by a CA that does".

-Kyle H

Eddy Nigg

unread,
Dec 29, 2008, 9:10:52 PM12/29/08
to
On 12/30/2008 03:44 AM, Grey Hodge:

>
> Considering the KNOWN size of the breach, a maximum of 111 certs, less than
> ten percent of which could not be verified in 2 days, only 2 of which were
> confirmed to be fraudulent (both your attempts), I don't think this requires a
> revocation. If we /can/ resolve this issue without revoking, why shouldn't we?

Well Grey, this is only what we know for an almost certainty. There is a
big question about what we don't know. There are contradicting practice
statements and one of them suggests that there might be more
(unvalidated certs), the other one suggest that validation isn't
performed by Comodo, even if required as per their policy.

> There's a reason "netcraftconfirmsit" is a tag on Slashdot, and it's not
> because Netcraft is a bastion of statistical rigor.

Still, it gives a better indication.

>
> So far, I have no reason to believe Comodo can't tighten up their
> practices without nuking millions of web surfers.
>

That would be great, this is really, really what we want here. There is
no fun in pulling a root, that's for emergencies. I'm certain, whatever
Comodo is going to do in this respect will influence any decision taken
at Mozilla. Hopefully Robin will tell us soon more...

Ben Bucksch

unread,
Dec 30, 2008, 12:45:11 AM12/30/08
to
On 28.12.2008 14:23, Ian G wrote:
> [1] disclosure, I work as an auditor

So, Ian, what are you trying to tell us? We can't yank roots. We can't
rely on audits. How are we supposed to restore and ensure proper
operation of the system?

Obviously, just trusting CAs blindly and hoping for the best doesn't work.
Not even an interested, security-conscious user can just walk into a CA
and verify their operations, so they *have* to rely on us.

Being able to yank roots, and relying on the auditor to verify and
ensure that the actual, day-to-day operations follow the documented
processes, and reading the process document to verify that it meets the
requirements of our policy and our user's needs, is fundamental to the
whole SSL thingy. Otherwise it's useless snake-oil, which harms users
who rely on it - on *us* (Mozilla).

Ian G

unread,
Dec 30, 2008, 8:23:26 AM12/30/08
to mozilla's crypto code discussion list
On 30/12/08 06:45, Ben Bucksch wrote:
> On 28.12.2008 14:23, Ian G wrote:
>> [1] disclosure, I work as an auditor
>
> So, Ian, what are you trying to tell us? We can't yank roots. We can't
> rely on audits. How are we supposed to restore and ensure proper
> operation of the system?


Right. There are no easy solutions. I don't have them. What I would
avoid however is following the old prescriptions without understanding
them better. That will involve more work for all, papering over the
cracks, and in the end, less security. This is what happened to the
financial system...


> Obviously, just trusting CAs blindly and hoping for the best doesn't work.
> Not even an interested, security-conscious user can just walk into a CA
> and verify their operations, so they *have* to rely on us.


In this I would differ somewhat :) In my time as an auditor, I have
seen very little that needs to be secret, confidential or closed [1].
In particular, all of the verification processes are more or less
available for open scrutiny already. As you yourself have shown, it was
possible for you to read the CPS and the audit opinion, and work out
that the reseller situation was as we found in the experiences. It's
also possible for anyone to buy a cert and find out what it feels like,
and today's discussion wasn't the first time this was done.

The difference is between the belief that "only" an auditor can verify
these things, and what you can really do.

Consider that Mozo musters some 150 million end-users. Probably a
million of those are interested parties. Probably 100k of those are
technically savvy and interested in security. Of those, I suggest we
can find 1000 who can read and comment on the CPS *and* review the
verification processes of every CA under consideration.

(I have seen this concept in other places. It works if you get enough
people, enough openness in thinking, and enough value on the table. It
works in open source for example.)

So, where we would be heading is this:

* reducing the scope of the audit to only those areas that cannot be
opened up.
* increasing the verification by the people over those areas that
are open, either already, or easy to open.

E.g., think about the current event. We now know far more about that
verification than the audit ever told us. It's simple: just buy a few
certs and report back.

The cost of the certs is $10 -> $100, and the cost of the audit is
$100k---> ... It's even cheaper this way.


> Being able to yank roots, and relying on the auditor to verify and
> ensure that the actual, day-to-day operations follow the documented
> processes, and reading the process document to verify that it meets the
> requirements of our policy and our user's needs, is fundamental to the
> whole SSL thingy. Otherwise it's useless snake-oil, which harms users
> who rely on it - on *us* (Mozilla).


Well, that is the old message from 1995. The message was constructed
before we saw how it worked in practice. Things have changed a lot
since then, especially we now know much more about open processes, and
we know how the net really works.

Instead, consider the reputational damage to the CA as the primary
vector of harm. If a CA is criticised, this hurts their business [2].

If we had independent security researchers posting on their experiences,
then this would enable a "CHOICE" style of approach to evaluating
security [3].

(Yes, there are some who believe that all CAs must be equivalent, and
all end-users are to be protected from any differences. I am pointing
out that this very core principle is a root cause of all our troubles.
It is unsustainable, and must break one day if security against a real
attacker is to be the intent. There is no real security system that
survives without end-to-end security, and the user is always the end.)

Of course, these are just my opinions, and many do not agree to them!

iang

[1] Comodo provided some confirmation of this when they stated that
much of what we were talking about they *could* open up but would only
do it if all CAs were required to. E.g., it is closed for commercial
reasons, not security or verification reasons.

[2] This particular time it failed to reach the press in any big way
(for reasons you can speculate on).

[3] By CHOICE I mean the consumer magazine in some countries where the
suppliers are kept at distance. This would be the exact opposite group
to CABForum for example, where users are kept at distance.

Kai Engert

unread,
Dec 30, 2008, 8:24:41 AM12/30/08
to mozilla's crypto code discussion list
Ian G wrote:
> Which language suggests they have to do verification *themselves* ?

The fact that the policy talks about a CA, and I didn't see talk about
external entities.

> BTW, it would be quite problematic to insist that the CAs do this job
> themselves.
>
> CAs are not generally experts on the issues raised. Traditionally, CAs
> outsource the processess within verification to a range of different
> organisations: government registries, commercial credit agencies,
> credit card companies, passport offices, birth registries, etc. That
> is, to insist they "do it themselves" would mean that they would have
> to develop skills that might be better handled elsewhere, and might in
> the end reduce to moving the deckchairs around.

Yes, it seems reasonable that a CA relies on external sources of
information like the ones you mention.

If the CA has obtained information from registry offices like the above,
the CA should be able to conclude "verified" on their own. It's a first
hand decision.

In my understanding, what we have experienced here was a second hand
decision. Some external entity claimed to have done verification. The CA
relied on that and treated it as sufficient. That's the bug.

In my opinion, if a CA wants to delegate the decision about correctness
of verification to an external party, they must verify the business
practices of that external party, requiring the same sense of duty. And
my proposal is, as part of this test, the external party should go
through the same kind of audit that Mozilla requires for CAs.

As I see verification as the core intention of the CA principle, I would
have assumed above requirement is obvious to everyone, at least to CAs
themselves.

> However, to turn it into a criteria or policy point, you would need to
> much more clearly refine your point, *and* you should clearly relate
> it to how this will improve security. I suggest this is much tougher
> than it sounds.

I'm not talking about improving security. I want to ensure we forbid
lowering of verification quality through the backdoor.

My point is, we must find a way to ensure the purpose of the CA audit
can not become void. We should forbid the practice to delegate the core
of verification to external entities with unknown sense of duty.

Kai

Eddy Nigg

unread,
Dec 30, 2008, 8:38:59 AM12/30/08
to
On 12/30/2008 03:24 PM, Kai Engert:

> As I see verification as the core intention of the CA principle, I would
> have assumed above requirement is obvious to everyone, at least to CAs
> themselves.
>

One of Comodo's CPS (the one responsible for PositiveSSL) claims:

To validate PositiveSSL and PositiveSSL Wildcard Secure Server
Certificates, *Comodo* checks that the Subscriber has control.....
....and the use of generic e-mails which ordinarily are only
available to person(s) controlling the domain name administration, for
example, webmaster@ . . ., postmaster@ . . ., admin@;

However the general CPS says something else. See other thread "Facts
about Comodo Resellers and RAs".

Nevertheless I believe that most CAs indeed take domain validation
seriously. CAs must provide confirmation concerning that during
inclusion requests. Comodo has not disclosed what I found now. As such
there is no backdoor.

Ben Bucksch

unread,
Dec 30, 2008, 11:46:58 AM12/30/08
to
I have an idea for a nice "make money fast" business model:

I'll make a CA. I'll talk about trust-worthiness and doing sophisticated
verifications etc.. In my guidelines and processes, I say that I'll
offer "HighSec high security certificates", where I'll get the in-person
signature and passport verification. I'll also define "CheapO" certs,
and say that I'm not actually going to do any verifications whatsoever
for them. (Maybe I won't define CheapO just yet, but in a year.)

I'll get the root cert in the Mozilla roots.

I'll get an audit by KPMG which will verify me just fine that I do
nothing, i.e. follow the guidelines. If the audit is thorough, the
auditor will also let me issue a HighSec cert for himself, and I'll
check his own signature and passport, and he'll see that I verify that -
all fine. The audit costs me, let say, $3000 (one day of work by a KPMG
guy - maximum).

I'll issue both HighSec ($1000) and CheapO certs based on my root cert.
I'll make a simple website with lots of seal graphics and impressive
"high security certification" text, where I sign any key that people
give me, without any verifications whatsoever. I sell them for $5.
That's more than 50% cheaper than popular competitors, and 95% cheaper
than the market leader.

I'll get really popular with web site owners, because I'm real cheap and
fast and unobtrusive. Every webhoster under the sun is my reseller (they
make $1, too), which is part of my success. I cash $$/year. All is fine.

Part of the reason why all is fine is that people are generally careful
before nonsense when their credit card / bank account is involved.

Now, 3 years later, some scammers and spammers actually notice me and
set up fake SSL sites with my certs. (They need the site for a few days
only anyways.) (Before that, they simply haven't bothered about SSL -
why should they?) People notice. I quickly revoke the offending certs,
and say "Oops, sorry. Fixed it. Won't happen again.". Otherwise, I
continue everything as-is. I refer people to my audit above. Still,
people yell for my root to be yanked. I put the "big business, can't do
that" face on.

Some other people, however, say that I don't violate my own guideline,
and that they have no right to put me out of business, and that even if
so, they should not yank my root anyways, because so many websites are
using it.

I smile.

Ben

Florian Weimer

unread,
Dec 30, 2008, 3:47:37 PM12/30/08
to mozilla's crypto code discussion list
* Ben Bucksch:

> Now, 3 years later, some scammers and spammers actually notice me and
> set up fake SSL sites with my certs.

Not just fake sites. Some of the OEM software spammers use valid SSL
certificates for the checkout procedure, e.g.:

<https://secure.securesoftmarket.com/>

For those trying to figure who has issued the certificate: Equifax
(the data broker) sold the root to Geotrust, which was then bought by
Verisign.

> I smile.

I fear that most of the historic root certs and many of the newer ones
have problems comparable to Comodo and Verisign. This is a good
situation for the CAs because it limits what browsers and end users
can do. It's difficult to select business partners who do not suffer
from those backyard (or frontyard) problems, so why bother at all?

Usually, if the industry is not totally rotten, some players clean up
the field, often using the court system (we see attempts at that in
the antivirus market, for instance). I doubt that this will happen
with certificates because it's hard to see why issuing a certificate
creates liability, while delegating a domain does not. And this is a
matter many players will only touch with a ten-foot pole.

Kyle Hamilton

unread,
Dec 30, 2008, 5:51:14 PM12/30/08
to mozilla's crypto code discussion list
On Tue, Dec 30, 2008 at 12:47 PM, Florian Weimer <f...@deneb.enyo.de> wrote:
> Usually, if the industry is not totally rotten, some players clean up
> the field, often using the court system (we see attempts at that in
> the antivirus market, for instance). I doubt that this will happen
> with certificates because it's hard to see why issuing a certificate
> creates liability, while delegating a domain does not. And this is a
> matter many players will only touch with a ten-foot pole.

This is unfortunately a place where /only/ the browser vendors (as
'source of trusted certificates') can take action. And now, Ian and
other people are saying that roots shouldn't ever be revoked because
of "business concerns", and I and others are saying that roots need to
be revoked, also because of "business concerns".

I am sorry for using this language, but fuck that noise. Mozilla has
an obligation to me as an end-user to uphold its CA program mission
and stated requirements for participation, since it provided me the
certificates that I am (by user interface) almost unable to quickly,
easily, and thoroughly remove the trust from -- and also by making it
impossible for me to completely remove the certificates that I remove
trust from while keeping the ones that I don't want to remove the
trust from in my local softoken.

NSS's public non-programmer interface tools need a major redesign (if
nothing else, certutil and modutil need to be modified to include
'print NSS and tool version' options and make their command-line
parameters similar). Firefox's UIs for certificate-related things
need to be completely thrown out and rebuilt from scratch. This
situation is completely unworkable as it stands.

-Kyle H

Ben Bucksch

unread,
Dec 30, 2008, 8:05:18 PM12/30/08
to
Florian, I think you refer to cert issued to spammers holding a domain,
and getting a DV cert for that domain that they registered? The cert is
issued correctly for the domain, just the organization does not do clean
business. This is a totally different issue.

I am talking about a phisher being able to get a cert for
www.bankofamerica.com or (worse) addons.mozilla.org.

Ben

On 30.12.2008 21:47, Florian Weimer wrote:
>
>> Now, 3 years later, some scammers and spammers actually notice me and
>> set up fake SSL sites with my certs.
>>
>
> Not just fake sites. Some of the OEM software spammers use valid SSL
> certificates for the checkout procedure, e.g.:
>
> <https://secure.securesoftmarket.com/>
>

Florian Weimer

unread,
Jan 2, 2009, 5:40:57 PM1/2/09
to mozilla's crypto code discussion list
* Ben Bucksch:

> Florian, I think you refer to cert issued to spammers holding a
> domain, and getting a DV cert for that domain that they registered?
> The cert is issued correctly for the domain, just the organization
> does not do clean business. This is a totally different issue.

Oops, sorry, then I misunderstood you.

However, if it's okay to do bad things with a certificate (from the
browser PKI point of view) if you also own the corresponding domain
name, we still have a problem thanks to the way the padlock icon has
been advertised.

> I am talking about a phisher being able to get a cert for
> www.bankofamerica.com or (worse) addons.mozilla.org.

Mozilla should probably hard-code the certificate for
addons.mozilla.org.

Michael Ströder

unread,
Jan 16, 2009, 8:54:44 AM1/16/09
to
Kyle Hamilton wrote:
> On Tue, Dec 30, 2008 at 12:47 PM, Florian Weimer <f...@deneb.enyo.de> wrote:
>> Usually, if the industry is not totally rotten, some players clean up
>> the field, often using the court system (we see attempts at that in
>> the antivirus market, for instance). I doubt that this will happen
>> with certificates because it's hard to see why issuing a certificate
>> creates liability, while delegating a domain does not. And this is a
>> matter many players will only touch with a ten-foot pole.
>
> This is unfortunately a place where /only/ the browser vendors (as
> 'source of trusted certificates') can take action. And now, Ian and
> other people are saying that roots shouldn't ever be revoked because
> of "business concerns", and I and others are saying that roots need to
> be revoked, also because of "business concerns".

I agree with the latter.

> I am sorry for using this language, but fuck that noise. Mozilla has
> an obligation to me as an end-user to uphold its CA program mission
> and stated requirements for participation, since it provided me the
> certificates that I am (by user interface) almost unable to quickly,
> easily, and thoroughly remove the trust from -- and also by making it
> impossible for me to completely remove the certificates that I remove
> trust from while keeping the ones that I don't want to remove the
> trust from in my local softoken.

I even think that someone could take Mozilla to court for not enforcing
its own policy. Marking something as trusted implies some obligations
too - even if you don't charge money.

> NSS's public non-programmer interface tools need a major redesign (if
> nothing else, certutil and modutil need to be modified to include
> 'print NSS and tool version' options and make their command-line
> parameters similar). Firefox's UIs for certificate-related things
> need to be completely thrown out and rebuilt from scratch. This
> situation is completely unworkable as it stands.

Totally agree here either.

Ciao, Michael.

Reply all
Reply to author
Forward
0 new messages