Certinomis Issues

[Wayne Thayer]

Mozilla has decided that there is sufficient concern [1] about the
activities and operations of the CA Certinomis to collect together a list
of issues. That list can be found here:
https://wiki.mozilla.org/CA/Certinomis_Issues

Note that this list may expand or contract over time as issues are
investigated further, with information either from our or our community's
investigations or from Certinomis.

We expect Certinomis to engage in a public discussion of these issues and
give their comments and viewpoint. We also hope that our community will
make comments, and perhaps provide additional information based on their
own investigations.

When commenting on these issues, please clearly state which issue you are
addressing on each occasion. The issues have been given identifying letters
and numbers to help with this.

At the end of a public discussion period between Mozilla, our community,
and Certinomis, which we hope will be no longer than a couple of weeks,
Mozilla will move to make a decision about how to respond to these
concerns, based on the picture which has then emerged.

- Wayne

[1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues

[Wayne Thayer]

Yesterday, Andrew Ayer filed a bug [1] identifying 14 pre-certificates
issued by Certinomis in February 2019 containing an unregistered domain
name. Since the cause described in the incident report is similar, I added
this under issue F.1.

[Paul Kehrer]

A publicly trusted CA is expected to demonstrate technical competence
around validation, issuance, and security of their infrastructure. When
non-compliant issuance occurs the community should expect any well operated
CA to rapidly detect, remediate the issue, and perform a root cause
analysis focused on how to prevent that entire class of problems in the
future.

Issues E and F argue that Certinomis is technically incapable of operating
a certificate authority in compliance with the expectations we have for
such trust. In issue E we see non-compliance with a BR requirement for OCSP
responder behavior for over 4 years. Incidentally, the requirement in
question was explicitly added to the BRs in response to a major CA security
incident. Issue F lists a pattern of repeated misissuance that suggests
repeated human typos with no systemic improvement.

Similarly, issues A through D show an apparent disinterest in policy,
compliance, and communications. Issuing a cross-certification for a CA that
was in the middle of major sanctions, having repeated audit gaps, ignoring
Mozilla root store policies for years, and generally declining to engage
with the community to help resolve these issues is not the action of an
organization that understands the responsibility of being a CA.

I believe the issues highlighted by Mozilla represent, in aggregate,
extremely strong evidence that Certinomis is unfit to operate a trusted
certificate authority.

-Paul

On April 17, 2019 at 2:44:44 AM, Wayne Thayer via dev-security-policy (

dev-secur...@lists.mozilla.org) wrote:

Mozilla has decided that there is sufficient concern [1] about the
activities and operations of the CA Certinomis to collect together a list
of issues. That list can be found here:
https://wiki.mozilla.org/CA/Certinomis_Issues

Note that this list may expand or contract over time as issues are
investigated further, with information either from our or our community's
investigations or from Certinomis.

We expect Certinomis to engage in a public discussion of these issues and
give their comments and viewpoint. We also hope that our community will
make comments, and perhaps provide additional information based on their
own investigations.

When commenting on these issues, please clearly state which issue you are
addressing on each occasion. The issues have been given identifying letters
and numbers to help with this.

At the end of a public discussion period between Mozilla, our community,
and Certinomis, which we hope will be no longer than a couple of weeks,
Mozilla will move to make a decision about how to respond to these
concerns, based on the picture which has then emerged.

- Wayne

[1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Wayne Thayer]

Yesterday, Andrew Ayer reported two additional misissued certificates:

* Space in SAN, issued yesterday:
https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7
* O=Entreprise TEST, issued in January:
https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20

I've added these to the issues list.

[Matt Palmer]

On Thu, Apr 18, 2019 at 12:29:05PM -0700, Wayne Thayer via dev-security-policy wrote:
> Yesterday, Andrew Ayer reported two additional misissued certificates:
>
> * Space in SAN, issued yesterday:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7

I'm starting to think Certnomis really aren't taking any of this seriously.
Continuing to issue certificates without effective controls in place to
prevent misissuance is not the behaviour of an organisation worthy of the
trust granted to a CA.

- Matt

[Ryan Sleevi]

On Wed, Apr 17, 2019 at 5:22 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Yesterday, Andrew Ayer filed a bug [1] identifying 14 pre-certificates
> issued by Certinomis in February 2019 containing an unregistered domain
> name. Since the cause described in the incident report is similar, I added
> this under issue F.1.
>

In the course of investigating this bug [1], it further appears that
Certinomis has continued to use method 3.2.2.4.5 to validate domains,
despite it being formally prohibited in the Baseline Requirements 8 months
ago, in August 2018.

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

[Wayne Thayer]

Since this is a separate, serious issue, I filed a new bug and requested an
incident report: https://bugzilla.mozilla.org/show_bug.cgi?id=1547072

I added this to the issues list as Issue G:
https://wiki.mozilla.org/CA/Certinomis_Issues

I also added a summary of the response received yesterday from Certinomis
to issue F.3: Inadequate Controls on Production Testing

[philbo...@gmail.com]

> >Below is to clarify Wayne's summary related to Certinomis (Issue C: Audit Issues (2015-2018)
Generally speaking, a CAB cannot decide to perform an audit against CAB/forum requirements unless a formal order is made by the TSP. It is not to the CAB to enforce the rules regarding the "no gap rules" between two audits. This is exactly what happened with Certinomis where we performed audits on request.
2015 assessment report is not an “audit attestation" for the browsers but a certificate of conformity that claims conformance to a French regulation called RGS which implied ETSI standards compliance but not CAB/forum audit compliance.
LSTI was not informed that Certinomis provided this document as an "audit attestation" nor that Mozilla accepted it.
2016 assessment report is indeed an attestation letter LSTI issued on Certinomis request. It covers a period beginning on 13-May 2015 – to 13 May 2016. LSTI provided an annual audit as Certinomis could have been audited by another CAB before 2015.
2017 assessment report
LSTI didn't issue to Certinomis any "audit attestation" for the browsers in 2017. The document Wayne references is a "Conformity Assessment Report" for the eIDAS regulation.
2018 assessment report was due end of October but not received by Mozilla until 23-November.
At this period LSTI faced a huge increase of its activity and auditors were a little bit overwhelmed that created the extra delay to provide the report and the "audit attestation".

[mono...@gmail.com]

> 2017 assessment report
> LSTI didn't issue to Certinomis any "audit attestation" for the browsers in 2017. The document Wayne references is a "Conformity Assessment Report" for the eIDAS regulation.

I had a look at the 2017 report, and unless I misread, it implies conformity to ETSI EN 319 401 (Est vérifiée également la conformité aux normes: EN 319 401), whereas EN 319 401 states, "The present document is aiming to meet the general requirements to provide trust and confidence in electronic
transactions including, amongst others, applicable requirements from Regulation (EU) No 910/2014 [i.2] and those from CA/Browser Forum [i.4].", so I'm not sure how that squares with saying it wasn't an audit taking CA/BF regulations into account?

[Jakob Bohm]

But does EN 319 401, as it existed in 2016/2017 incorporate a clause to
apply all "future" updates to the CAB/F regulations or otherwise cover
all BRs applicable to the 2016/2017 timespan?

Because otherwise EN 319 401 compliance only implied compliance with
the subset of the BRs directly included in EN 319 401 or documents
incorporated by reference into EN 319 401 (the above quote is a
statement of intent to include the BR requirements that existed when
EN 319 401 was written).

That said, Mozilla policy at the time may have explicitly stated that an
EN 319 401 audit is/was sufficient for Mozilla inclusion purposes.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Wayne Thayer]

