1573490 - PKIoverheid: CIBG insufficient serial number entropy

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Jorik van 't Hof]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

As indicated in bug (#1535871) this separate bug is filed regarding the issue of the 64-bit serial number of TLS certificates issued by CIBG as originally reported on MDSP (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/r9C_Mh9Du_g).

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
   3/8/2019 12.30, due to reviewing discussions in mozilla.dev.security.policy.
2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
   (all times are in UTC +1)
   30/9/2016 Ballot 364 came into effect. The CP of Logius PKIoverheid already stipulated the use of 64-bit serial numbers and as such, no change was deemed necessary to the CP. Our CP (Programme of Requirements) is a baseline document, stating the absolute minimum. This ballot predates the incident which PKIoverheid had about serial numbers with one of her other TSP's in 2017. Measures which were taken then didn't apply retroactively.

3/8/2019 12.30 While reading MSDP the Logius PKIoverheid started an investigation if it was possible that her TSP's had this implementation/interpretation issue

3/8/2019 13.15 Logius PKIoverheid suspects that this issue could potentially impact one or more of the TSP’s under PKIoverheid. Logius PKIoverheid asked the TSP KPN to launch an investigation if said issue was applicable to certificates issued by KPN.

3/11/2019 09:53 Logius PKIoverheid asked KPN for an update following statements from both Google and Mozilla representatives stating that in their view the matter as reported by several other CAs violates the BRG.

3/15/2019 09:39 CIBG indicates that the same issue that plagued KPN also affects them. This means that the certificates issued from October 2016 onwards are also in scope for the 64-bit entropy issue. First indications are that this affects a maximum of 6000 certificates, later revised to ~4200.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
   CIBG switched over to a private CA for issuing TLS certificates in December 2017. The issuing CA will expire in March 2020.
4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
   CIBG issues the TLS certificates for use in machine-to-machine communications between organizations in the Dutch Healthcare system. Although not intended to be used for TLS connections of public websites some of them are (re)used as such. Taking earlier dates into account the amount of remaining, valid certificates which are affected by this issue is small
5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
   Will post the list soon. Seeing that almost all certificates were issued before CT logging became mandatory we’ll have to log those first or post a CSV here.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   The cause in this case was the same as in bug 1535871. For completeness, I will restate what we wrote in there (and on MDSP):
   As stated in the timeline, the Programme of Requirements (PoR, CP) PKIoverheid already stipulated the use of a serial number with a 64-bit length. When ballot 264 went into effect, both the PA and the TSPs determined that PKIoverheid was already compliant. The conversations about the underlying thoughts or intent of the ballot were seen at the time but not taken into account when deciding the final impact. The final text of the ballot after it was passed was used to check if implementations were correct. In this case the TSP also relied on the configuration of EJBCA and assumed that this was the correct implementation (again, also based on their interpretation of the text).
7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
   CIBG has already stopped issuing publicly trusted TLS certificates and all remaining valid TLS certificates will be left to expire, seeing the short lifespan still remaining.

Comment 1

[Wayne Thayer]

Jorik: Please confirm the number of affected certificates and the date on which the last will expire.

Comment 2

[Jorik van 't Hof]

Wayne,

The last certificate will expire on March 20, 2020.

Kind regards,

Jorik van 't Hof

Comment 3

[Ryan Sleevi]

Jorik: Thanks for the update.

I'm not sure I understand the delay between detection (2019-03-15) and this report, especially considering PKIOverheid was so responsive and comprehensive in its initial detection and reporting in Bug 1535871. Could you help understand the timeline gap here? Did I miss a thread or a related discussion that helps contextualize it?

Comment 4

[Ryan Sleevi]

Jorik: Any updates?

Comment 5

[Jochem van den Berge]

Hello Ryan,

As for the response to the question asked in comment 3, please find our answer as part of comment 2 in bug 1578809, the relevant part of which I'll quote below:

Unfortunately, this was an oversight. In the bug 1535871 we did indicate that the intention was to file a separate bug for CIBG. Unfortunately, due to the fact that the original intent was to let all CIBG certificates expire naturally and that the (initial) focus for Logius was on replacement of the intermediate CAs and KPN end-user certs this didn’t have the appropriate level of attention of Logius.

Regards,

Jochem

Comment 6

[Ryan Sleevi]

Wayne: I think Comment 2 of Bug 1578809 provides a comprehensive explanation of the issue, and a remediation plan of action.

Comment 7

[Wayne Thayer]

We are still awaiting the complete list of affected certificates that was promised "soon" in the description (unless they were included in https://bugzilla.mozilla.org/show_bug.cgi?id=1535871#c15)

PKIOverheid has chosen not to revoke these certificates, so this bug will remain open until the last one expires in March 2020.

Comment 8

[Ryan Sleevi]

Wayne: Thanks for pointing that out. I may have misunderstood, but I understood https://bugzilla.mozilla.org/show_bug.cgi?id=1578809#c0 to be stating that all of CIBG's certificates will be revoked October 1, instead of expiring by March 2020, which would address this issue.

Comment 9

[Jochem van den Berge]

Attachment: CIBG_total_list_64-bit_serial_number_issue.txt

Hello Wayne,

After consulting with our legal departement the outcome was that sharing the full certificate data is indeed impossible because of GDPR constraints. We can however share a list of serial numbers (please find those attached to this comment). The total amount of certificates in scope has been determined at 4129 certificates.

As Ryan indicated in comment 8, all of these certificates are also in scope of bug 1578809 and as such will be revoked (or have already expired).

Please let me know if you have any more questions.

Regards,

Jochem

Comment 10

[Jorik van 't Hof]

Attachment: CIBG.txt

Hello Wayne,

I’m happy to report that CIBG was successful in revoking the affected certificates. For 24 certificates CIBG wasn’t able to replace and revoke due to there use in critical healthcare systems before October 1 (common names are attached to this comment). For these the subscribers have asked for an extension till October 8 at the latest.

Regards,

Jorik

Comment 11

[Jorik van 't Hof]

Hello Wayne,

As mentioned above, all certificates have been revoked.

Please let me know if you have any additional questions.

Regards,

Jorik

Comment 12

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.