1667448 - Entrust: Incorrect keyUsage for ECC certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Bruce Morton]

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:

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 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.

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.

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.

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.

Under investigation.

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.

ECC SSL certificate with a keyUsage value of keyEncipherment.

5. The complete certificate data for the problematic certificates.

https://crt.sh/?id=3426033550

6. 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.

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.

Will follow up with steps we are taking to resolve this situation and mitigate repetition in the future.

Comment 1

[Ryan Sleevi]

From the timeline, this seems to overlook issues like Bug 1647468 , or further back, Bug 1560234, as well as discussion within the IETF for the past year. Could you help factor these in to your timeline?

Comment 2

[Bruce Morton]

(In reply to Ryan Sleevi from comment #1)

From the timeline, this seems to overlook issues like Bug 1647468 , or further back, Bug 1560234, as well as discussion within the IETF for the past year. Could you help factor these in to your timeline?

I don't think that the issues referenced apply to our issue. We were aware of the requirement; however, I cannot put a specific date on when we understood the requirement. Our policy was correct when we created CAs to issue certificate with ECC keys in April 2016. This policy was also implemented in our post issuance linting software.

The current issue is not a misunderstanding of the requirement, but that there is a bug in the enrollment software which sent a certificate request with an ECC key to a CA which was configured to issue subscriber certificates with an RSA key. This issue is currently being investigate and we will post a plan for resolution.

We also planned to address that the issue was not detected with zlint. We found https://github.com/zmap/zlint/pull/479/commits/90dbcc6b3f5623441b09754e219bfb4e71ce9ce0 and https://github.com/zmap/zlint/issues/454. We support this change. However, if the change is not made available, we will implement in our pre-issuance linting.

More details to follow.

Comment 3

[Ryan Sleevi]

(In reply to Bruce Morton from comment #2)

(In reply to Ryan Sleevi from comment #1)

From the timeline, this seems to overlook issues like Bug 1647468 , or further back, Bug 1560234, as well as discussion within the IETF for the past year. Could you help factor these in to your timeline?

I don't think that the issues referenced apply to our issue.

I'm not sure I understand. They appear to be identical in outcome, and it seems like you're just saying it's different in root cause. Am I misunderstanding something?

Comment 4

[Bruce Morton]

(In reply to Ryan Sleevi from comment #3)

(In reply to Bruce Morton from comment #2)

(In reply to Ryan Sleevi from comment #1)

From the timeline, this seems to overlook issues like Bug 1647468 , or further back, Bug 1560234, as well as discussion within the IETF for the past year. Could you help factor these in to your timeline?

I don't think that the issues referenced apply to our issue.

I'm not sure I understand. They appear to be identical in outcome, and it seems like you're just saying it's different in root cause. Am I misunderstanding something?

I'm not understanding either. Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1647468 does not state why they made the error. It does not say that they knew the requirement or did not know the requirement. They even say that "the certificate wrongly contains the key usage “keyEncipherment” instead of “keyAgreement“." I do not believe that this is a correct requirement.

In Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1560234 they state "we realized our lack of understanding about the ECC certificate." So this CA did not understand that the ECC certificate should meet the intent of RFC 5480.

In our case we understood and implemented the RFC 5480 requirement.

Note that Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1647468 could have advised that zlint does not report the issue as an error. This would not have been discovered on first read of the bug as this information was not provided.

Comment 5

[Ryan Sleevi]

Thanks Bruce, that's helpful at least to understand the disconnect.

I think the approach I was hoping for, for all CAs, is that:

• An incident is reported by another CA
• The (non-affected) CA looks at:
  • The resulting misissuance
  • The root causes
  • The mitigations the CA is proposing/applying
• The (non-affected) CA examines their own system:
  • Is such a misissuance possible (independent of root causes)?
    • What are the controls to prevent this?
    • How are they tested?
    • Have they been reviewed to make sure documentation and production are aligned?
  • Are there variants of the root cause that can affect the CA?
  • Does the non-affected CA have similar mitigations in place?

Going to these other issues, it seems like had an examination like the above been done, then even though the supposed root causes (lack of awareness) are different, the question would have been: "Would our pre-issuance systems prevent this?", which would have determined that no, not yet. The distinction between keyAgreement and keyEncipherment is, to me at least, largely irrelevant; the issue at play here is a disallowed key usage (which does seem identical between these issues)

In your original report, you said:

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.

So this is why I bring up the other issues. If you had, say, pre-issuance linting, presumably the attempt to use the Retail OV RSA profile with an ECC key would have flagged the pre-issuance lint, which would have discovered that the Retail profiles were sending everything to the RSA profile (at least, as I understand it) and that ECC keys weren't getting blocked.

Does that at least help better explain the relation and relevance of these other issues? The keyEncipherment vs keyAgreement seems largely moot, and this is more generally about using those other incidents (of the keyUsage not matching the subscriber key) to make sure that sufficient controls were in place to ensure that keyUsage, well, matched subscriber keys.

Do you have a timline for a plan for remediation, even an initial WIP one?

Comment 6

[Bruce Morton]

To re-state, SSL certificates using ECC keys are not supported in our Retail mode. However, we did find path where the Retail service does not reject a CSR with an ECC key. Since the Retail service only uses CAs which have certificate profiles based on an RSA key, the CA signed a certificate with an ECC key and the incorrect key usage. This error is being corrected.

In addition, the pre-issue linting which uses zlint, did not provide an error and block certificate issuance. However, zlint does provide a Notice that the key usage is incorrect. We will update zlint to the latest version and update our code to provide an error, which will mitigate this error in the future.

Our timeline to have this incident remediated is no later than 30 October 2020.

Comment 7

[Bruce Morton]

Effective 23 October 2020, zlint has been updated to the latest version and our pre-issuance linting code will provide an error and stop certificate issuance in the event that the key usage is incorrect in the future. We believe that all actions have been completed.

Comment 8

[Ben Wilson]

I'll close this bug on or about 30-Oct-2020 unless there are any other issues to be discussed.