On Wed, May 1, 2019 at 3:25 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 01/05/2019 22:29, mono...@gmail.com wrote:

The 2017 report [1], while not an attestation letter, indicates conformance
with EN 319 411 (refer to annex 2). This is the audit that covers
compliance with the BRs and is required by Mozilla policy.

>
> But does EN 319 401, as it existed in 2016/2017 incorporate a clause to
> apply all "future" updates to the CAB/F regulations or otherwise cover
> all BRs applicable to the 2016/2017 timespan?
>
> Because otherwise EN 319 401 compliance only implied compliance with
> the subset of the BRs directly included in EN 319 401 or documents
> incorporated by reference into EN 319 401 (the above quote is a
> statement of intent to include the BR requirements that existed when
> EN 319 401 was written).
>
> That said, Mozilla policy at the time may have explicitly stated that an
> EN 319 401 audit is/was sufficient for Mozilla inclusion purposes.
>
>

Correct - 319 411 was (and still is) the Mozilla audit requirement.

[1] https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

[mono...@gmail.com]

On Thursday, May 2, 2019 at 1:11:20 AM UTC+2, Wayne Thayer wrote:
> Correct - 319 411 was (and still is) the Mozilla audit requirement.
>
> [1] https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Thanks for the clarification Wayne.

[mono...@gmail.com]

> But does EN 319 401, as it existed in 2016/2017 incorporate a clause to
> apply all "future" updates to the CAB/F regulations or otherwise cover
> all BRs applicable to the 2016/2017 timespan?

Interesting question. Would it have to explicitly claim to incorporate any future updates? Or would it have to explicitly *deny* to be applied to future updates? My personal interpretation would be to assume compliance at PIT and including potential future amendments, unless explicitly stated otherwise.

[Wayne Thayer]

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

[Jonathan Rudenberg]

On Tue, May 7, 2019, at 19:48, Wayne Thayer via dev-security-policy wrote:
> 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.

Hi Wayne,

My preference would be removing the root entirely. So far there have been no requests from either the CA or any subscribers for special treatment of specific sites or certificates. If Certinomis isn't trustworthy (which I think is documented in the current record), why should a high assurance use case (government websites) be special cased as trusted?

It's also worth noting that the certificate issued for ants.gouv.fr has a three year validity period, and the lower we push validity periods, the lower the impact is for removing individual CAs from root stores.

Jonathan

[Ryan Sleevi]

On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

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

Thanks Wayne for ensuring the conversation progresses in a timely fashion.

Your Option #2 does have precedent, both by Mozilla and by other browser
vendors, so I can understand the appeal. Some of these incidents have been
documented by Mozilla [1] in the context of past discussions about
voluntary name constraints [2], which captured a lengthy discussion about
some of the tradeoffs involved.

I appreciate that your Option #2 is only proposed in the context of
addressing compatibility risks. Other CA events have prompted similar
analysis, with different vendors taking different approaches (e.g. [3] vs
[4]/[5], [6] v [7]). Despite these initial differences, it's worth noting
that even in these cases of addressing potential compatibility issues, the
industry uniformly aligned on ultimately removing trust in these CAs. It is
unclear whether your Option #2 is proposing such a convergence, and when,
or whether you see this as an indefinite proposition.

One thing to consider with the creation of allowlists, whether in the
context of name constraints (e.g. India CCA, ANSSI) or in the context of
specific domains and certificates (Apple and Google, respectively, in the
context of WoSign/StartCom), an important factor to consider is not just
the compatibility, but the risk and value of the domain(s) being protected.
If the conclusion is that Certinomis' existing controls are insufficient to
provide reliable security, and its operations are not robust enough to
provide the assurances that the community and Mozilla users critically
depend on, then it seems important to also consider the potential harm of
misissued certificates for those domains

In the case of India CCA, this was part of the Indian National Informatics
Center (India NIC), which itself was the domain registry for these domains.
Similarly, while AFNIC is the operator for the French TLDs, ANSSI was the
French national computer security agency to protect government systems. In
these cases, the allowlist effectively and specifically accomodated the
government needs and oversight. In the case of Certinomis, it is unclear
whether the French Government itself would want to delegate the control and
protection of its critical systems to an organization that has suffered
such repeated failures.

