Verizon and Etisalat

269 views
Skip to first unread message

Eddy Nigg

unread,
Aug 13, 2010, 6:12:34 PM8/13/10
to mozilla-dev-s...@lists.mozilla.org
I was previously aware that in the UAE some backdoors were installed
on Blackberry devices, however I wasn't aware that those were signed by
a CA which Mozilla ultimatly trusts. I believe that the allegations in
this letter (and provided links) require some investigation:
https://www.eff.org/deeplinks/2010/08/open-letter-verizon

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 [1]
<http://www.itp.net/561962-etisalats-blackberry-patch-designed-for-surveillance>.
Research In Motion subsequently issued patches to remove this malicious
code [2]
<http://gulfnews.com/business/telecoms/etisalat-s-blackberry-update-intercepts-communication-says-rim-1.502062>.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

Owen Shepherd

unread,
Aug 15, 2010, 9:21:26 PM8/15/10
to dev-secur...@lists.mozilla.org
On Friday 13 Aug 2010 23:12:34 Eddy Nigg wrote:
> I was previously aware that in the UAE some backdoors were installed
> on Blackberry devices, however I wasn't aware that those were signed by
> a CA which Mozilla ultimatly trusts. I believe that the allegations in
> this letter (and provided links) require some investigation:
> https://www.eff.org/deeplinks/2010/08/open-letter-verizon
>
> 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 [1]
> <http://www.itp.net/561962-etisalats-blackberry-patch-designed-for-surveill
> ance>. Research In Motion subsequently issued patches to remove this
> malicious code [2]
> <http://gulfnews.com/business/telecoms/etisalat-s-blackberry-update-interce
> pts-communication-says-rim-1.502062>.

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
disclosure
- Owen
(* 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
anyone...)

signature.asc

Owen Shepherd

unread,
Aug 15, 2010, 9:37:12 PM8/15/10
to dev-secur...@lists.mozilla.org
(This mail was sent Friday and nothing to the list since? Am I experiencing
weird quantum mail lossage effects, or is everyone just being deathly silent?)

(And yes, I really ought to check the sent dates on mails. My fault)
signature.asc

Stephen Schultze

unread,
Aug 16, 2010, 3:41:58 PM8/16/10
to mozilla-dev-s...@lists.mozilla.org
On 8/15/10 9:21 PM, Owen Shepherd wrote:
> 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
> disclosure


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
disclosure.
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?
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/eea04805fbd98045

Terminology and policy in relation to subordinate CAs
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc

CNNIC cert signed by Entrust
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/7ba51ca49de0f6cf

Eddy Nigg

unread,
Aug 16, 2010, 4:10:09 PM8/16/10
to mozilla-dev-s...@lists.mozilla.org
On 08/16/2010 10:41 PM, From Stephen Schultze:

> 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 disclosure.
> 3. There are no significant means for restricting the domains for
> which SubCAs may issue certs (eg: Domain Constraints)

It should be noted that the item
https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
of the Problematic Practices exists for quite some time. And we've
discussion even more time before. Also affecting to some extend is
https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties

Eddy Nigg

unread,
Aug 16, 2010, 4:13:40 PM8/16/10
to mozilla-dev-s...@lists.mozilla.org
On 08/16/2010 11:10 PM, From Eddy Nigg:

> And we've discussion even more time before.

Well, sometimes English nothing work well. :-)

Kurt Seifried

unread,
Aug 17, 2010, 11:27:38 PM8/17/10
to Eddy Nigg, mozilla-dev-s...@lists.mozilla.org
I have to say I'm a little concerned, I have now seen a good half
dozen or so situations where CAs completely failed in some manner
(technologically, procedurally, etc.). And nothing has happened. In
some cases some of the problems have been fixed with the specific CA
that got caught (i.e. me buying certs for webmail sites via the
ssladministrator@ through Verisign, I suspect there are still some CAs
that allow non standard addresses) or the CAs signing certs not only
for IP addresses but for 192.168.1.2 and the like (which is completely
inexcusable).

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
shows:

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.

--
Kurt Seifried
ku...@seifried.org
tel: 1-703-879-3176

Steve Schultze

unread,
Aug 18, 2010, 9:14:21 AM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 8/18/10 8:07 AM, Eddy Nigg wrote:
> Yes and finally a sane defined list exists for domain control validation
> via email as a requirement.

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?

Steve Schultze

unread,
Aug 18, 2010, 9:28:25 AM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 8/16/10 4:10 PM, Eddy Nigg wrote:
> On 08/16/2010 10:41 PM, From Stephen Schultze:
>> 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
>> disclosure. 3. There are no significant means for restricting the
>> domains for which SubCAs may issue certs (eg: Domain Constraints)
>
> It should be noted that the item
> https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
> of the Problematic Practices exists for quite some time. And we've
> discussion even more time before.

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
policy.

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).

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.

Eddy Nigg

unread,
Aug 18, 2010, 12:26:15 PM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 08/18/2010 04:28 PM, From Steve Schultze:

> 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
> policy.

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 :-)

Stephen Schultze

