I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track this issue.
Apple has also submitted the following bug for this issue listing a large number of impacted certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=1533655 - Wayne On Thu, Mar 7, 2019 at 7:14 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Practical question: > > How does the update to CABLint/Zlint work? > > If a CA is choosing to issue certs with serial numbers with exactly 64 bits > of entropy, approximately 50% of the time there will be a certificate with > an 8 byte encoding of the serial number, as the high-order bit of the first > byte will be 0. Approximately the other 50% of the time, the high-order > bit of the 64 bits of data will be a 1 and the value will therefore be > encoded as 9 bytes, the value of the first byte being 0x00. > > As linters work on one document [certificate] at a time, how can the linter > identify with certainty that the 8-byte encoded value represents less than > 64 bits of entropy? Approximately half of the time, a strict 64-bit random > value would encode as a mere 8 bytes. > > On Thu, Mar 7, 2019 at 8:01 PM Daymion Reynolds via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit > certificate > > Serial Number issue. We have identified a significant quantity of > > certificates (> 1.8million) not meeting the 64bit serial number > > requirement. We are still performing accounting so certificate quantity > is > > expected to change before we finalize the report. > > > > 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. > > > > 9pm 3/6/2019 AZ Time, due to reviewing a discussion 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. > > > > 9pm 3/6/2019 AZ Time, identified a hot issue with serial numbers in > > Mozilla group. > > 10am 3/7/2019 AZ Time, identified the issue was pervasive, and identified > > root cause. > > 6:30pm 3/7/2019 AZ Time, fix deployed to production to correct the serial > > number issue. > > We are still quantifying and classifying the certificate scope of impact. > > > > 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. > > > > We have deployed a fix to the issue, and are no longer issuing > > certificates with the defect. > > > > 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. > > > > Issue was introduced with a change in 2016. Impacted certificates still > > being aggregated. Will update with information and timeline on issue > > closure. > > > > 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. > > > > Still being aggregated. Will update with certificate information on issue > > closure. > > > > 6. Explanation about how and why the mistakes were made or bugs > > introduced, and how they avoided detection until now. > > > > Ambiguity in language led to different interpretations of BR 7.1. It was > > believed a unsigned 64bit integer was sufficient to satisfy the new > > requirement. Additionally, industry tools like CABLint/ZLint were not > > catching this issue, which provided a false sense of compliance. We are > > submitting CABLint/Zlint updates as part of the fix. > > > > 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. > > > > Defect has been resolved, we are also updating linting tools > > (CABLint/Zlint) and upstreaming to patch for other peoples usage. > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
