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
