1560234 - SECOM: Ambiguity on KeyUsage with ECC public key

Assignee

Description

•

5 years ago

This Problem is about ECDSA certificates with “key encipherment” and “data encryption”, which does not make sense, and should be mississuance. However, such certificates seem to fit current trust program.
Although we assume this case is not within the scope of Mozilla trust program because of the following reasons, we believe this information may be helpful for other members, so we would like to share the information with you.

Problem with the certification authority applying for root inclusion.
The ambiguity of RFCs is the nature of the problem, but not the problem of the trust program.

The date described in this post is by JST.

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/02/05 The valid certificates with the problem were found by the self-audit.

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/02/05 31 valid certificates with the problem were found by the self-audit
2019/02/08 We discussed and considered that they were not seem to be violated against BR, but confirmed they were inappropriate in anyway, so decided to revoke them by CA’s discretion.
2019/03/15 We issued the intermediate CA certificate that corrected the Key Usage. At that time, the issuance of the certificates containing the problem was stopped, and we confirmed the 34 certificates were subject to be revocation.
2019/03/21 We posted the question in mozilla.dev.security.policy forum [1], and found out that this does not necessarily mean to be a violation, due to the ambiguous representation of the RFC.
Currently, Mr Ito(SECOM) has drafted the Internet Draft, and is making an effort to correct the corresponding part in RFC5480.

[1]https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/ito%7Csort:date/mozilla.dev.security.policy/vDhKG7T6sCM/gKwMGqrYAwAJ

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.

Since we reissued the intermediate CA certificate after stopped issuing the certificates with the problems on 2019/03/15, certificates with the problems are not going to be issued anymore.

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.

2018/07/12 We issued these certificates after this date.
2019/03/15 We issued the intermediate CA certificate that corrected the Key Usage.
2019/03/15～2019/04/24 We revoked the 30 certificates with the problem.
2019/05/08 We revoked the remaining 4 certificates with the problem and all certificates were revoked.
2019/05/13 We revoked the intermediate CA certificate.

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.

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

Before the ECC certificates were issued, the certificate profile creator made a research on the RFCs, but we realized our lack of understanding about the ECC certificate.

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.

On the benefit of the RFC correction and the subsequent modification of the linting tool, the alert system will be on by linting when attempting to issue such a problematic certificate in the future. Therefore, we believe that such mississuance will be prevented from now on.

Thank you for your consideration.

Best regards,
Hisashi Kamo

BugBot [:suhaib / :marco/ :calixte]

Updated

•

5 years ago

Status: UNCONFIRMED → ASSIGNED

Ever confirmed: true

Ryan Sleevi

Updated

•

5 years ago

Assignee: wthayer → h-kamo

Whiteboard: [ca-compliance]

Ryan Sleevi

Updated

•

5 years ago

Flags: needinfo?(wthayer)

Wayne Thayer

Comment 1

•

5 years ago

Kamo-san,

Thank you for the incident report and for the steps that your colleagues have taken to get the RFC updated. Has SECOM's linting tool been modified to detect this problem? If SECOM uses a publicly-available linting tool like Zlint, has the change been submitted to the maintainers (I have noticed that CABlint detects the problem but Zlint does not)

Flags: needinfo?(wthayer) → needinfo?(h-kamo)

Jinta Nakamura

Comment 2

•

5 years ago

Wayne-san,

I am Jinta Nakamura from SECOM, who was newly assigned as a staff who can report to Bugzilla.
On behalf of Hisashi Kamo, I will response as follows.

Tadahiko Ito from our company is proposing document at IETF now.
Although that document have not got consensus yet, confirmation procedure will be held at IETF 106 from July 19th.

We believe that key-usages are not appropriate, but because of no-consensus at IETF, We have not report that to linting tool maintainers.

We are not sure when we should report, but planning to report after consensus.
If you have any advice about when to report, we would like to hear that.

Also, linting tool using in SECOM is running 3 lint, which is cablint, certlint and x509lint, and discovered as a result of that.

Best regards,
Jinta Nakamura

Wayne Thayer

Comment 3

•

5 years ago

Jinta: thank you for pointing out that this is already identified by CABlint. I believe that Zlint has a GitHub page where issues can be reported, or pull requests for additional tests can be submitted.

Ryan: given that the RFC ambiguity has been acknowledged, I believe the appropriate action here is RESOLVED INVALID. Do you have any further comments or questions?

Flags: needinfo?(h-kamo) → needinfo?(ryan.sleevi)

Ryan Sleevi

Comment 4

•

5 years ago

Wayne: I agree with your assessment.

I really want to commend SECOM here for how they approached this. They proactively identified an area of ambiguity, raised it with root stores to gather feedback, took proactive steps to address any concerns that might exist because of that ambiguity (the unilateral revocation), and then have worked within the broader community to confirm and resolve the ambiguity. This is the model behavior for such a situation, and I think worth commending.

Status: ASSIGNED → RESOLVED

Closed: 5 years ago

Flags: needinfo?(ryan.sleevi)

Resolution: --- → INVALID

Jinta Nakamura

Comment 5

•

5 years ago

Wayne-san, Ryan-san,

Thank you for the response.
Also, we reported to Zlint's GitHub as folow:
https://github.com/zmap/zlint/issues/291

Best regards,
Jinta Nakamura

Nobody; OK to take it and work on it

Updated

•

2 years ago

Product: NSS → CA Program

Bugzilla

Quick Search

SECOM: Ambiguity on KeyUsage with ECC public key

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

People

(Reporter: h-kamo, Assigned: h-kamo)

References

Details

(Whiteboard: [ca-compliance])

Crash Data

Security

(public)

User Story

Description

Updated

Updated

Updated

Comment 1

Comment 2

Comment 3

Comment 4

Comment 5

Updated