unread,
Aug 18, 2010, 1:30:19 PM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 8/18/10 12:06 PM, Eddy Nigg wrote:
> On 08/18/2010 04:14 PM, From Steve Schultze:

>> 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?
>
> Nonono....they were not removed from NSS, but from the most recent batch
> of to-be-added new and updated roots and EV OIDs. Those where
> Camerafirm, Izempe and GlobalSign if I recall correctly. Each for a
> different reason.

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):

https://bugzilla.mozilla.org/show_bug.cgi?id=361957#c124

http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/60570fc88bed97f/9852ff938cd3c726#a00875047c170839


Eddy Nigg

unread,
Aug 18, 2010, 1:45:26 PM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 08/18/2010 08:30 PM, From Stephen Schultze:

>
> 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
https://bugzilla.mozilla.org/show_bug.cgi?id=582579#c6

Eddy Nigg

unread,
Aug 18, 2010, 1:48:20 PM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 08/18/2010 08:45 PM, From Eddy Nigg:

> On 08/18/2010 08:30 PM, From Stephen Schultze:
>>
>> 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 https://bugzilla.mozilla.org/show_bug.cgi?id=582579#c6
>

Here some more:

https://bugzilla.mozilla.org/show_bug.cgi?id=578491#c7
https://bugzilla.mozilla.org/show_bug.cgi?id=582579#c4

Eddy Nigg

unread,
Aug 18, 2010, 1:52:08 PM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 08/18/2010 08:21 PM, From Stephen Schultze:
> Was that Comodo?

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.

Stephen Schultze

unread,
Aug 18, 2010, 3:07:39 PM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 8/18/10 1:21 PM, Stephen Schultze wrote:

> On 8/18/10 12:26 PM, Eddy Nigg wrote:
>>> 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 :-)
>
> Was that Comodo? I went back and re-read the threads about their RA
> issue (it was before my time here) and it wasn't actually clear that it
> had been totally resolved, but I could be missing something. In any
> event, the larger point is that it is an allowed practice that has only
> partial and ad hoc oversight. Letting people pester the CAs is helpful,

> but is not a substitute for a real security policy.

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):

https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c73

In any case, how about Verizon and Etisalat? Is something going to be
done about that?

Eddy Nigg

unread,
Aug 18, 2010, 5:11:01 PM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 08/18/2010 10:07 PM, From Stephen Schultze:

>
> 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.

Stephen Schultze

unread,
Aug 18, 2010, 5:47:00 PM8/18/10
to mozilla-dev-s...@lists.mozilla.org
On 8/18/10 5:11 PM, Eddy Nigg wrote:
> On 08/18/2010 10:07 PM, From Stephen Schultze:
>>
>> 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?

Kathleen Wilson

unread,
Aug 20, 2010, 8:28:49 PM8/20/10
to mozilla-dev-s...@lists.mozilla.org


All,

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
soon.
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
further attention.

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.

Thanks,
Kathleen

David E. Ross

unread,
Aug 20, 2010, 10:41:37 PM8/20/10
to mozilla-dev-s...@lists.mozilla.org
On 8/20/10 5:28 PM, Kathleen Wilson wrote [in part]:

> We are planning to kickoff a project to update the Mozilla CA
> Certificate Policy. I will post more about this in a separate discussion
> soon.
> 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.
>

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
occur.

--

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

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.

Daniel Veditz

unread,
Aug 21, 2010, 12:08:52 AM8/21/10
to mozilla-dev-s...@lists.mozilla.org
On 8/20/10 7:41 PM, David E. Ross wrote:
> (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.

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
all).

- self-signed certs served over DNSSEC doesn't exist for any current
software/device

- 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).

-Dan Veditz

Eddy Nigg

unread,
Aug 21, 2010, 3:37:53 AM8/21/10
to mozilla-dev-s...@lists.mozilla.org
On 08/21/2010 05:41 AM, From David E. Ross:

> (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

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.

David E. Ross

unread,
Aug 21, 2010, 11:35:52 AM8/21/10
to mozilla-dev-s...@lists.mozilla.org
On 8/21/10 12:37 AM, Eddy Nigg wrote:
> On 08/21/2010 05:41 AM, From David E. Ross:
>> (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
>
> 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
deployment.

Steve Schultze

unread,
Aug 22, 2010, 10:32:02 PM8/22/10
to mozilla-dev-s...@lists.mozilla.org
On 8/21/10 12:08 AM, Daniel Veditz wrote:
> On 8/20/10 7:41 PM, David E. Ross wrote:
>> (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.
>
> 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.

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:
http://code.google.com/p/android/issues/detail?id=1016

Matt McCutchen

unread,
Aug 29, 2010, 5:20:24 PM8/29/10
to mozilla-dev-s...@lists.mozilla.org
On Aug 13, 6:12 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
> https://www.eff.org/deeplinks/2010/08/open-letter-verizon [...]

OK, which roots do I disable if I want to make sure I am not affected
by this?

Matt

Kathleen Wilson

unread,
Aug 30, 2010, 2:24:11 PM8/30/10
to mozilla-dev-s...@lists.mozilla.org

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
firmware update".

Kathleen


Reply all
Reply to author
Forward
0 new messages