Has there been any communication with the agencies tasked with this - most
likely, ANSSI itself? For example, the same concerns that lead to
contemplating "Option #1" may similarly lead the French government to
replace their certificates, rather than run further risk of misissuance.
Similarly, has there been any consideration to simply allowlist the limited
existing certificates, with a clear sunset date, as an alternative to name
constraining?

My overarching concern with any solution that does not eventually coverge
at #1, if not begin there, is that it creates significant confusion about
to what extent "legacy compatibility" is valued compared to "security". If
such compatibility, with such a small number of sites, is such a concern,
then as Jonathan Rudenberg has highlighted, it's useful to consider what
other, additional steps, Mozilla and other browsers may wish to take to
reduce the compatibility risk. As Jonathan rightly highlighted, one of the
best ways to do this is a reduction in certificate lifetimes. Are there
other steps that might be similarly productive to also consider, and in
doing so, provide confidence that any Option #2 would, if adopted, be
temporary, both specific to Certinomis and more generally as a mitigation
strategy?


[1] https://wiki.mozilla.org/CA:NameConstraints
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/pF4aVsF21ww/yKDhNpEt-2gJ
[3]
https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
[4]
https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html
[5] https://support.apple.com/en-us/HT204132
[6]
https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html
[7]
https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2982792

[fcha...@gmail.com]

Dear All,

Before detailing my answer, I would like to refute opinions that Certinomis does not take these subjects seriously: since February the management of Certinomis was directly involved in the exchanges with the Mozilla community, decisions were made and are implemented.

I acknowledge that I was surprised by the multiple topics that were grouped by Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne THAYER for his analysis of a technical point of view that distinguished different categories of problems.

For my part, my role is above all to advance the practice of Certinomis, and for this I must classify the problems according to their cause, because the best way to solve a problem is to correct its cause. And I will allow myself to structure my answer according to this classification that I made of problems, reserving for the end the Issue A (Startcom Signing) that I really did not expect to hear about.

- First cause of problems: An organization of the technical direction not adapted to the plan of charge in 2018

In 2018, Certinomis carried out several projects to renew its technical capabilities (new production site, new PKI software, adaptation to BR 1.6.5, among others). Franck as our Technical Director led all this work. And at the same time, Frank was Mozilla’s only point of contact. Inevitably there has been errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 comment#20 and answer that are part of Issue F3) and low reactivity (Issue B until November 2018) and perhaps editorial errors when updating PCs and DPCs (for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the description, in English, is that of rule 3.2.2.4.6)

-->Response to Cause 1:

- Action 1:
Franck’s departure was an opportunity to restructure Certinomis’ technical management with three roles for caring of SSL activity.
- an internal audit team independent of the project management is in place; the structure that ensures it has implemented a daily linting post-issuance control since April 1st, to allow us to detect without delay any possible mistake.
- An employee of the quality team of Certinomis will be designated as the main contact of the CA/B Forum and Mozilla (but not the only point of contact).
To be complete on this topic the transition between Franck and another person had been prepared during the three months following his decision to leave.
But it soon became clear that the person chosen was not fitted to the role. It is for this reason that I have resumed the discussion with Mozilla personally, and I intend to remain engaged on the subject until the situation is stabilized.
-- PKI’s project management will carry out changes, settings and corrections.

The idea is to separate those who propose the evolutions, those who realize them and those who control them. In this way each one carries out his task without being inhibited by the constraints of the other.

- Second cause of problem: insufficient syntax control for certificate request processed by Enterprise RAs.

