Etisalat (which is cross/sub signigned by Verizon) issued a mislabeled
firmware update to approximately 100,000 of its BlackBerry subscribers
that contained malicious surveillance software 
Research In Motion subsequently issued patches to remove this malicious
Signer: Eddy Nigg, StartCom Ltd.
If this information is correct (and I have no reason to believe otherwise), it
raises two issues:
Firstly, there is a subordinate CA within the NSS database which has expressed
either (a) malicious intent or (b) gross negligence and incompetence on its
part*. Verizon should be compelled to revoke this sub CA promptly, else a
security update be released which removes the trust bits on their root from
the NSS database
Secondly, it illustrates problems with subordinate CAs - or, more pressingly,
the lack of disclosure of such, and such an event demonstrates that the
Mozilla Foundation need be informed about any and all such CAs. It should not
have taken anywhere near this long for us to become aware of this issue
It would seem that this requires both prompt action by either Verizon or
Mozilla, and, in the long term, policy changes to require better Sub-CA
(* Does anyone have any technical information on how exactly the "update" was
deployed? I would not expect a phone to accept updates signed by just
On 8/15/10 11:50 PM, David E. Ross wrote:
> I don't know about the mailing list taht feeds into this newsgroup, but
> this particual newsgroup is moderated. Sometimes, the moderators take a
> weekend break.
I'm not sure if I'm a victim of a moderation hiccup, but I tried to post
via the Google Groups interface yesterday and have yet to see my message
come through. In any case, my message said something like:
It would be nice if Moz did something like what Owen suggested, but they
haven't shown much willingness to go that far in the past. The SubCA
problems are already well known (you observed "It should not have taken
anywhere near this long for us to become aware of this issue"). These
problems include at least three sub-issues:
1. There is no required disclosure of SubCAs if the grantees promise to
use the only for "private"/"enterprise" purposes (but there is no
technical way of enforcing this)
2. The only time any type of SubCA must be disclosed is at the time of
root approval, and this policy only went into effect recently. This
means that there are probably hundreds of existing undocumented SubCAs,
and that approved roots may subsequently issue new SubCAs without
3. There are no significant means for restricting the domains for which
SubCAs may issue certs (eg: Domain Constraints)
A few relevant threads, if you haven't already seen them:
Does the CA approval process consider intermediate certs?
Terminology and policy in relation to subordinate CAs
CNNIC cert signed by Entrust
It should be noted that the item
of the Problematic Practices exists for quite some time. And we've
discussion even more time before. Also affecting to some extend is
Well, sometimes English nothing work well. :-)
I have seen 0 widespread or concerted effort from Mozilla to get these
problems corrected (although Qualys and the EFF seems to be doing a
pretty good job). Are we ever going to see Mozilla/Firefox actually do
anything (like reprimand CAs publicly, remove bad CAs, ship revocation
certificates for known bad sub CAs, or?). There isn't even a way to
easily or automatically disable certificates (you must go through one
at a time and disable the trust bits, there is no way to create a file
and do an import, or easily script it, or whatever as far as I can
tell), thus making it almost impossible for users to protect
themselves even if they are sophisticated enough to want to do this.
Also while doing a mass edit of the certs in my browser I noticed
several certs have no common name, which means the check box dialog
The certificate "" represents a Certificate Authority
It would help if the interface maybe displayed a warning or the
Organization name or something instead of just a blank.
This is good, but this is just one of many possible failure modes of the system.
> Additionally three CAs were removed and omitted from the latest batch of
> root updates for NSS.
Which were those? Were they due to some unacceptable CA behavior or, instead, were they simply unclaimed certs left over from the dark ages of the approval system?
Yes, it has certainly been discussed quite a bit in the past. However,
even the language there such as "You must provide a clear description of
the subordinate CAs that are operated by external third parties" has not
been thoroughly enforced. Instead, that section refers to the SubCA
checklist which makes the "private"/"enterprise" exception I mentioned
in #1. Furthermore, the "Potentially Problematic Practices" are seen as
general guidelines and, as such, don't carry as much weight as formal
I'm not sure if your point was to demonstrate that it has been discussed
in the past (it has), or that any of my enumerated issues had been
solved (they have not).
> Also affecting to some extend is
Right, although this is one of many possible issues. And also as far as
I'm aware, although that section says "Delegation of domain/email
validation to third parties should generally be avoided," this practice
is still widespread.
Correct, and the original proposal was entirely different. First of all
there was never a differentiation between "enterprise/private" sub CAs
and others. This is an invention of some additions which also watered
down the original problematic practice.
The only differentiation I know about is those intermediate CAs that are
operated and control by the CA itself and those of external entities of
the CA. From my point of view, any intermediate CA that is not operated
at the CA is external.
> I'm not sure if your point was to demonstrate that it has been discussed
> in the past (it has), or that any of my enumerated issues had been
> solved (they have not).
Nope. The Problematic Practices came into being mostly because of the
issues I raised at that time - it's not what I wanted, but this is what
we got. The interpretation is that you must have some very good reasons
for having a problematic practice. I would be very much in favor to
start enforcing most items as a policy.
> Right, although this is one of many possible issues. And also as far as
> I'm aware, although that section says "Delegation of domain/email
> validation to third parties should generally be avoided," this practice
> is still widespread.
But the CA that was the reason for this entry has according to their own
account enforced exactly this by now. And this is a very important step
into the right direction. More needs to be done and you and anybody else
is invited to pick on the CAs to have it implemented :-)
So your point is that when there are objections during the approval
process, sometimes the approvals get delayed? I would certainly hope
so, otherwise I don't know why we bother. Incidentally, GlobalSign was
subsequently approved. Camerafirma was approved. Inzepe was approved
(evidently over your objections):
The requests have been approved but not included in NSS recent update
due to pending issues. I can't find now all the bug entries, here is one
Here some more:
Yes, see https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
> Letting people pester the CAs is helpful, but is not a substitute for
> a real security policy.
Use your skills to convince those with the powers to do so. I wasn't
able to do that.
Ah, and your pointer helped me find the comment I was thinking of when I
said "this practice is still widespread." In the discussion of the
Comodo RA fiasco they explained that they continue to maintain
externally operated RAs, and Kathleen said that she didn't think they
should even have to disclose how many there were (or require full
WebTrust audits of them):
In any case, how about Verizon and Etisalat? Is something going to be
done about that?
I believe first we have to establish if one or more certificates were
issued against the CA policy of Verizon and the Mozilla CA policy. Some
more information would be helpful.
Is there a specific proposal that Mozilla request information from them?
Or is there some other channel for investigation that you envision?
Your input in these discussions is appreciated. There are a few items
that I would like to respond to.
>> 1. There is no required disclosure of SubCAs if the grantees
>> promise to use the only for "private"/"enterprise" purposes
>> (but there is no technical way of enforcing this)
We are planning to kickoff a project to update the Mozilla CA
Certificate Policy. I will post more about this in a separate discussion
As per https://wiki.mozilla.org/CA:SubordinateCA_checklist we plan to
include requirements for CAs to constrain third-party private sub-CAs so
they can only issue certs within a specified domain.
>> 2. The only time any type of SubCA must be disclosed is
>> at the time of root approval, and this policy only went
>> into effect recently. This means that there are probably
>> hundreds of existing undocumented SubCAs, and that approved
>> roots may subsequently issue new SubCAs without disclosure.
Good point. As part of updating the Mozilla CA Certificate Policy, we
intend to add policy about renewing audits. It is duly noted that this
also needs to include sub-CAs.
>> 3. There are no significant means for restricting the
>> domains for which SubCAs may issue certs (eg: Domain Constraints)
In https://bugzilla.mozilla.org/show_bug.cgi?id=394919 libPKIX was
updated to apply DNS name constraints to cert Common Names. However, my
understanding is that Firefox doesn’t use libPKIX for SSL cert
verification. So essentially your statement is correct, and warrants
In https://bugzilla.mozilla.org/show_bug.cgi?id=532158 it is requested
that the PSM (and thus Firefox) be updated to use CERT_PKIXVerifyCert
for all cert verification tasks so that name constraints would be
enforced. Perhaps this bug needs to have a higher priority.
>> In any case, how about Verizon and Etisalat?
>> Is something going to be done about that?
In regards to Verizon/Etisalat, we are not aware of a certificate whose
issuance was in violation of the Mozilla CA Certificate Policy. We
disapprove behavior of using a legitimate code-signing cert to sign
malware. However, the behavior of Etisalat is subject to the contract
between Verizon and Etisalat, and should be dealt with by Verizon.
For two reasons, I would strongly urge that the policy be revised to
prohibit the inclusion of any root certificate used to sign third-party
private intermediate certificates.
(1) There should be no need for the general public to chain up through a
private intermediate certificate. Thus, the root that signs such a
certificate should not be in a general, public store.
(2) If the signing root certificate is indeed in a general, public
store, there is nothing within NSS to prevent the owner of a private
intermediate certificate from going into business as an independent
certificate authority. Only after such a situation occurs and exists
for some time might it be detected; in the meantime, much damage could
David E. Ross
I filter and ignore all newsgroup messages posted through
GoogleGroups via Google's G2/1.0 user agent because of the
amount of spam from that source.
Many of the alternatives have problems:
- a private corporate root cannot be installed on some devices. Not
a problem for desktop Firefox users, but if an organization has many
mobile device users, for example, they may not be able to go this route.
- a wild-card cert introduces its own set of security problems
(compromise any of the corporate servers and you've compromised them
- self-signed certs served over DNSSEC doesn't exist for any current
- buying a cert per internal server might be prohibitively expensive
(though I'd prefer they went this route).
> (2) If the signing root certificate is indeed in a general, public
> store, there is nothing within NSS to prevent the owner of a private
> intermediate certificate from going into business as an independent
> certificate authority.
There could be -- we could insist CAs issue such subsidiary signing
certs with name constraints. NSS supports these (although I believe
Firefox currently doesn't, requires bug 479393).
In other words, there is no such a thing like "private" intermediate CA,
they are all public what us concerns. Why the differentiation anyway, do
we have a private and public root store? This never made much sense.
That is the point. There should NOT be a private root store in Mozilla
products distributed to the general public. Roots for private intranets
hsould be excluded from NSS. In a private intranet, a system
administrator should be handling the deployment of applications,
updates, and patches. That person should install the root certificate
for the intranet when deploying browsers, E-mail clients, etc, before
Let me highlight this argument. It is, in essence, that in order to
solve a technology problem at a completely different layer of the stack,
we should compromise on security in the core of the CA system. I am not
arguing that the problem described above is not legitimate, but the
trad-eoff should be made explicit. We should also consider what might
happen if we do not compromise... for instance, incompatible device
makers might be motivated to support custom root stores rather than
perpetuating the problem. Indeed, the inability to configure a custom
root store on a mobile device creates a problem that goes far beyond
simply perpetuating sub-optimal SubCA practices... is such a situation
really compatible with our myth that the users have control? In this
regard, decisions that Firefox makes have the potential to influence
even users on other platforms.
Incidentally, I say this as someone who has faced this very limitation
on Android OS, reporting it as an issue nearly two years ago:
OK, which roots do I disable if I want to make sure I am not affected
There are two parts to this question...
The first question being: Is there a root that you might want to disable
as a result of reading this open letter? In regards to this letter, we
are not aware of a code signing certificate that was issued in a manner
that does not meet the requirements of the Mozilla CA Certificate Policy.
The second question being: If you want to disable a root as a result of
this open letter, which root would it be? The first paragraph of the
letter seems to indicate a particular CA's root. However,at closer
inspection (including reading footnote #5) you'll see that the root
mentioned in the open letter was not involved in the "mislabeled