1536082 - T-Systems: Insufficient serial number entropy

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Arnold Essing]

Attachment: 20190318-T-Systems.zip

1. How your CA first became aware of the problem, and the time and date.
   In the discussions over the inclusion of Dark Matter at the end of February this year, the problems with EJCBA and its default settings are described. Although we do not use EJCBA, we checked internally if we have a similar problem.

2. A timeline of the actions your CA took in response.
   2019-02-27: We became aware of a potential problem of some CAs with the entropy of serial numbers.
   2019-02-27 16:45 UTC: We completed the analysis of the serial number generation process for all our CAs that issued at least server certificates. All generated serial numbers already included the minimum value of 64-bit entropy some time before the BR effective date of September 30, 2016.
   2019-03-14 09:20 UTC: It was only during the observation of the various incident reports did we realized that the rules for generating serial numbers also apply to certificates with EKU e-mail protection instead of server authentication.
   2019-03-14 10:30 UTC: Start of the investigation of non-server certificate authorities, as these were not taken into account when analyzed on February 27, 2019.
   2019-03-14 10:35 UTC: A non-server Certificate Authority (TeleSec PKS CA 7:PN) violates a requirement as per Mozilla's Root Policy, Chapter 5.2.
   2019-03-14 13:11 UTC: We have stopped issuing non-server certificates from this CA.

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.
   Yes, we no longer issue non-server certificates with insufficient entropy in the serial numbers.

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.
   From February 28, 2017 until March 14, 2019, a total of 113,719 non server certificates were issued. There are 4,532 revoked/expired certificates. All affected certificates were generated and issued on smart cards.

5. The complete certificate data for the problematic certificates.
   Attached you will find a complete list of the SHA256 fingerprints. They are all non-server certificates. No CT.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   Since we already used compliant serial numbers for all CAs that also issued server certificates before September 30, 2016, we mistakenly overlooked the need for full 64-bit entropy as per the Mozilla Root Store Policy from February 28, 2017 for non-server certificates.
   Many thanks to Jeremy for pointing out this need in the Incident https://bugzilla.mozilla.org/show_bug.cgi?id=1533899

7. List of steps CA is taking to resolve the situation and ensure it will not be repeated.
   Starting March 15, 2019, we changed our internal processes for examining policy changes. Additional staff members are now being added to review the policy changes of the Root Store Program and the BR separately.
   Although these certificates violate the Mozilla root storage policy, we do not want to revoke the certificates. All certificates will be invalid or revoked latest on July 10, 2019.

Comment 1

[Arnold Essing]

Expansion to 2.)
2019-03-18 10:20 UTC: After further investigation a second non-server Certificate Authority (Deutsche Telekom AG Issuing CA 01 ) violates a requirement as per Mozilla's Root Policy, Chapter 5.2. This did not stand out on March 14, 2019, because this CA used 80 bit serial numbers and at first glance it looked OK. After further investigation, it showed that the entropy is also too low here. This CA has not issued any more certificates since April 18, 2018.

Expansion to 4.)
From February 28, 2017 until April 18, 2018, a total of 193,232 non-server certificates were issued from Deutsche Telekom AG Issuing CA 01. There are 125,482 revoked/expired certificates. All affected certificates were issued on smart cards.

Expansion to 5.)
Attached you will find the additional list of the SHA256 fingerprints. They are all non-server certificates. No CT.

Expansion to 7.)
The certificates from the „Deutsche Telekom AG Issuing CA 01“ are used within our company the Deutsche Telekom AG. Due to the low security risk we do not wish to revoke these non-server certificates.

Comment 2

[Arnold Essing]

Attachment: 20190325-T-Systems.zip

Comment 3

[Wayne Thayer]

(In reply to Arnold Essing from comment #1)

Expansion to 7.)
The certificates from the „Deutsche Telekom AG Issuing CA 01“ are used within our company the Deutsche Telekom AG. Due to the low security risk we do not wish to revoke these non-server certificates.

Arnold: in the incident report you stated " All certificates will be invalid or revoked latest on July 10, 2019." Does that still hold true? If not, when will all these certificates be revoked or expired?

Comment 4

[Arnold Essing]

Wayne, yes all issued certificates of „TeleSec PKS CA 7:PN“ will be invalid or revoked until July 10, 2019.
The last end-entity certificate of "Deutsche Telekom AG Issuing CA 01" expires on 17.04.2021.
The procedural expense of blocking and reissuing for the end user is very high due to the issuance on smart cards. There is also a high number of support requests expected. For the cooperation with our partners and providers, user certificates are stored in their systems, which would therefore have to be exchanged there in large numbers.
Since the key history on the smart card can only store a few keys, the early blocking leads to noticeable restrictions for the users when processing existing encrypted data and e-mails.
Since we do not see a security problem here, we do not wish to revoke the certificates of "Deutsche Telekom AG Issuing CA 01" for the above mentioned reasons.

Comment 5

[Ryan Sleevi]

Arnold: Wanting to make sure this is on your radar for this week to provide a status update on the completed revocation.

Comment 6

[Arnold Essing]

All issued certificates of „TeleSec PKS CA 7:PN“ are now invalid or revoked.

Comment 7

[Wayne Thayer]

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