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.
When performing self-compliance check on our Trusted Root based on discussions in mozilla.dev.security.policy with similar issues.
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.
2019-03-18: Atos TC self-assessment on certificates issued from Atos Trusted Root CAs. The issued certificates have effective serial number lengths of 63 Bit due to a feature of the used EJBCA (64 bit is configured for serial number length, but the highest bit is always set to zero to avoid misinterpreting as a negative signed long integer value.
2019-03-18: Atos TC installed PKI software upgrade on development environment and offline root-ca environment
2019-03-28: Atos TC Issued new Server-CA to replace Atos TrustedRoot Server-CA 2017 using offline root-ca environment
2019-03-29: Atos TC started software upgrade of EJBCA Version in production environment and changed CA Serial Number Octet Size to 12 for certificates issued by Atos TrustedRoot Server-CA 2019 and started certificate replacement planning.
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.
Atos TC issues new server certificates with certificate serial number length of 96 bit with entropy of 95 bit (highest bit is always zero). Issuance of server certificates with wrong entropie is stopped.
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.
The following certificates are effected:
Atos TrustedRoot Server-CA 2017:
Atos TrustedRoot Server-CA 2013:
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.
The effected certificates are listed at:
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
There was a misinterpretation of BR 7.1. It was believed a unsigned 64 bit integer was sufficient to satisfy the requirement. Atos TC has used the tools like zlint, CA/B Forum lint and X.509 lint for compliance checking, but the issue was not detected.
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.
2019-04-01: Information to certificate holder about planned certificate renewal process.
2019-05-30: Renewal of all effected server certificates
2019-05-31: Revocation of all effected server certificates