Closed Bug 1580525 Opened 2 years ago Closed 2 years ago

D-TRUST: Delayed revocation of EV certificates

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: enrico.entschew, Assigned: enrico.entschew)

Details

(Whiteboard: [ca-compliance] [delayed-revocation-leaf])

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:
https://bugzilla.mozilla.org/show_bug.cgi?id=1567588#c7

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.

Type: defect → task
Summary: Delayed revocation of EV certificates → D-TRUST: Delayed revocation of EV certificates
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee: wthayer → enrico.entschew
Whiteboard: [ca-compliance]

A quick update on D-TRUST’s remediation plan:

  1. Active communication with D-TRUST’s customers is still ongoing. We expect the process to be finished by the end of October 2019.
  2. To increase awareness we will keep our customers informed at least once every six months about the rules and requirements of their certificates.
  3. Currently we are preparing a whitepaper as a guidance for our customers to choose the right certificate service fulfilling their needs and requirements completely.

Next response to the community by EOD, October 30th latest.

Quick update:
As already announced, we have an ongoing intensive communication process with our customers in order to address even more clearly the need for them to be prepared for a short-term certificate exchange. These are the completed actions so far:

All customers were contacted by email to achieve better acceptance of short term revocations according to the baseline requirements. A notice with the same content was published on our website (https://www.bundesdruckerei.de/en/SSL-and-TLS-certificates). In the future, we will inform our customers continuously, every six months, that they must support a short-term certificate exchange.

We also directly approached/ addressed customers who we suspect are using certificates in their infrastructures in a way that makes short-term revocation difficult and offered to advise them on certificate agility.

D-Trust also takes the incident as an opportunity to revise its internal processes. This is to minimize any possible influence of the certificate owner on the revocation time. For this purpose, process descriptions were revised and decision-making processes simplified.

The communication process with our customers has once again confirmed that some of our customers have difficulties in selecting the appropriate certificate product for their security requirements. This will be reflected in the whitepaper we are currently preparing. Situations and appropriate solutions based on certificates will be described as examples. We expect to publish the whitepaper by the end of this year. We will also make the whitepaper available to the community afterwards.

The next report to the community will be on 30.11.2019.

Enrico: Do you have an update here?

Flags: needinfo?(enrico.entschew)
Whiteboard: [ca-compliance] → [ca-compliance] [delayed-revocation-leaf]

Ryan: We are working on the whitepaper. We still expect it to be completed by the end of the year.

Flags: needinfo?(enrico.entschew)

Just a quick update: Currently the white paper is under review. We expect the publication in January 2020.

My apologies for the delayed update.

I’m happy to tell you that we already published the whitepaper at the beginning of this year. The English version can be found here (direct link): https://www.bundesdruckerei.de/system/files/dokumente/pdf/Guide-for-using-TLS-certificates.pdf or here (over our website): https://www.bundesdruckerei.de/en/SSL-and-TLS-certificates

A German version is also available, which was published first.

Enrico: Thank you for the update and the link to the whitepaper, which I have reviewed.

It appears that all questions have been answered and remediation is complete.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.