SECOM: Ambiguity on KeyUsage with ECC public key

SECOM reported a problem they discovered during a self-audit involving ECDSA certificates whose Key Usage included “key encipherment” and “data encryption,” which SECOM stated does not make sense. SECOM said the issue was found on 2019/02/05, and that 31 valid certificates were identified as having the problem. After discussion, SECOM decided to revoke the certificates by CA discretion on 2019/02/08, and they issued an intermediate CA certificate on 2019/03/15 that corrected the Key Usage; SECOM also stated that issuance of the problematic certificates was stopped at that time. SECOM reported revoking the affected certificates (30 between 2019/03/15 and 2019/04/24, and the remaining 4 on 2019/05/08), then revoking the intermediate CA certificate on 2019/05/13. SECOM also posted a question to the mozilla.dev.security.policy forum and stated that the RFC ambiguity was acknowledged, with an Internet Draft being proposed to correct the relevant RFC text. In the thread, reviewers agreed the appropriate Bugzilla resolution was RESOLVED INVALID, and SECOM later reported a Zlint GitHub issue for detection improvements at https://github.com/zmap/zlint/issues/291. The bug is currently marked RESOLVED with resolution INVALID.

1. 2019-02-05 SECOM self-audit identified 31 valid ECDSA certificates with Key Usage values SECOM considered inappropriate.
2. 2019-03-15 SECOM issued an intermediate CA certificate correcting the Key Usage and stopped issuing the problematic certificates.
3. 2019-05-13 SECOM revoked the intermediate CA certificate after revoking all affected end-entity certificates.

1. 2019-06-20 Secom representative — Hisashi Kamo described the self-audit findings, SECOM’s revocation and reissuance actions, and noted the RFC ambiguity discussion and related links.
2. 2019-07-05 Fastly representative — Wayne Thayer asked whether SECOM modified its linting tool and whether changes were submitted to Zlint maintainers.
3. 2019-07-12 Secom representative — Jinta Nakamura responded that an IETF document is being proposed, that SECOM had not reported to linting maintainers yet due to lack of consensus, and that SECOM’s linting tools (cablint, certlint, x509lint) detected the issue.
4. 2019-07-14 Fastly representative — Wayne Thayer agreed the case should be RESOLVED INVALID and asked if there were further comments or questions.
5. 2019-07-15 Community commenter — Ryan Sleevi agreed and praised SECOM’s proactive identification, unilateral revocation, and community engagement to resolve the ambiguity.
6. 2019-07-19 Secom representative — Jinta Nakamura stated SECOM reported the issue to Zlint’s GitHub and provided the link to the Zlint issue.