Several problems have been reported for certificates issued for the domains "laposte.fr" and "labanquepostale.fr".
La Poste and La Banque Postale belong to the La Poste group, as well as Certinomis. For each of these two companies an external RA was set up by Certinomis, to facilitate the issuance of certificates on the two domains controlled by these two companies. The ownership of domain names and the authorisation of operators have been established beforehand.
In this context, it has recently happened that CSRs generated by technicians on their servers are inserted by the operators in the AE software and that the syntax errors they contained are not highlighted by the RA software neither detected by operators (a space in a domain name, truncated domain names, empty SANs, function names instead of geographical indications etc. (Issues F1 & F2).
Under no circumstances could these errors lead, or could lead, to the supply to an illegitimate person for this purpose of a certificate containing a real domain name.

-->Responses to Cause 2:

- Action 2: Entreprise RAs have been temporarily deactivated to allow us to correct this situation.

- Action no. 3: The action carried out as a priority was to install the pre-issuance linting. It is now operational as we committed to.

- Action 4: The next action will be to strengthen control on the locality field in these external RAs.

- Third cause of problem: human-based registration.

Several certificates were issued in good faith for testing by operators of Certinomis (Issue F3). To understand, it is necessary to know that for our other ranges of certificates, it is sometimes necessary to provide a test certificate from the production CAs, for the purpose of testing complex applications from end to end. Well, in those cases, the operator must display the word "TEST" in the significant fields; and in order that the invalidity of these certificates be even more evident to third parties who rely, we have, voluntarily, created fictitious organizations whose name is intended to make evident this fictitious character, and above all, also a fictitious organization identifier. The objective is that no one can be misled with any of these certificates.

This practice is forbidden by the CA/B Forum, I do not discuss it, and simply I explain why the operators of Certinomis could have made these errors.

Another error related to human control occurred in February 2019: the town hall of Le Cannet, client of Certinomis for several years, was mistaken in writing its application form and requested a domain name "mediatheque-lecannet.fr" instead of "mediatheque.lecannet.fr". And the Certinomis RA operator did not notice that instead of a dot there was a dash.
The employee who validated this request made an indisputable error, even though I am convinced that his vigilance would have been stronger for an unknown client.

--> Responses to cause 3:

- Action no. 5: for test certificates, the solution was to isolate the test organizations in a registration area where PTC SSL certificates are not available. This solution is now fully in place.

- Action no. 6: Certinomis has developed a function for sending e-mails in accordance with BR 1.6.5 method 3.2.2.4.4 This function will be in production by May 15, and then it will no longer be possible for a human operator to add or validate a domain name without a positive response according to 3.2.2.4.4

On these three main causes of problem, Certinomis has already started to act, certain actions have been completed (action n°2, action n°3, action n°5) one is partially completed (action n°1) and the others will be completed within a maximum of one month (action n°6) or two months (action n°4). And our efforts will not stop, other improvements are already in the works and will have to be added to our road map (implementation of method 3.2.2.4.6 for example).

I don’t want to finish this answer without going back to the A issue, the Startcom cross-sign.
I will not repeat all the history, Franck LEROY had detailed it in his e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of view: at no time did we in this case violate an existing rule, nor did we assist or seek to assist Startcom in circumventing the remediation plan proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand if what we wanted to do was acceptable, we clearly made it a condition for Iñigo to follow the plan and waited to be convinced that he had done so, and when, after all these precautions, we were told that we had not understood this remedial plan, we revoked both CAs without discussion.
I hadn’t heard anything about it in those two years.
So what is the factual criticism that is being made now, two years later? I don’t know about that.
And what is the link with our difficulties of this year? None!

In conclusion, I would like to remind you that Certinomis, although a modest player in the SSL business, is a respectably well-known company in France, qualified for several ranges of certificates, and which provides personal signature certificates for many organizations, large companies, ministries and local communities.

This good reputation does not justify the errors that are currently highlighted.

But this fame was not obtained by chance, and on the contrary, it is a testament to our know-how, our work and the rigour we put into it.

And I believe that considering this is likely to reassure the Mozilla community and restore its confidence: It’s true that we have been initially destabilized by the barrage of questions and bug notifications that started just after the departure of our former technical director Franck LEROY.
But the attention paid to this issue over the past three months and especially the rapid progress of our action plan show that we are taking these matters seriously and that we are able to play our role as a CA as well in the rules of the CA/B Forum than in the other rules to which we are subject.

Kind Regards,

François CHASSERY
CEO
Certinomis

[Wayne Thayer]

Thank you for this response Francois. I have added it to the issues list
[1]. Because the response is not structures the same as the issues list, I
did not attempt to associate parts of the response with specific issues. I
added the complete response to the bottom of the page.

On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> I don’t want to finish this answer without going back to the A issue, the
> Startcom cross-sign.
> I will not repeat all the history, Franck LEROY had detailed it in his
> e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of
> view: at no time did we in this case violate an existing rule, nor did we
> assist or seek to assist Startcom in circumventing the remediation plan
> proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand
> if what we wanted to do was acceptable, we clearly made it a condition for
> Iñigo to follow the plan and waited to be convinced that he had done so,
> and when, after all these precautions, we were told that we had not
> understood this remedial plan, we revoked both CAs without discussion.
> I hadn’t heard anything about it in those two years.
> So what is the factual criticism that is being made now, two years later?
> I don’t know about that.
> And what is the link with our difficulties of this year? None!
>
>

In response to the email from Franck that you mention, Gerv responded [1]
by quoting the plan he had approved and stating "This seems to be very
different to the plan you implemented." By cross-signing Startcom's old
roots, Certinomis did assist Startcom in circumventing the remediation
plan, and by proposing one plan then implementing a different one,
Certinomis did so without Mozilla's consent.

Startcom misissued a number of certificates (e.g. [3]) under that
cross-signing relationship that Certinomis is responsible for as the
Mozilla program member.

By cross-signing Startcom's roots, Certinomis also took responsibility for
Startcom's qualified audit.

I will also add this information to the issues list.

- Wayne

[1] https://wiki.mozilla.org/CA/Certinomis_Issues
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ
[3] https://crt.sh/?opt=cablint&id=160150786

[Jakob Bohm]

On 10/05/2019 02:22, Wayne Thayer wrote:
> Thank you for this response Francois. I have added it to the issues list
> [1]. Because the response is not structures the same as the issues list, I
> did not attempt to associate parts of the response with specific issues. I
> added the complete response to the bottom of the page.
>
> On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>

>> ...
> ...

>
> In response to the email from Franck that you mention, Gerv responded [1]
> by quoting the plan he had approved and stating "This seems to be very
> different to the plan you implemented." By cross-signing Startcom's old
> roots, Certinomis did assist Startcom in circumventing the remediation
> plan, and by proposing one plan then implementing a different one,
> Certinomis did so without Mozilla's consent.
>

As can be seen from your [3] link, Certinomis cross-signed StartCom's
NEW supposedly remediated 2017 hierarchy, not the old root.

However it was still wrong.

> Startcom misissued a number of certificates (e.g. [3]) under that
> cross-signing relationship that Certinomis is responsible for as the
> Mozilla program member.
>
> By cross-signing Startcom's roots, Certinomis also took responsibility for
> Startcom's qualified audit.
>
> I will also add this information to the issues list.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Certinomis_Issues
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ
> [3] https://crt.sh/?opt=cablint&id=160150786
>

[Wayne Thayer]

On Thu, May 9, 2019 at 8:56 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 10/05/2019 02:22, Wayne Thayer wrote:

> > Thank you for this response Francois. I have added it to the issues list
> > [1]. Because the response is not structures the same as the issues list,
> I
> > did not attempt to associate parts of the response with specific issues.
> I
> > added the complete response to the bottom of the page.
> >
> > On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >

> >> ...
> > ...

> >
> > In response to the email from Franck that you mention, Gerv responded [1]
> > by quoting the plan he had approved and stating "This seems to be very
> > different to the plan you implemented." By cross-signing Startcom's old
> > roots, Certinomis did assist Startcom in circumventing the remediation
> > plan, and by proposing one plan then implementing a different one,
> > Certinomis did so without Mozilla's consent.
> >
>

> As can be seen from your [3] link, Certinomis cross-signed StartCom's
> NEW supposedly remediated 2017 hierarchy, not the old root.
>

> Thank you for correcting me Jakob. I was confused by a statement in the
2017 thread that I referenced, but I see now that Certinomis only
cross-signed Startcom's new roots. Since Certinomis cross-signed Startcom's
new roots before the remediation plan was completed, I believe the
statements I made are otherwise correct.

[fcha...@gmail.com]

Dear Wayne,

I’m not arguing that signing the new Startom root was a mistake.In fact, as soon as we were told, we backed off.
Our understanding at that time was that the remediation plan had been fully implemented. But the Mozilla staff did not agree and had another interpretation of the situation.
I do not know how or when a distortion was introduced between Franck’s exchange with the Mozilla staff and our action.
But there was no intent to circumvent the Mozilla plan, and we corrected it immediately when we were asked to do so.
That is why I do not understand why this subject is included in the present discussions: if there has been an error, it is a past error, corrected in the past and on which no further action is possible.
At a minimum it should only be recalled as a problem that has been solved.

Kind Regards,

François

[Wayne Thayer]

On Fri, May 10, 2019 at 8:09 AM fchassery--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Dear Wayne,
>
> I’m not arguing that signing the new Startom root was a mistake.In fact,
> as soon as we were told, we backed off.
> Our understanding at that time was that the remediation plan had been
> fully implemented. But the Mozilla staff did not agree and had another
> interpretation of the situation.
> I do not know how or when a distortion was introduced between Franck’s
> exchange with the Mozilla staff and our action.
> But there was no intent to circumvent the Mozilla plan, and we corrected
> it immediately when we were asked to do so.
> That is why I do not understand why this subject is included in the
> present discussions: if there has been an error, it is a past error,
> corrected in the past and on which no further action is possible.
>

The answer can be found on our Maintenance and Enforcement wiki page under
the Recurring Issues section [1], which states (in part) "Mozilla considers
the totality of known issues and patterns of behavior in a CA's response to
those issues."

[1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues

[Wayne Thayer]

On Wed, May 8, 2019 at 10:32 AM Ryan Sleevi <ry...@sleevi.com> wrote:

If we decide to take option 2, I'm open to suggestions about the length of
time we should continue to trust the root for issuance to gouv.fr domains,
but I don't expect the answer to be "forever". One approach would be to
require a relatively quick transition prior to the inclusion of a new
Certinomis root. Another is to set a date far enough in the future that we
believe it would be reasonable for Certinomis to have a new root included
and transition to it, allowing gouv.fr site to continue to rely on
Certinomis.

No, I have not attempted to contact these site operators, nor has the
option of allowlisting specific certificates been given any consideration.
I am not opposed to the idea of allowlisting specific certificates.

My overarching concern with any solution that does not eventually coverge
> at #1, if not begin there, is that it creates significant confusion about
> to what extent "legacy compatibility" is valued compared to "security". If
> such compatibility, with such a small number of sites, is such a concern,
> then as Jonathan Rudenberg has highlighted, it's useful to consider what
> other, additional steps, Mozilla and other browsers may wish to take to
> reduce the compatibility risk. As Jonathan rightly highlighted, one of the
> best ways to do this is a reduction in certificate lifetimes. Are there
> other steps that might be similarly productive to also consider, and in
> doing so, provide confidence that any Option #2 would, if adopted, be

> temporary, both specific to Certinomis and more generally as a mitigation
> strategy?
>
>
I share the concern that option #2 sends a confusing message. As Jonathan
stated, why should we distrust a CA for all but the most important websites
they secure?

[Matt Palmer]

On Fri, May 10, 2019 at 09:59:48AM -0700, Wayne Thayer via dev-security-policy wrote:

> > On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >> 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.

[...]

> If we decide to take option 2, I'm open to suggestions about the length of
> time we should continue to trust the root for issuance to gouv.fr domains,
> but I don't expect the answer to be "forever". One approach would be to
> require a relatively quick transition prior to the inclusion of a new
> Certinomis root. Another is to set a date far enough in the future that we
> believe it would be reasonable for Certinomis to have a new root included
> and transition to it, allowing gouv.fr site to continue to rely on
> Certinomis.

Apologies if I missed mention of this, but has there been any request from
the operators of gouv.fr to maintain trust in Certinomis for subdomains
thereof? I'd be *extremely* uncomfortable with the idea that Firefox would
continue to trust an otherwise distrusted CA for a domain hierarchy without
the enthusiastic and informed consent of the operator of that hierarchy.

- Matt

[okaphone.e...@gmail.com]

On Friday, 10 May 2019 19:00:11 UTC+2, Wayne Thayer wrote:

...

> I share the concern that option #2 sends a confusing message. As Jonathan
> stated, why should we distrust a CA for all but the most important websites
> they secure?

I'd say that both "too big to fail" and "too important to fail" are not particularly good reasons for trusting something/somebody.

It's understandable that as a browser you'd want to limit the collateral damage of distrusting a CA, but your first priority should definitely be limiting the possible damage from trusting a CA that has turned out not to be trustworthy.

CU Hans

[fcha...@gmail.com]

Dear All,

First, seeing the post of Wayne THAYER dated 10th of May I want to precise how my own answer dated 9th of May covers the different issues:

- Action 1 is our response to Issue B, C, D (work in progress), E and is a guaranty that Issue A will not happen again;
- Action 2 to 6 target Issue F;

In detail:

Issue A found its source in the good relationships between Franck and Iñigo, who both are no more in charge;
Issue B: we have identified since last year that a non-operational contact person will be the best way to follow the relation with the Mozilla Community; after a first attempt we are looking for someone and I am now the acting contact person.
Issue C: there is now a team (not a single man) in charge of audits.
Issue D: the CP is currently under revision, and later in translation, in response of the Certinomis’ Issues page; and afterwards it will be followed by the contact person and controlled by the audit team, that will maintain the quality and the update of the document.
Issue E: is past and happened under the former organisation too. The separation between project management and audit team is our solution to control internally the conformity of implementation.

As you can see, most of these issues are from the past, fixed or on their way to be fixed soon.

Issue F in various occurrences is a consequence of too much reliance on human controls.
To fix that, 5 quick actions have been initiated among them 4 are achieved.

Second, all these progresses have been obtained in few months and we made this real effort (all over technical subjects have been frozen last three months) to demonstrate our concern about BR conformity.
Since problems are 90% fixed, I believe that it would not threaten the security to keep trust in Certinomis’ Root. Even more, distrusting us at the very moment when we are achieving corrections is not encouraging security, in my opinion.
For this reason, I calls for rejecting option#1 that is an answer to the past, not to the present nor to next future.

Third, if really option#2 must be considered, there is for sure one first operator who will without any hesitation grant us its trust: French group La Poste, to which Certinomis belongs to. And I will easily obtain official request for domain names owned by the group (“laposte.fr”, “labanquepostale.fr”, “Docaposte.fr” etc.)

But of course I would really appreciate that there would be a clear distinction in considering apart events of the past (before 1st of December 2018) from present and coming events, because we really initiated a strong change in Certinomis’ technical management.

Kind Regards,

François CHASSERY,
CEO
Certinomis

[Matt Palmer]

On Mon, May 13, 2019 at 02:35:51PM -0700, fchassery--- via dev-security-policy wrote:
> Issue A found its source in the good relationships between Franck and
> Iñigo, who both are no more in charge;

Is the only change to address Issue A the removal of Franck from a position
of leadership within Certinomis?

> Issue F in various occurrences is a consequence of too much reliance on human controls.

What changes have been made to address the underlying failure in risk
management which allowed such a high degree of reliance on human controls?

Further, what changes have been made in management policies and procedures
to address the fact that this reliance was allowed to continue for an
extended period after the limitations were clearly identified?

> But of course I would really appreciate that there would be a clear
> distinction in considering apart events of the past (before 1st of
> December 2018) from present and coming events, because we really initiated
> a strong change in Certinomis’ technical management.

That is yet to be established.

- Matt

[Andrew Ayer]

I would like to highlight the many examples of Certinomis' poor incident
response.

Sometimes Certinomis ignores problems entirely - for example, in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c5>, a misissued
certificate is still unrevoked and unacknowledged three months after
being reported. Other times, they respond with very sparse details,
for example <https://bugzilla.mozilla.org/show_bug.cgi?id=1551357#c3>
from yesterday.

Most of the time Certinomis appears to copy and paste the list
of problematic certificates that were reported to them instead
of performing their own investigation. In some cases additional
problematic certificates are later discovered that they missed - for
example <https://bugzilla.mozilla.org/show_bug.cgi?id=1524103#c4> from
this year and <https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c9>
from last year.

The worst example is
<https://bugzilla.mozilla.org/show_bug.cgi?id=1551390> from yesterday,
in which Certinomis didn't even examine the full list of problematic
certificates that were reported to them. I reported 174 certificates
with an OCSP status of "unknown." In their incident response,
Certinomis stated that their "Web CA" issuer doesn't suffer from this
problem, even though seven of of the certificates in my report were
issued from this CA. Furthermore, between the time of my report and
Certinomis' response, two additional certificates were issued from "Web
CA" with an unknown OCSP status. Neither was included in Certinomis'
response - instead, Certinomis just linked to the list I provided them.

As recently as last month, Certinomis blamed human error in
their incident response, stating that issuing certificates to
unregistered domains was "a single human error not a systemic issue"
<https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c1>, even though
the fact that human error is possible is the systemic issue, and even
though this incident was far from the first time Certinomis had issued
certificates without doing domain validation.

On May 6, 2019, François CHASSERY stated: "I confirm
that pre-issuance linting is now operationnal."
<https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c8>
On the basis of that response,
<https://bugzilla.mozilla.org/show_bug.cgi?id=1539531> and
<https://bugzilla.mozilla.org/show_bug.cgi?id=1542793> were resolved.

However, on May 13, 2019, Certinomis issued four certificates with
an invalid DNS SAN (lrcopro.), which is trivially detectable by
linting: <https://bugzilla.mozilla.org/show_bug.cgi?id=1551357>

In response, Certinomis stated that pre-issuance linting is actually
only operational under two of their issuing CAs, "Web CA" and "Safe CA".
Therefore, pre-issuance linting was never fully operational at
Certinomis, and it was misleading for them to state "pre-issuance
linting is now operationnal." This, combined with the incomplete
remediation last year in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20>, calls into
question any other remediation which they claim has been completed.

A CA that performs bad incident response will be unable to correctly
fix problems because they will fail to identify the full scope of the
issue or identify the root cause that needs to be fixed. I believe the
evidence shows that Certinomis performs very poor incident response,
and continues to do so despite the new technical management. They are
therefore unlikely to improve and will remain a risk to Firefox users.
They should be distrusted.

Regards,
Andrew

[Wayne Thayer]

I would like to thank everyone for your constructive input during this
discussion. Since my post last week suggesting two options for distrusting
the existing Certinomis root, a number of events have occurred, including
the following:

* Certinomis confirmed that they have implemented pre-issuance linting [1],
although it has more recently been disclosed that the linting is not active
on older subCAs that Certinomis no longer intend to use for TLS [2][3].
* Francois posted a detailed response [2] to the issues list [4], and
followed that with another explanation of how the response covers all of
the issues that were identified [5].
* Four new precertificates containing an invalid SAN value [6] were found
to have been issued on 13-May, after pre-issuance linting was in place.
This was explained as being caused by a misconfiguration that allowed TLS
issuance from one of the older subCAs without pre-issuance linting in place.
* On 13-May, 174 precertificates with ‘unknown’ OCSP status were discovered
[7]. Two more were discovered on 14-May. Certinomis currently does not have
a solution to this problem [3].
* On 15-May, Andrew Ayer argued in this thread that Certinomis responds
poorly to incidents.

While the most recent incidents have not yet been fully understood, their
existence points to the fact that Certinomis continues to demonstrate
compliance issues, and it supports my previous recommendation to distrust
the Certinomis root. While I encourage continued discussion of these
issues, at this time we have enough information to make a decision.

I proposed an option involving name constraining the existing Certinomis
root rather than completely removing it from the Mozilla NSS root store.
The feedback that was received was largely against this idea, and the
arguments presented for not extending trust in the most important gouv.fr
government site certificates - especially when they haven’t asked us to do
so - are compelling.

In conclusion, I recommend the following:

Remove the “Certinomis - Root CA” from the Mozilla root store in an
upcoming NSS release.
* Treat any cross-signature of the existing root by another CA in Mozilla’s
program as a policy violation that will (at a minimum) result in the
immediate addition of the cross-certificate to OneCRL.

Allow Certinomis to apply for inclusion in the Mozilla program with one or
more newly created root(s)
* Certinomis must undergo the normal Mozilla root inclusion process
* Certinomis may be required to explain in detail how the issues discussed
in this thread have been resolved.
* A new audit report covering a period ending after the new root(s) are
created will be required prior to completing the inclusion process.

Mozilla may consider permitting an existing Mozilla CA Program member to
cross-sign the new root under certain conditions, such as requiring
Certinomis to produce a “clean” audit prior to the signing. Any such
agreement must be disclosed to Mozilla, discussed on this list, and
approved by Mozilla before the new Certinomis root key(s) are signed by any
root included in our program.

I will appreciate any feedback you have on this recommendation.

I will soon file a bug requesting removal of the “Certinomis - Root CA”
from NSS. If Kathleen accepts this recommendation, I predict that the root
will be removed in the version of NSS that ships with Firefox 69 in
September [8].

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c8
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357#c3
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357#c6
[4] https://wiki.mozilla.org/CA/Certinomis_Issues
[5]
https://groups.google.com/d/msg/mozilla.dev.security.policy/rmU311hOIIc/UiLZU1gDBQAJ
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
[8] https://wiki.mozilla.org/Release_Management/Calendar

On Tue, May 7, 2019 at 4:48 PM Wayne Thayer <wth...@mozilla.com> wrote:

> 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 Thayer]

On Thu, May 16, 2019 at 4:23 PM Wayne Thayer <wth...@mozilla.com> wrote:

I will soon file a bug requesting removal of the “Certinomis - Root CA”
> from NSS.
>

This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374

[Jakob Bohm]

To more accurately assess the impact of distrust, maybe someone with
better crt.sh skills than me should produce a list of current
certificates filtered as follows:

- Sort by O= (organization), thus grouping together certificates that
were issued to the same organization (for example, there are many
issued to divisions of LA POSTE).
- Exclude certificates that expire on or before 2019-08-31, as those
will be unaffected by a September distrust.
- Exclude certificates issued after 2019-05-17 (today), as Certinomis
should be aware of the likely distrust by tonight.

[Ryan Sleevi]

On Fri, May 17, 2019 at 1:21 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 17/05/2019 01:39, Wayne Thayer wrote:

> To more accurately assess the impact of distrust, maybe someone with
> better crt.sh skills than me should produce a list of current
> certificates filtered as follows:

If you feel this is important to consider, especially if it may impact any
proposals, may I ask why you waited so long to suggest this, and how you
see this information being used now?

There is value in analyzing the information when exploring options, and I
have no doubt, given how trivial it is to explore this information from CT,
that it was and has been taken into consideration. It was certainly
something I looked at when Wayne proposed options, and it’s clear that
Andrew Ayer has run similar analysis.

However, I do not believe it valuable or productive to be suggesting at
this venture, and I think it’s a particularly unhelpful way to engage to
suggest to do so. If you feel that such information should change how
things progress, or you’re unsure of whether it has been taken into
consideration, it seems that concern could have been raised over the past
month of discussion. The suggestion, as presented, does not lead to any
concrete behavior changes - it’s merely presented as information for
informations sake. If there is a feeling that it should change something:
the proposed next steps, the timeline, the implementation details of the
action, that the next steps are too risky, etc, then it is far more
productive to simply state that, and explain your point of view, so as to
justify why you believe it valuable to look at this information.

It has been considered. If you would like to consider it for yourself, the
information is readily available. If you believe the information should
change things, you should say so, and during the community discussion
phase. As presented though, I’m not sure it’s a very useful or helpful
statement, so something clearer would be much more beneficial.

[Jakob Bohm]

On 17/05/2019 07:21, Jakob Bohm wrote:
> On 17/05/2019 01:39, Wayne Thayer wrote:
>> On Thu, May 16, 2019 at 4:23 PM Wayne Thayer <wth...@mozilla.com> wrote:
>>
>> I will soon file a bug requesting removal of the “Certinomis - Root CA”
>>> from NSS.
>>>
>>
>> This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374
>>
>
> To more accurately assess the impact of distrust, maybe someone with
> better crt.sh skills than me should produce a list of current
> certificates filtered as follows:
>
> - Sort by O= (organization), thus grouping together certificates that
>  were issued to the same organization (for example, there are many
>  issued to divisions of LA POSTE).
> - Exclude certificates that expire on or before 2019-08-31, as those
>  will be unaffected by a September distrust.
> - Exclude certificates issued after 2019-05-17 (today), as Certinomis
>  should be aware of the likely distrust by tonight.
>

To clarify, this is intended as an improvement to the statistics Andrew
Ayer posted at https://bugzilla.mozilla.org/show_bug.cgi?id=1552374#c1 .

I am posting it in the thread to increase the chance someone with the
skills will see it and run the query.

I expect it to show a surprisingly small number of certificate holders,
indicating the real impact of revocation to be much smaller than one
would expect from the raw count of 1381 certificates.

This in turn could inform the mitigations or other proactive steps to
reduce relying party (user) impact of distrust, if distrust is accepted
by Kathleen.

[Jakob Bohm]

On 17/05/2019 07:21, Jakob Bohm wrote:

> On 17/05/2019 01:39, Wayne Thayer wrote:
>> On Thu, May 16, 2019 at 4:23 PM Wayne Thayer <wth...@mozilla.com> wrote:
>>
>> I will soon file a bug requesting removal of the “Certinomis - Root CA”
>>> from NSS.
>>>
>>
>> This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374
>>
>
> To more accurately assess the impact of distrust, maybe someone with
> better crt.sh skills than me should produce a list of current
> certificates filtered as follows:
>
> - Sort by O= (organization), thus grouping together certificates that
>  were issued to the same organization (for example, there are many
>  issued to divisions of LA POSTE).
> - Exclude certificates that expire on or before 2019-08-31, as those
>  will be unaffected by a September distrust.
> - Exclude certificates issued after 2019-05-17 (today), as Certinomis
>  should be aware of the likely distrust by tonight.
>

To clarify, this is intended as an improvement to the statistics Andrew
Ayer posted at https://bugzilla.mozilla.org/show_bug.cgi?id=1552374#c1 .

I am posting it in the thread to increase the chance someone with the
skills will see it and run the query.

I expect it to show a surprisingly small number of certificate holders,
indicating the real impact of revocation to be much smaller than one
would expect from the raw count of 1381 certificates.

This in turn could inform the mitigations or other proactive steps to
reduce relying party (user) impact of distrust, if distrust is accepted
by Kathleen.

[Jakob Bohm]

On 17/05/2019 07:21, Jakob Bohm wrote:

> On 17/05/2019 01:39, Wayne Thayer wrote:
>> On Thu, May 16, 2019 at 4:23 PM Wayne Thayer <wth...@mozilla.com> wrote:
>>
>> I will soon file a bug requesting removal of the “Certinomis - Root CA”
>>> from NSS.
>>>
>>
>> This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374
>>
>
> To more accurately assess the impact of distrust, maybe someone with
> better crt.sh skills than me should produce a list of current
> certificates filtered as follows:
>
> - Sort by O= (organization), thus grouping together certificates that
>  were issued to the same organization (for example, there are many
>  issued to divisions of LA POSTE).
> - Exclude certificates that expire on or before 2019-08-31, as those
>  will be unaffected by a September distrust.
> - Exclude certificates issued after 2019-05-17 (today), as Certinomis
>  should be aware of the likely distrust by tonight.
>

To clarify, this is intended as an improvement to the statistics Andrew
Ayer posted at https://bugzilla.mozilla.org/show_bug.cgi?id=1552374#c1 .

I am posting it in the thread to increase the chance someone with the
skills will see it and run the query.

I expect it to show a surprisingly small number of certificate holders,
indicating the real impact of revocation to be much smaller than one
would expect from the raw count of 1381 certificates.

This in turn could inform the mitigations or other proactive steps to
reduce relying party (user) impact of distrust, if distrust is accepted
by Kathleen.

[Kathleen Wilson]

Thank you to Wayne and all of you who have investigated concerns about
the recent activities and operations of the CA Certinomis. I have
appreciated the thoughtful consideration that you have put into the
investigation and discussion.

I approved Bugzilla Bug #1552374, for the removal of the following root
certificate in NSS 3.45 and Firefox 69 [1].

Common Name: Certinomis - Root CA
SHA-1 Fingerprint: 9D70BB01A5A4A018112EF71C01B932C534E788A8
SHA-256 Fingerprint:
2A99F5BC1174B73CBB1D620884E01C34E51CCB3978DA125F0E33268883BF4158
Trust Bits: Websites
This root is *not* enabled for EV treatment

As Wayne previously explained[2], Certinomis may apply for inclusion of
a new root certificate, and the new root certificate may be cross-signed
by a currently included CA under certain conditions.

Thanks,
Kathleen

[1] https://wiki.mozilla.org/Release_Management/Calendar
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/rmU311hOIIc/oYuxQJbEAQAJ

[Hanno Böck]

Hi,

I just saw this on twitter:
https://twitter.com/sam280/status/1133008218677022722


And later in the thread:
https://twitter.com/sam280/status/1133112699385257985

The first tweet points out that Certinomis seems to use wrong OIDs in
their certs (quote "Of course the first invalid #PSD2 #QWAC had to come
from Certinomis... guys, the entire PSD2 roles OID arc is not meant to
be included in the list of certificate policies"). I don't know what
PSD2 and QWAC means, I'll leave it to others to interpret how big of an
issue this is.

The second tweet points to a cert issued for an unregistered domain:
https://crt.sh/?id=1514142478

That obviously seems like a big deal. (Cert issued 2 days ago, so I
believe it's unlikely that this domain existed at the point this cert
was generated.)

I understand the removal of Certinomis from NSS is already decided, but
maybe these incidents justify some acceleration.


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Nick Lamb]

PSD2 is the Payment Services Directive 2 a Directive from the European Union. Directives aren't legislation per se, but tell the member states to write their own legislation to achieve some agreed outcome. Many things you think of as EU laws are actually Directives, as a citizen the broad effect of a Directive should be pretty similar everywhere in the EU but implementation details very a lot.

AIUI PSD2 has numerous goals following on from the previous successful Payment Services Directive, but they did once again get into the game of defining what X.509 certificates should mean and how issuers should validate information. So they've got themselves an OID arc for new policy OIDs.

If these OIDs are used in certs in the Web PKI then such certificates would need to obey both sets of rules, but as a relying party I can't say I care about the EU rules at all until I see some clear benefit, whereas the benefit of rules from Mozilla and CA/B forum is already clear.

If they shove an valid but nonsensical policy OID into a cert I don't know what Mozilla policy about that would be, but certainly the browser and common TLS clients will just ignore it altogether.

[Ryan Sleevi]

On Tue, May 28, 2019 at 1:03 PM Nick Lamb via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> If they shove an valid but nonsensical policy OID into a cert I don't know
> what Mozilla policy about that would be, but certainly the browser and
> common TLS clients will just ignore it altogether.
>

The relationship of such issues has been discussed in the past, in the
context of T-Systems (e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=1498463 and
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/x3s3CSKdIlY/o-oBBD7eAgAJ
)