1397832 - GRCA: Signing SHA-1 OCSP responses with unconstrained certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

Attachment: OCSP Response

I just sent the following to Government of Taiwan, Government Root Certification Authority (GRCA)'s problem reporting address ([e-mail]).  Note that in the April 2017 CA Communication, GRCA stated that they were no longer using SHA-1 to sign OCSP responses: https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026

Your OCSP responder at
http://hcaocsp.nat.gov.tw/cgi-bin/OCSP/ocsp_server.exe signs OCSP
responses with SHA-1 using a certificate that is trusted by Mozilla for
server authentication.  This is a violation of section 5.1.1 of
Mozilla's Root Store Policy Version 2.5, which states:

"CAs MAY sign SHA-1 hashes over OCSP responses only if the signing
certificate contains an EKU extension which contains only the
id-kp-ocspSigning EKU. ... CAs MUST NOT sign SHA-1 hashes over other data,
including CT pre-certificates."

Furthermore, since the response reflects an attacker-supplied nonce of
arbitrary length, your OCSP responder could allow attackers to forge
SHA-1 SSL certificates using a chosen-prefix attack as described here:
https://www.mail-archive.com/[e-mail]/msg02999.html

I have attached a signed OCSP response as evidence.

A copy of this report will be sent to Mozilla.

Comment 1

[Kathleen Wilson]

Hung-Yu Hsu or Rob Betwu,

Please reply in this bug very promptly to acknowledge that you have been informed of this bug, and provide a timeline for resolving the concern.

Then please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 2

[Gervase Markham [:gerv]]

