User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Steps to reproduce:
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.
2019-07-26, 09:00 UTC: We became aware that numerous customers (47 out of 89 certificates), who were affected by https://bugzilla.mozilla.org/show_bug.cgi?id=1567588 were not able to replace the affected certificates within the given timeframe with new compliant certificates we provided. We performed a risk assessment which resulted in the decision not to revoke the 47 remaining certificates due to urgent customer needs (obligations on availability). The deadline for revoking the affected certificates would have been 2019-07-27, 11:50 UTC.
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.
2019-07-26, 16:00 UTC: Update on https://bugzilla.mozilla.org/show_bug.cgi?id=1567588#c5 that 42 out of 89 certificates were already revoked and 47 certificates remaining could not be revoked within the given timeframe due to urgent customer needs and risks.
2019-08-02, 20:50 UTC: Update on https://bugzilla.mozilla.org/show_bug.cgi?id=1567588#c7 that still 23 out of 89 certificates could not be revoked due to urgent customer needs and risks. For each of the 47 certificates with delayed revocation an explanatory statement and a scheduled revocation time was disclosed to the community.
2019-08-09, 16:10 UTC: Update on https://bugzilla.mozilla.org/show_bug.cgi?id=1567588#c9 that 80 out of 89 affected certificates were revoked and the scheduled revocation times for the remaining certificates are still on track.
2019-08-30, 12:28 UTC: Update on https://bugzilla.mozilla.org/show_bug.cgi?id=1567588#c10 that 89 out of 89 affected certificates were revoked.
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.
Not applicable in this special case.
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.
Problem: delaying revocation
Number of affected certificates: 47
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.
All affected certificates can be found here:
6.) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
We are aware of retail customers having had difficulties of replacing certificates in a timely manner. This is not limited to the known challenge of certificate pinning as discussed here (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/_k2Nvv6OD7U), but also not having the resources or knowledge at hand due to vacation or sick leave. We have already informed our customers that they have to accept enforced revocation within 5 days, however we have experienced some negative feedback towards short-term revocation if the reason is not justified through security issues.
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.
How D-TRUST plans to avoid delayed revocations in the future?
We are now addressing our customers which we suspect using the certificates for pinning purposes and recommending more suitable products. This should be completed by the end of October. If necessary, we will offer them additional advice in the implementation of pinning according to good practice.
In the past we have had correspondence with customers to achieve better acceptance of short term revocations according to the baseline requirements. We increased our communication to recall these facts since August. We will proactively contact customers in order to keep them aware of short term revocation of certificates.
As we already mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1567588#c13 we made the major strategic decision to discontinue this retail business and to concentrate on business performed via our managed PKI platform which offers the ability to retrieve certificates in an automated manner. We are convinced that customers using this managed PKI platform have a better ability of revocation within the given timeframe if necessary. This gives us the opportunity to carry out a proper revocation without bringing the customer into unreasonable difficulties.