Closed Bug 1563574 Opened 5 months ago Closed 2 months ago

SECOM: Failure to disclose Unconstrained Intermediate within 7 Days

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ryan.sleevi, Assigned: h-kamo)

Details

(Whiteboard: [ca-compliance] )

The following certificate has been issued and is not disclosed within CCADB.

This appears to be a of Bug 1497703.

Please provide an Incident Report. Within this Incident Report, please provide an explanation why the steps outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1497703#c3 were insufficient.

Please also provide a binding commitment from SECOM that this problem will not reoccur.

Flags: needinfo?(h-kamo)

Ryan-san,

Regarding with this issue, we are now summarizing the detailed information with our colleague Mr. Ito, who actually attended the forum discussion at Google Groups, let us comment next week.
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/B4lzjgNKtEQ

Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Thank you for pointing to that discussion.

The important and relevant piece here, and why this certificate is required to be disclosed, is that the issuing intermediate, https://crt.sh/?id=1352971689 , does not meet the definition of Technically Constrained. Mozilla Policy refers to the Baseline Requirements, Section 7.1.5, which state that:

If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA
Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress
and DirectoryName as follows:-
(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered
the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line
with the verification practices of section 3.2.2.4.
(b) For each iPAddress range in permittedSubtrees, the CA MUST confirm that the Applicant has been
assigned the iPAddress range or has been authorized by the assigner to act on the assignee's behalf.
(c) For each DirectoryName in permittedSubtrees the CA MUST confirm the Applicants and/or
Subsidiary’s Organizational name and location such that end entity certificates issued from the
subordinate CA Certificate will be in compliancy with section 7.1.2.4 and 7.1.2.5.

The issue is that this certificate only contains dNSName nameConstraints. As a consequence, it is not Technically Constrained, and thus required to be disclosed and audited. This also means that the subordinate certificate issued is also not Technically Constrained, and thus also required to be disclosed and audited.

Flags: needinfo?(h-kamo)

Ryan-san,

Thank you for your comments.

The CA in question this time was on the assumption that Technical Constraints were applied, and not posted to CCADB.
After posting it to Bugzilla, we reconfirmed BR in our company, and as you pointed out, we found that the control of the name constraints is insufficient, which is violated against Chapter 7.1.5 of BR.

From this CA, we provide server certificates and client certificates.
We reconfirmed the all certificates issued by this CA, and found that 3 server certificates and 3 client certificates were issued at this point, then the revocation of all 3 server certificates have been completed.
Regarding with the client certificates, we will continue to coordinate with the customer.
For CA certificates, we will immediately make corrections and updates to the correct Technical Constraints.
※Specifically, we modify the Name Constraints field as follows:
X509v3 Name Constraints:
Permitted:
DNS: .fujixerox.co.jp
DirName: O =Fuji Xerox, L = Yokohama, C = JP
Excluded:
IP:0.0.0.0/0.0.0.0
IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0

After that, we will carry out the revocation of the old CA certificate.
We will make the post later for the entire work schedule and the incident report.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Thanks. Do you have a timeline for when those steps will be completed, or when you will expect to have such a timeline?

Flags: needinfo?(h-kamo)

Ryan-san

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

Thank you for your comment.
We are currently making the plan with our customer.
We will report the details and timelines next week then.

Best regards,
Yuu Hidaka

Wayne:

I'm deferring to you about the timeframe here. I'm raising this, because the issuing intermediate ( https://crt.sh/?id=1352971689 ) is not listed within the scope of the BR audit ( https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222450 ) despite being disclosed as such.

The consequence of the incomplete nameconstraints on that certificate, along with the unconstrained nature of the subordinate, gives me strong belief that one or both private keys are controlled by an unaudited, unconstrained entity. While they are constrained via the dNSName constraints, they are not constrained via IP Address, and can thus issue a certificate for any IP on the Internet.

My belief is that this requires /immediate/ revocation and treatment as a high-security incident. The past discussion (in Comment #1) highlighted the importance of ensuring the proper constraints last January. I wanted to bring this one to your attention as well, because I think this represents an URGENT and REAL security risk.

Flags: needinfo?(wthayer)

(In reply to Ryan Sleevi from comment #6)

Wayne:

I'm deferring to you about the timeframe here. I'm raising this, because the issuing intermediate ( https://crt.sh/?id=1352971689 ) is not listed within the scope of the BR audit ( https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222450 ) despite being disclosed as such.

The consequence of the incomplete nameconstraints on that certificate, along with the unconstrained nature of the subordinate, gives me strong belief that one or both private keys are controlled by an unaudited, unconstrained entity. While they are constrained via the dNSName constraints, they are not constrained via IP Address, and can thus issue a certificate for any IP on the Internet.

My belief is that this requires /immediate/ revocation and treatment as a high-security incident. The past discussion (in Comment #1) highlighted the importance of ensuring the proper constraints last January. I wanted to bring this one to your attention as well, because I think this represents an URGENT and REAL security risk.

I agree, this certificate is clearly misissued and the 7-day BR revocation window has passed. I will submit it for addition to OneCRL on Monday unless SECOM has revoked this certificate or commits here to revoke it before 27-July.

Flags: needinfo?(wthayer) → needinfo?(yu-hidak)

Ryan-san, Wayne-san,

Thank you for the comments.

We are now making the arrangement for revocation.
We commit to revoke it before 27-July.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 27-July 2019

Ryan-san, Wayne-san,

Let me post about revocation in behalf of my colleague Hisashi Kamo of Secom.
We have revoked this certificate and signing CA certificate.

Best regards,
Jinta Nakamura

Thanks for the update.

It's going to be necessary to capture this in an Incident Report using that template.

I think the questions we want to see answered are:

  1. Why weren't the constraints issues detected by SECOM?
  2. Related to #1, why was the issuing-intermediate disclosed as Audit Same as Parent? Had this not been set, it would have allowed for earlier detection?
  3. Related, after the m.d.s.p. discussion, why was the issuing-intermediate not reviewed to ensure the proper constraints?

Ryan-san,

Thank you for your comments.
We are now preparing the answers and let us have some time to post it on early next week.

Thank you for your consideration.

Best regards,
Jinta Nakamura

Ryan-san, Wayne-san,

Let us provide you our incident report.

  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.

2019/07/04 We received a report from Bugzilla and as a result of investigation, we recognized the problem.

  1. 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/01/15 We asked a question about Name Constraints in Google Groups and understood that we need to do NameConstraints for each intermediate CA certificates.
2019/03/28 We issued the two intermediate CA certificates with wrong setting about NameConstraints.
2019/07/04 We received a report from Bugzilla.
2019/07/10 We recognized the problem.
2019/07/10 We stopped issuing EE certificate from the intermediate CAs.
2019/07/23 We revoked the two intermediate CA certificates with the problem.

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

2019/07/10 We stopped issuing certificates from the intermediate CAs with the problem.

  1. 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 two intermediate CA certificates with the problem are as follows:
https://crt.sh/?id=1352971689&opt=mozilladisclosure
https://crt.sh/?sha256=c69fb2391f7a23381fd33a6576be4f0a2833b9d811395be8df353b79b6cd4718&opt=mozilladisclosure
2019/03/28 We issued the two intermediate CA certificates with this problem.

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

The two certificates with problem are as follows:
https://crt.sh/?id=1352971689&opt=mozilladisclosure
https://crt.sh/?sha256=c69fb2391f7a23381fd33a6576be4f0a2833b9d811395be8df353b79b6cd4718&opt=mozilladisclosure

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

The profile creator made a mistake in recognition about NameConstraints, and confirmed only the constraint of DNSName.
As a result, we did not check the review of other constraints items and issued the certificats with wrong setting about NameConstraints.

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

We have procedures for registering to CCADB. Because this case with NameConstraints is not considered in our manual, we will revise our review including whether NameConstraints are there or not before issuing CA certificates.
Also, from now on, in addition to deepen the understanding on BR and the NameConstraints of each root policy, we plan to revise the checks on issued intermediate CA certificates.

We answer the question from Ryan-san as follows:

  1. Why weren't the constraints issues detected by SECOM?

We are very sorry about that.
The profile creator made a mistake in recognition about NameConstraints, and confirmed only the constraint of DNSName.
Therefore, we issued the two intermediate CA certificates with the wrong setting about NameConstraints.
As the same statement was written in the incident report, please confirm.

  1. Related to #1, why was the issuing-intermediate disclosed as Audit Same as Parent? Had this not been set, it would have allowed for earlier detection?

These intermediate CA certificates do not acquire WebTrust certification, and operate as technically constrained.
Therefore there was no plan to register them with CCADB.
Because this case is not considered with technically constrained in our manual, we specified it as same as parent and released them as usual.
If it is not set, it seems that a confirmation e-mail has arrived and has been detected early.
From now on, they will be operated as technically constrained so they will not be registered in CCADB.
Also, we correct the manual in consideration of technically constrained.

  1. Related, after the m.d.s.p. discussion, why was the issuing-intermediate not reviewed to ensure the proper constraints?

After the discussion of m.d.s.p., we had a common understanding in our company that the NameConstraints field for the four-tier model would not be subject to audit if it is properly configured. However, our understanding of what the appropriate NameConstraints field values should be, has not been clarified by the discussion of m.d.s.p. Therefore, it was passed the review with the wrong value for the same reason as #1.
We’d like to correct it as we’ll do as #1.

Best regards,
Jinta Nakamura

Flags: needinfo?(ryan.sleevi)

In terms of working to understand the root cause, I understand the profile creator made a mistake. Part of the reason we have incident reports is to try and develop better understanding of what are the sources of mistakes, and how to prevent them.

For example, what steps are involved when creating and configuring a profile? What sort of review is required before hand, and what sort of confirmation is performed after the fact? Who is involved?

The way it sounds currently is that one person was able to go in and configure new certificates to be issued in violation of the BRs, and there was no review or other controls that would have prevented this. If that's not correct, then understanding what the process is used for every profile configured/created is useful, so that we can find opportunities to improve that process.

The goal is not about blaming the profile creator; it's about finding ways to help them carry out their job in a way that minimizes the risk of accidents or errors.

Flags: needinfo?(ryan.sleevi)

Ryan-san,

We'd like to propose the model work flow as follows:

  1. At first, profile creator creates a certificate profile.
  2. Then, we assign multiple reviewers for reviewing the profiles and get approval for work.
  3. Finally, The staff in charge(2 persons) performs the certificate issuance work.

The cause of this case was because of that we had a problem during the process flow "2".

Since the review was done by multiple people, this process usually should have prevented mistakes.
However, the staff in charge and reviewers (multiple names) are not fully familiar with NameConstraints, and reviewed the restriction on DNSName with NameConstraints, but regarding other values (IP address, directory name), they passed the review with misrecognizing the necessity of setting.

As a future improvement measure, we'll add a check sheet for the NameConstraints setting value in the procedure manual.

Also, when setting certificate attributes that are set less frequently in the future, we'll strengthen the confirmation method depending on the settings, so that the recurrence will be prevented.

Best regards,
Jinta Nakamura

Flags: needinfo?(wthayer)

It appears that all questions have been answered and remediation is complete.

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Flags: needinfo?(yu-hidak)
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
Whiteboard: [ca-compliance] - Next Update - 27-July 2019 → [ca-compliance]
You need to log in before you can comment on or make changes to this bug.