Since I began this discussion, additional recent misissuances by Certinomis
have been discovered and reported. [1] [2] [3] One investigation [1] led us
to suspect that Certinomis had continued to employ BR domain validation
method 3.2.2.4.5 after it was banned [4]. A former Certinomis employee
denied this [5], and over a week passed with no official response from
Certinomis before they stated that the former employee is correct.
Unfortunately, we have also seen no engagement from Certinomis on this
mozilla.dev.security.policy list since I began the discussion, almost 3
weeks ago. This week, the primary contact stated [6] “I am on holidays
until 14th of may, please apologize my slow answering.”

On a positive note, on 6-May Certinomis stated in multiple bugs that
pre-issuance linting is now operational.

I have updated the issues list [7] to reflect these changes.

As others have stated during this discussion, I believe that the issues I
have documented demonstrate a basic inability to operate effective issuance
controls. While I acknowledge the efforts that Certinomis has made to
correct their problems, they continued issuance in spite of clear evidence
that the problems weren’t resolved. Having now implemented pre-issuance
linting, it may be reasonable to expect that most of these problems are
finally resolved. However, prior to and during this discussion, they have
also continued a pattern of unresponsiveness and demonstrated a lack of the
deep understanding of our requirements and of their own operations that we
expect of every CA.

To continue to participate in the Mozilla CA program, I recommend that we
require Certinomis to create a new hierarchy and demonstrate their ability
to competently operate their CA by going through a new root inclusion
request. I’d like to propose two options for their existing root:

   1.

   Remove it from our root store in an upcoming Firefox release.
   2.

   Constrain it to use for gouv.fr domains in an upcoming Firefox release.


While there are only a few thousand unexpired TLS certificates (the root is
not trusted for email) known to chain to this root, a few are in use by
major French government websites (e.g. ants.gouv.fr). I have suggested
option #2 to minimize disruption to those subscribers and relying parties.

I will greatly appreciate everyone’s input on my recommendation and the
proposed options.


   -

   Wayne


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1544933

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1547072

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1547072#c4

[7] https://wiki.mozilla.org/CA/Certinomis_Issues
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
  • Certinomis Issues Wayne Thayer via dev-security-policy
    • Re: Certinomis Issues Wayne Thayer via dev-security-policy
      • Re: Certinomis Is... Ryan Sleevi via dev-security-policy
        • Re: Certinomi... Wayne Thayer via dev-security-policy
          • Re: Certi... philbouchet35--- via dev-security-policy
            • Re: ... mono.riot--- via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
                • ... Wayne Thayer via dev-security-policy
                • ... mono.riot--- via dev-security-policy
                • ... mono.riot--- via dev-security-policy
                • ... Wayne Thayer via dev-security-policy
                • ... Jonathan Rudenberg via dev-security-policy
                • ... Ryan Sleevi via dev-security-policy
                • ... Wayne Thayer via dev-security-policy
                • ... Matt Palmer via dev-security-policy
                • ... okaphone.elektronika--- via dev-security-policy
                • ... fchassery--- via dev-security-policy
                • ... Matt Palmer via dev-security-policy
                • ... Andrew Ayer via dev-security-policy
                • ... Wayne Thayer via dev-security-policy
                • ... Wayne Thayer via dev-security-policy

Reply via email to