Trustworthyness requirement for CAs and SubCAs

[Jan Schejbal]

Hi,
there have been repeated issues where CAs were claimed to be
untrustworthy due to prior misconduct not related to certificates.
Usually, this was dismissed by saying that no certificate was issued
contrary to Mozilla Policy, and thus there is no reason not to include a CA.

Examples of this were for example the discussions around CNNIC, which
was claimed to have been involved in malware distribution, internet
censorship and other attacks on users. Most of these claims were not
backed by solid evidence. A different case is Etisalat, which has
infected Blackberry devices with malware. The fact that the software was
deployed by Etisalat is uncontested, and the fact that it is malware has
been confirmed, among others, by Blackberry/RIM. Etisalat is not a Root
under the Mozilla CA program, but has a Sub-CA issued by GTE/Verizon.

The problem I see in this "no action until misconduct shown" approach
that it is retroactive: Only if a (Sub-)CA violates the policy *and* is
stupid enough to get caught, it *might* lose its certificate. Other than
that, no matter how likely it is that they will misuse their certificate
due to previous unethical behavior, everything is fine. This exposes
users to targetted attacks. The Etisalat attack was caught because they
attacked 100,000 devices in a really stupid and obvious way and some
owners got suspicious. I fully assume that even if the Etisalat CA does
violate the policy and is stupid enough to get caught, Verizon will
revoke the CA and everything will be fine again, because until then,
everyone was following policy and so "noone could have known", it's
noones fault, and Verizon is too big to fail anyways... Who might not be
fine are the dissidents affected by the spying this enabled. They might
be dead.

A CA would not allow untrustworthy individuals to handle their keys and
cert issuance process. Background checks are usually included in the
CPS, and I'm pretty sure those background checks exclude people with any
kind of serious criminal history, not just one related to the issuance
of false X.509 certifcates. So why are we limiting the "background
checks" for CAs to this?

Interestingly, the "trustworthyness" requirements are actually part of
the Mozilla policy, since we require CAs to follow the CAB Forum
Baseline Requirements. These, in turn, require that "Prior to the
engagement of any person in the Certificate Management Process, whether
as an employee, agent, or anindependent contractor of the CA, the CA
SHALL verify the identity and trustworthiness of such person." They do
not seem to have specific criteria when it is OK to make an organization
a SubCA - probably because that decision is the browser vendor's to make.

If we decided that these requirements don't apply to the CAs and Sub-CAs
themselves, we would basically be saying "no, you are not trustworthy
enough to run a part of the Certificate Management Process, but hey, do
you want to be a (Sub-)CA instead?"

On the other hand, "trustworthy" is a highly subjective thing. The
Mozilla inclusion policy calls for objective criteria. Therefore, I
would suggest to amend point 4 in the inclusion policy by adding a third
point to the examples that make us assume that a CA would cause undue
risks to users' security.This point could be, for example, worded like this:

"knowingly were involved in active attacks against internet users, e.g.
by installing software without user consent"

A lot of criticism voiced by users here was related to controversial CAs
with a questionable record in other areas, or involvement in intercept
operations, and the response to that was usually to point towards the
policy and mention that unfortunately nothing can be done because that
is not the exclusion criterion. This policy change would fix that.

We could, if we wanted to, include a clause like "have a conflict of
interest by being involved in the development or sales of software or
hardware designed to perform man-in-the-middle attacks on SSL
connections", but I left that out intentionally since such a rule would
be difficult to define precisely and controversial as per the last
discussion here.

Kind regards,
Jan

--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...

[Kathleen Wilson]

On 10/23/13 2:20 PM, Jan Schejbal wrote:
> Hi,
> there have been repeated issues where CAs were claimed to be
> untrustworthy due to prior misconduct not related to certificates.
> Usually, this was dismissed by saying that no certificate was issued
> contrary to Mozilla Policy, and thus there is no reason not to include a CA.
>

All, I know we've tried to solve this before, but let's try again.

I've add this to
https://wiki.mozilla.org/CA:CertPolicyUpdates#Consider_for_Version_2.3
~~
- Figure out a way to draw a line to say that certain types of actions
cannot be taken by the same company/organization that includes the
operation of a publicly trusted CA. Things to consider:
-- Government sanctioned/initiated/controlled projects
-- Legally forced participants
-- Ability for one corporation to completely support a spying system
like PRISM functionality (physical lines, access nodes, data
center/hosting resources, backbone level Internet controls, DNS etc.)

*newly added:*
- Address issue of trustworthy CAs
-- knowingly were involved in active attacks against internet users,

e.g. by installing software without user consent

-- have a conflict of interest by being involved in the development or

sales of software or hardware designed to perform man-in-the-middle
attacks on SSL connections

~~


I think it is time to start drafting the next version of the Mozilla's
CA Certificate Policy.

Perhaps a good place to start is the policy framework that Peter
suggested:
https://groups.google.com/d/msg/mozilla.dev.security.policy/SzSGHbrcBe0/hSGt50rJfYMJ


Thanks,
Kathleen