1667518 - QuoVadis: Incorrect keyUsage for ECC certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Stephen Davidson]

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.

In monitoring Bugzilla filings, QuoVadis noted the Entrust bug filed this evening https://bugzilla.mozilla.org/show_bug.cgi?id=1667448 related to the use of keyEncipherment keyUsage in ECC certificates.

Sept 26 03:00 UTC - QuoVadis has identified that it issued a small number of similar certificates in 2019. QuoVadis will file a report following an investigation to identify all such certificates, confirm their revocation, and describe root causes and remediation.

Comment 1

[Stephen Davidson]

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.

Sept 26 03:00 UTC - QuoVadis identified that it issued a small number of similar certificates in 2019.
Sept 26 20:00 UTC - Investigation completed; CA policies confirmed; nine valid problem certificates identified.
Sept 26 21:00 UTC - Subscribers informed, with revocation scheduled by Oct 1, 20:00 UTC at latest.

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.

QuoVadis stopped issuing such certificates in 2019. It has been confirmed that existing certificate profiles do not allow this issue.

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.

The certificates in question are ECC TLS certificates with a keyUsage value of keyEncipherment.
The certificates were issued between February and November 2019.

5. The complete certificate data for the problematic certificates.

The nine certificates will be revoked by Oct 1, 20:00 UTC. SHA-256 fingerprints:
2378e03fefd8d5e17b1a652e9d25aaee6eea1362dd540b30306cd0325ae412d5
f725e25e7b2eaa80eb29e768ea9588621206bbadf4aaa85ce0f27f8dc3cc46b1
be8999efb12bc0079be8eaba53b01fefadf84480a4f9ef3bed817ad1aa71ae22
3ea10489799fe0924c4877940095aa53a4896cd914c101fd7e725d878d4a7a6a
05e534feb457f7a6a6dff42ca06e9e9a1670fe32e4f92a10ee0cc8f3a15d241c
88acb4d1b665e066620e5bddce445a7c007630f5d9c5bd9f31369498050b7f25
4c3f5d8e56300c5aa38eba2d0560aa4213052aa5a5ab87f9909b8773c6162d7d
6532c5b8167bc06d28e8a93b182d2b012fc9d64f16bb141573c4f99efb32a42b
0cc42e5ea2830630bfaff73495a3de69cc980f703002ef7b975f78754080ebfd

A postmortem is under way and QuoVadis will provide a further update on (6) how the mistakes were introduced, how they avoided detection, and (7) steps that have been taken.

Comment 2

[Mathew Hodson]

I think the timeline leaves out important dates such as when the certificates were issued and when the change happened to stop issuing certificates with this problem.

Also dates for the work to update RFC 5480 https://tools.ietf.org/html/draft-turner-5480-ku-clarifications-00 from bug 1560234.

Comment 3

[Stephen Davidson]

Confirming that the nine affected certificates have been revoked. Further update on items 6 and 7 to follow.

Comment 4

[Stephen Davidson]

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

Only a small number of certificates (~15) were created with this issue: 1 in 2018 and the remainder between Feb and November 2019.

In Feb 2020, QuoVadis became aware of the work being done on https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-03. A review was made of certificate profiles and a correction was made. However, all of the then-existing certificates were not revoked in part because the rfc errata was draft and in part because zLint labelled the certificates with a warning, not an error.

In light of other facts now known, such as discussions occurring regarding zLint in GitHub, QuoVadis would have chosen revocation.

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.

The process of integrating QuoVadis into DigiCert is ongoing, with the steady migration onto DigiCert’s processes, automation tools, and technology platforms over the past year.

Many improvements have been described in previous filings including the adoption of DigiCert validation methodologies and tools, blocking of keyCompromise keys, and automated keyCompromise reporting to name a few.

In summer of 2020 a detailed review was made of certificate profiles in use at QuoVadis; this problematic profile was no longer in use so was not identified.

One significant improvement is the present adoption of DigiCert’s significant investment in “clean sheet” research into compliant templates for both CAs and end entity certificates. QuoVadis believes this will greatly reduce the instance of noncompliant certificate profiles in future, in particular in the area of keyUsage and ExtendedKeyUsage.

QuoVadis will implement a periodic review of other zLint messages (“verbose mode”) in its compliance/internal audit activities.

Comment 5

[Ryan Sleevi]

Ben: I don't have any follow-up questions here.

I'm quite happy with the cause of this incident report being noticed (monitoring CA incidents), the examination of past issuance, the correction and the context to the overall set of remediations being put into play here. This is exactly the kind of thing that these incident reports facilitate, and it's great to see Quovadis/DigiCert be proactive rather than reactive here.

Comment 6

[Ben Wilson]

I'll schedule this to be closed on 30-October-2020 unless there is additional discussion needed.