On Sat, Mar 10, 2018 at 7:03 PM, syrine.tl--- via dev-security-policy <
> > Trusting a CA is like that. Operating a CA requires a high degree of
> > competence and excellence, and each CA applying for inclusion should be
> > or more competent, as or more skilled, and as or more valuable, as they
> > otherwise bring the ecosystem down rather than lifting it up.
> your effort lifting up CA ecosystem will not pay off by rejecting new CA
Sure it is, when the CA has a pattern of misissuance.
> You should also consider rejecting trusted CAs that still have
> miss-issuance concerns despite their well-established certificate issuance
> process and this is a fact. You have much more renewal request than new
That has happened as well - if you look at PROCert for example.
> If you do have a list of unacceptable auditors, it should be clearly
> stated in Mozilla Policy so that all CAs will be informed.
> Running through the archives is not considered an appropriate way of
> information for a selection process as demanding as this.
This is covered in Section 2.3 of the Policy.
> Having a fair and objective process requires applying the same acceptance
> or rejection criteria to all CAs.
> Otherwise it will be a double standards process.
Section 7.1 of the policy covers this.
""We will determine which CA certificates are included in Mozilla's root
program based on the benefits and risks of such inclusion to typical users
of our products. ""
Inclusions are not guaranteed - they are a balancing act of risk.
""We will make such decisions through a public process, based on objective
and verifiable criteria."
It is objective and verified that the Tunisian Government has had a
problematic series of misissuances, up to and including this past month,
and has consistently failed to ensure proper controls are in place.
Further, it is objective and verifiable, these were readily detectable by
the Tunisian Government, but weren't noticed as such until the issue was
raised. These included issues after the Tunisian Government reported them
Further, based on does not mean limited to.
""We reserve the right to not include certificates from a particular CA in
our root program.""
Any root request can be rejected, for any reason, or not reason at all, at
> Anyway, we are looking forward to get the official outcome of Mozilla, and
> we will spare no effort to be listed among Mozilla Trusted CA
Can you explain your motivations for this? Such a globally trusted root
carries with it profound security risk to the ecosystem. What is the
overall goal for such trust, given that it does not in any way reduce risk
of distrust. If anything, it increases the risk for all Subscribers and
Relying Parties, given the pattern of misissuances shown and the apparent
lack of technical expertise to support and protect that infrastructure.
dev-security-policy mailing list