User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Steps to reproduce:
- 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 25 September 2020, Entrust compliance team discovered an issue using post-issuance linting software where an ECC SSL certificate was issued with a keyUsage value of keyEncipherment.
We interpret the requirement as follows:
• BRs state the keyUsage for Subscriber certificate is optional.
• BRs state “All other fields and extensions MUST be set in accordance with RFC 5280.”
• RFC 5280 states “appropriate values for keyUsage extensions for particular algorithms are specified in [RFC3279], [RFC4055], and [RFC4491].
• RFC 3279 has been updated by RFC 5480
• RFC 5480 states “If the keyUsage extension is present in an End Entity (EE) certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, then any combination of the following values MAY be present: digitalSignature; nonRepudiation; and keyAgreement.
As such, RFC 5480 should apply to ECC SSL certificates issued in accordance with the BRs. This means that keyUsage value of keyEncipherment should not be included in Subscriber certificates which use an ECC key.
- 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.
Pe-2015: Certificate policy was created to adhere to the RFC 5480 requirements for keyUsage, as such, all ECC certificate profiles did not include the keyEncipherment value.
25 September 2020, 8:36 UTC: Entrust issued an ECC certificate with the keyUsage value of keyEncipherment
25 September 2020, 8:43 UTC: Post-issuance certificate linting sent a message of an error
25 September 2020, 8:50 UTC: Subscriber issued a request to revoke the certificate, which Entrust performed.
25 September 2020, 12:31 UTC: Investigation started to find the issue with the miss-issued certificate.
- 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.
- 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.
ECC SSL certificate with a keyUsage value of keyEncipherment.
- The complete certificate data for the problematic certificates.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The certificate management system is set to issue certificates in the Enterprise and Retail model. The PKI hierarchy is set with different CAs to issue certificates with RSA or ECC subscriber keys. The certificate profiles for this CAs are set to meet the requirements of the BRs, RFC 5280 and RFC 5480. The error occurred when a Retail OV ECC SSL certificate was issued from a OV RSA SSL CA. ECC keys are not supposed to be supported in the Retail model, but in this case the request was not blocked. Unfortunately, all SSL certificate requests in the Retail model are directed to CA configured to issue subscriber certificates with RSA keys.
This issue is currently under investigation.
- 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.
Will follow up with steps we are taking to resolve this situation and mitigate repetition in the future.