(In reply to Kathleen Wilson from comment #1)
> Hung-Yu Hsu or Rob Betwu,
> 
> Please reply in this bug very promptly to acknowledge that you have been
> informed of this bug, and provide a timeline for resolving the concern.

It has now been 10 days. Please respond ASAP.

Gerv

Comment 3

[National Development Council]

Incident Report

1.How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
-->Via Bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 at Sep. 23 2017

2.A timeline of the actions your CA took in response.
-->Sep. 23: Identify the incident and found that HCA (one of subordinate CA) misunderstood the policy.
   Sep. 24: Contact the subordinate CA administrator and scheduled to fix the problem before Sep. 27.
   Sep. 25: Confirm that no other subordinate CA has the same issue.
   Sep. 30: Confirm the problem were fixed and report to bugzilla.

3.Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
-->This subordinate CA no longer issues TLS/SSL certificate since Sep. 2016.

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.
-->No problematic TLS/SSL certificates were issued.

5.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.
-->No problematic TLS/SSL certificates were issued.

6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
-->The HCA misunderstood the policy and assumed that the SHA-1 policy only apply to certificates. Thus HCA do stop issuing any SHA-1 certificate since last year, however, they forget to replace SHA-1 hash algorithm of OCSP response.  GRCA also has not conducted technical review before replying CA communication this April.  

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.
-->In order to prevent from subordinate CAs misunderstanding the new policies, GRCA will take following steps when policies change:
1.Gathering all subordinate CAs and explain new policies precisely.
2.Get the schedule of subordinate CAs to conform new policies.
3.Technically review all subordinate CAs and check completeness.
These action takes effect immediately.

Comment 4

[Ryan Sleevi]

(In reply to National Development Council from comment #3)
> 2.A timeline of the actions your CA took in response.
> -->Sep. 23: Identify the incident and found that HCA (one of subordinate CA)
> misunderstood the policy.
>    Sep. 24: Contact the subordinate CA administrator and scheduled to fix
> the problem before Sep. 27.
>    Sep. 25: Confirm that no other subordinate CA has the same issue.
>    Sep. 30: Confirm the problem were fixed and report to bugzilla.

Can you also please provide the timeline related to compliance steps taken?

Such as, when did GRCA first update its policies with respect to the BR change, when did GRCA notify its subordinates of the policy change, were there any other policies or practices GRCA had in place for compliance changes that were followed?


> 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.
> -->In order to prevent from subordinate CAs misunderstanding the new
> policies, GRCA will take following steps when policies change:
> 1.Gathering all subordinate CAs and explain new policies precisely.
> 2.Get the schedule of subordinate CAs to conform new policies.
> 3.Technically review all subordinate CAs and check completeness.
> These action takes effect immediately.

Approximately how many independent sub-CAs does GRCA have?

Kathleen: From trying to examine the audit information (based on both crt.sh and https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport ), I cannot appear to find a BR audit for these CAs (e.g. https://crt.sh/?id=12714631 or https://crt.sh/?id=12721379 )

The newest statement I could find about BR compliance was in response to the May 2014 communication - https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml - suggesting that GRCA expected an audit to be completed within the year.

From looking at the original inclusion bug, GRCA acts as a "Super-CA" - https://bugzilla.mozilla.org/show_bug.cgi?id=274106#c4 - but the audit information provided to the CCADB does not seem to reflect that or be consistent with this response (with respect to audit scope). Given https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs , I believe it would be consistent with Mozilla's policies for inclusion to remove this CA, but would be interested in your thinking.

Comment 5

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #4) 
> Kathleen: From trying to examine the audit information (based on both crt.sh
> and
> https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport ),
> I cannot appear to find a BR audit for these CAs (e.g.
> https://crt.sh/?id=12714631 or https://crt.sh/?id=12721379 )

I see that this CA does indeed need to update the Standard Audit and BR Audit information for all of their subCAs in the Common CA Database very promptly.

Here's the 2017 Audit statements I am aware of:

https://cert.webtrust.org/SealFile?seal=2252&file=pdf
SHA-256 Fingerprints of certs in scope of audit:
76:00:29:5E:EF:E8:5B:9E:1F:D6:24:DB:76:06:2A:AA:AE:59:81:8A:54:D2:77:4C:D4:C0:B2:C0:11:31:E1:B3
70:B9:22:BF:DA:0E:3F:4A:34:2E:4E:E2:2D:57:9A:E5:98:D0:71:CC:5E:C9:C3:0F:12:36:80:34:03:88:AE:A5
90:FA:98:D6:46:DD:5F:00:60:2D:68:D1:7D:D7:6B:55:EE:51:CD:A3:D3:92:2F:0D:BD:D1:04:80:F5:99:0A:CD
FE:BF:42:F9:BE:5A:BF:DD:B8:17:5D:01:02:39:F9:03:6F:E9:0D:33:3E:70:8E:13:CC:5E:ED:FF:D5:2D:0A:97

https://cert.webtrust.org/SealFile?seal=2253&file=pdf
SHA-256 Fingerprints of certs in scope of audit:
30:CE:40:96:31:12:0A:0C:5A:C5:48:AB:FB:23:17:89:A8:47:41:1C:38:18:A5:6E:9B:06:FE:B1:72:3C:E7:97
1F:99:2B:63:59:05:FC:0E:EC:ED:AA:BC:EA:F9:74:1D:77:77:8D:D8:38:DE:92:B5:BB:51:11:72:2F:46:31:D6

Taiwan GRCA must provide current audit statements (included BR audit statements) for all of their subCAs annually, and must keep the data in the CCADB current. If a subCA does not issue TLS/SSL certs, then that subCA may be added to OneCRL to remove the requirement of having an annual BR audit statement.


> 
> The newest statement I could find about BR compliance was in response to the
> May 2014 communication -
> https://docs.google.com/spreadsheets/d/1v-
> Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml - suggesting that GRCA
> expected an audit to be completed within the year.
> 
> From looking at the original inclusion bug, GRCA acts as a "Super-CA" -
> https://bugzilla.mozilla.org/show_bug.cgi?id=274106#c4 - but the audit
> information provided to the CCADB does not seem to reflect that or be
> consistent with this response (with respect to audit scope). Given
> https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs , I believe
> it would be consistent with Mozilla's policies for inclusion to remove this
> CA, but would be interested in your thinking.

Super-CAs are allowed to be in Mozilla's program if they continuously ensure that all of their subCAs are meeting the requirements of Mozilla's Root Store Policy and the CA/Browser Forum's Baseline Requirements.

If the Taiwan GRCA is unable to keep their full CA hierarchy in full compliance of our requirements, then we should remove the root (Super-CA) cert, and only consider inclusion of specific subordinate CAs who do fully meet Mozilla's root store requirements.

I will update Bug #1065896 to this effect as well.

Comment 6

[Gervase Markham [:gerv]]

(In reply to National Development Council from comment #3)
> 1.How your CA first became aware of the problem (e.g. via a problem report
> submitted to your Problem Reporting Mechanism, via a discussion in
> mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
> -->Via Bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 at
> Sep. 23 2017

An email about this was sent to you by Kathleen when she filed the bug (at least, she tells me she emailed all the affected CAs). Did you not receive this email? Kathleen: can you check that it was sent, and let us know who it was sent to?

Gerv

Comment 7

[Kathleen Wilson]

(In reply to Gervase Markham [:gerv] from comment #6)
> Kathleen: can you check that it was sent, and let us know who it
> was sent to?

Here are the emails that I sent...


-------- Forwarded Message --------
Subject: URGENT: Need your response in Bugzilla #1397832
Date: 	Fri, 8 Sep 2017 11:54:11 -0700
From: 	Kathleen Wilson <[e-mail]>
To: 	徐宏宇 <[e-mail]>, 政府處 吳三裕 <[e-mail]>

Hello Hong-Yu Hsu and Rob Betwu,

An incident regarding your CA has been reported, and it has been 
determined that the problem can cause active issuance (via SHA-1 
collisions) of trusted certs. Therefore, your prompt response in the 
following Bugzilla Bug is requested.

https://bugzilla.mozilla.org/show_bug.cgi?id=1397832

I assigned the bug to [e-mail]. If you need me to directly add 
you to the bug, then please create a Bugzilla account and send me the 
email for it:
https://bugzilla.mozilla.org/createaccount.cgi

Regards,
Kathleen



-------- Forwarded Message --------
Subject: Re: URGENT: Need your response in Bugzilla #1397832
Date: 	Fri, 22 Sep 2017 17:39:54 -0700
From: 	Kathleen Wilson <[e-mail]>
To: 	徐宏宇 <[e-mail]>, 政府處 吳三裕 <[e-mail]>
CC: 	gpki <[e-mail]>, Gervase Markham <[e-mail]>, Aaron Wu <[e-mail]>

Dear Government of Taiwan CA,

A representative of your CA must respond immediately in
https://bugzilla.mozilla.org/show_bug.cgi?id=1397832

Regards,
Kathleen

Comment 8

[National Development Council]

Provide the latest Audit reports for all subCAs .

GRCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GRCA_Audit_Report_2017.pdf)
GCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GCA_WTCA_Report_2017.pdf)
GCA BR (http://grca.nat.gov.tw/download/Audit/GCA_BR_Audit_Report_2017.pdf)
XCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/XCA_Audit_Report_2017.pdf)
HCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2016.pdf)
HCA BR (http://grca.nat.gov.tw/download/Audit/HCA_BR_Audit_Report_2016.pdf)
MOEACA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOEACA_Audit_Report_2017.pdf)
MOICA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOICA_Audit_Report_2017.pdf)

The annual audit for HCA just finished. we don't get the audit report yet.

Comment 9

[Gervase Markham [:gerv]]

National Development Council: you need to provide current audit information in the CCADB, not just in this bug here. Has that been done?

Please also reply to the issues raised in comment #6 and comment #4 ASAP.

Gerv

Comment 10

[National Development Council]

(In reply to Gervase Markham [:gerv] from comment #6)
> (In reply to National Development Council from comment #3)
> > 1.How your CA first became aware of the problem (e.g. via a problem report
> > submitted to your Problem Reporting Mechanism, via a discussion in
> > mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
> > -->Via Bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 at
> > Sep. 23 2017
> 
> An email about this was sent to you by Kathleen when she filed the bug (at
> least, she tells me she emailed all the affected CAs). Did you not receive
> this email? Kathleen: can you check that it was sent, and let us know who it
> was sent to?
> 
> Gerv

After some investigation, I found the Sep. 8 email in spam mail box.
It never happen before, and I have changed the detection rule to prevent the mail goes to spam mail box again.
I would also like to provide an extra email address [e-mail] as a backup email address.

Comment 11

[National Development Council]

(In reply to Ryan Sleevi from comment #4)
> (In reply to National Development Council from comment #3)
> > 2.A timeline of the actions your CA took in response.
> > -->Sep. 23: Identify the incident and found that HCA (one of subordinate CA)
> > misunderstood the policy.
> >    Sep. 24: Contact the subordinate CA administrator and scheduled to fix
> > the problem before Sep. 27.
> >    Sep. 25: Confirm that no other subordinate CA has the same issue.
> >    Sep. 30: Confirm the problem were fixed and report to bugzilla.
> 
> Can you also please provide the timeline related to compliance steps taken?
> 
> Such as, when did GRCA first update its policies with respect to the BR
> change, when did GRCA notify its subordinates of the policy change, were
> there any other policies or practices GRCA had in place for compliance
> changes that were followed?

5 Apr. 2017 Received Mozilla April 2017 CA communication.
12 Apr. 2017 Notify all subordinate CAs to check the compliance of CA communication.
25 Apr. 2017 Received reports from all subordinate CAs (including HCA) and confirm the result of all subordinate CAs.
28 Apr. 2017 Report results to CCADB
7 Sep. 2017 This problem  were  notified on Bugzilla (Bug 1397832)

HCA not only issues SSL certificates (not issued since Sep. 2016), but also other certificates. Considering the OCSP related to API and interoperability to the legacy system, HCA can’t stop generating SHA-1 OCSP response immediately. In the mean time, HCA misunderstands the SHA-1 deprecation policy and just stops issues the SHA-1 certificates. That’s why HCA reports to GRCA that they have done with the SHA-1 deprecation. Through this notification, GRCA required HCA to stop generating SHA-1 OCSP response immediately, and HCA stops generating SHA-1 OCSP response at 30 Sep. 2017.
GRCA and all subordinate CAs have regular meeting with Government Electronic Certification Steering Committee (twice per year). If necessary GRCA also have  meetings with subordinate CAs and make the subordinate CAs to comply with related requirement.

> 
> > 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.
> > -->In order to prevent from subordinate CAs misunderstanding the new
> > policies, GRCA will take following steps when policies change:
> > 1.Gathering all subordinate CAs and explain new policies precisely.
> > 2.Get the schedule of subordinate CAs to conform new policies.
> > 3.Technically review all subordinate CAs and check completeness.
> > These action takes effect immediately.
> 
> Approximately how many independent sub-CAs does GRCA have?

The subordinate certification authorities under GRCA are:
1.Government Certification Authority(GCA),
2.miXed organization Certification Authority(XCA),
3.Certification Authority of MOI(MOICA),
4.Certification Authority of MOEA(MOEACA),
5.Healthcare Certification Authority (HCA).
Only GCA and HCA issues SSL certificates.
P.S HCA no longer issues SSL certificate since Sep. 2016

> Kathleen: From trying to examine the audit information (based on both crt.sh
> and
> https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport ),
> I cannot appear to find a BR audit for these CAs (e.g.
> https://crt.sh/?id=12714631 or https://crt.sh/?id=12721379 )
> 
> The newest statement I could find about BR compliance was in response to the
> May 2014 communication -
> https://docs.google.com/spreadsheets/d/1v-
> Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml - suggesting that GRCA
> expected an audit to be completed within the year.

GRCA has 5 subordinate CAs, including GCA, XCA, MOICA, MOEACA and HCA. Only GCA and HCA (HCA no longer issues SSL certificate since Sep. 2016) issue SSL certificates, and we have baseline requirement audit reports for both GCA and HCA. 

The baseline requirement audit also applied to GRCA. Since GRCA does not issues any SSL certificates, we don’t have a separated audit report for it. Instead of providing the audit report, we provide an audit statement that states how the baseline requirement audits are performed according to Kathleen’s suggestion(https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/eFG27ZTYWD8/WleX5FSHEQAJ 16/12/14). The audit statement is available at https://bug1065896.bmoattachments.org/attachment.cgi?id=8835815(2016’s version. The 2017’s will be available in Nov. 2017). 
The auditors, KPMG are willing to explain the audit process if necessary.The contact information for the people at KPMG is below:
David Hsiu
68F, TAIPEI 101 TOWER, No.7, Sec. 5, Xinyi Road,
Taipei 11049, Taiwan (R.O.C.)
email: [e-mail]
T: [phone] ext.11900 
F: [phone] ext.11900

> From looking at the original inclusion bug, GRCA acts as a "Super-CA" -
> https://bugzilla.mozilla.org/show_bug.cgi?id=274106#c4 - but the audit
> information provided to the CCADB does not seem to reflect that or be
> consistent with this response (with respect to audit scope). Given
> https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs , I believe
> it would be consistent with Mozilla's policies for inclusion to remove this
> CA, but would be interested in your thinking.

Comment 12

[Andrew Ayer]

I've confirmed that this responder is no longer signing responses with SHA-1.

Can this bug be made public now?

Comment 13

[Gervase Markham [:gerv]]

Yes, it can.

Gerv