Embedding improper SCTs into OCSP Responses (SwissSign) 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.
On November 16th, 2017 SwissSign was informed by Brendan McMillion, Cloudflare, about “Embedding improper SCTs into OCSP Responses” and the discussion in https://groups.google.com/forum/#!msg/certificate-transparency/Ydoetykx3UA/mZeKOOYhBAAJ regarding this issue. 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. November 16th, 2017 SwissSign has validated this problem (Cloudflare and Chrome / Chromium) and we can confirm it. In addition, we analyzed the combination of apache Webserver and Chrome / Chromium and discovered that this combination worked well and did not show invalid SCTs in Chrome. The analysis of the underlying cause showed that currently all SCTs of a pre-certificate and SCTs of a certificate are stored in the same database and our OCSP-responder uses this database. So our OCSP responder also embeds pre-certificate SCTs, if they are present. 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. This problem is not related to a misuse of a certificate or a certificate format error. Therefore, we will not stop issuing certificates. 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. Since the introduction of the CT pre-certificates on March 20th, 2017, we have identified 120 potential candidates for the problem description which must now be analyzed in detail. Most of our customers order their SSL certificates without pre-certificates since SwissSign requires the use of OCSP stapling in the subscriber agreement. Up to now we are only aware of one certificate with this problem description: 3B426A5F18498B1F79E2CF54CBBC03758BAD775E 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. The affected certificate is logged in the CT Log. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The OCSP-stapling method was our first CT-Log implementation. Later we added the X.509v3 extension method. Our test suite regarding the “X.509v3 extension method” was focused on the correct certificate format. In our test scenarios with the apache web-server the reported error from Cloudflare did not occur. 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. Our development team is analyzing the solution and we are convinced that by release 4.10 at the latest (production rollout January 13th, 2018) this problem will be solved. We are currently assessing a workaround for the impacted customer and seeing if it would be possible to apply it before the release. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
