Closed Bug 1738778 Opened 2 years ago Closed 2 years ago

TWCA: Policy OID not set to indicate the assurance level to the issued certs

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: okoeroo, Assigned: hcli)

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

Attachments

(2 files)

2.73 KB, application/octet-stream
Details
2.38 KB, application/octet-stream
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36

Steps to reproduce:

I've downloaded the X.509 certificates to the sites "kkday.com" and "ettoday.com" and looked for the CA/B forum policy OIDs. These are absent.

Actual results:

--- ettoday.net ---
Subject: CN=*.ettoday.net,OU=RD,O=ET New Media Holding Co., Ltd.,L=Taipei,ST=Taiwan,C=TW
Issuer: CN=TWCA Secure SSL Certification Authority,OU=Secure SSL Sub-CA,O=TAIWAN-CA,C=TW
Serial number: 95559031384477517871019103745820225456
OID 1.3.6.1.4.1.40869.1.1.25 not found in db
No OID found for DV, OV, EV, IV, QWAC

--- kkday.com ---
Subject: CN=*.kkday.com,OU=IT Dept.,O=KKDAY.COM INTERNATIONAL COMPANY LIMITED (TAIWAN),L=Taipei,ST=Taiwan,C=TW
Issuer: CN=TWCA Secure SSL Certification Authority,OU=Secure SSL Sub-CA,O=TAIWAN-CA,C=TW
Serial number: 95559031384477521445258106110945506283
OID 1.3.6.1.4.1.40869.1.1.25 not found in db
No OID found for DV, OV, EV, IV, QWAC

Expected results:

The expected results where to find Policy OIDs indicating.

Other relevant information lifted from the mail thread:

"One of their CPSes says that Policy OID is for a "Device Certificate" (Assurance Level 2), which is separate than a TLS server certificate with an OID of 1.3.6.1.4.1.40869.1.1.21 (Assurance Level 3), both are very similar, but I don't know what the distinction is between the two types."

which make this an issues not compliant with the baseline requirements.

Assignee: bwilson → hcli
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Attached file kkday-com.pem
Attached file ettoday-net.pem

Hi Oscar,

"Device Certificate" was added to our CP/CPS in 2014 as one type of TLS server certificates which was originally intended for devices with embedded web server (e.g. NAS), but afterward we have not really distinguished between "Device Certificate" and "SSL/TLS Certificate" and both OIDs are used interchangeably.
The identity validation procedures of "SSL/TLS Certificate" and "Device Certificate" are the same in our CPS and conform to the OV level of Baseline Requirements.

We have switched to use the Baseline Requirements OIDs as required by Baseline Requirements, so newly-issued "SSL/TLS Certificate" and "Device Certificate" have the 2.23.140.1.2.2 policy OID now.
The certificates in your question are issued before the effective date (2020-09-30) of the OID requirement introduced in Baseline Requirements v1.7.1 and thus not violation of Baseline Requirements.

I will be closing this as invalid, unless there are any further questions.

Flags: needinfo?(bwilson)

Ben: I raised several issues on the thread that would demonstrate why it would appear TWCA’s current response is inadequate.

Flags: needinfo?(bwilson)

Hao-Chun Li,
Please address Ryan's comments in the email thread and complete an incident report for issues that have been raised there.
Thanks,
Ben

Flags: needinfo?(hcli)

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 the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.
On 2021-11-02 UTC+8, we noticed the discussion on the MDSP list and this bug. In the following discussion with Ryan Sleevi on the MDSP list we realized our CP/CPS is in violation of the Baseline Requirements, specifically the requirement to document in CP/CPS that certificates issued with specific policy identifiers are managed in accordance with the BR, under section 7.1.6.4.

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.
(Times are in UTC+8)
2014-07-02 "Device Certificate" and its policy identifier are added to CP/CPS, while not clearly documented that this type of certificates are issued in accordance with BR.
2021-11-01 09:39 Post on the MDSP list by Oscar Koeroo: Policy unclear for CA "TWCA Secure SSL Certification Authority"
2021-11-02 05:22 This bug opened by Oscar Koeroo
2021-11-02 07:35 TWCA noticed the post and bug and started investigating the issue.
2021-11-02 15:27 TWCA determined the certificates issued with policy OID 1.3.6.1.4.1.40869.1.1.25 are not mis-issued in terms of violation of the Baseline Requirements and Mozilla Root Store Policy. Posted comment 4.
2021-11-04 09:40 In further discussion with Ryan Sleevi on the MDSP list, TWCA confirmed the violation of the Baseline Requirements in CP/CPS documentation. Added the issue to the fix list for next version of CP/CPS and began preparing response to Ryan and this incident report.

3.Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
Not applicable for the incident but as a side note, all TLS certificates issued after 2020-09-30 contains OID from BR.

4 In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
Not applicable

5. In a case involving TLS server certificates, 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. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
Not applicable

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
There was only one type of TLS server certificate in the CP/CPS, which is named "TLS / SSL Certificate". Therefore, it was clear that "TLS / SSL Certificate" are issued in accordance with the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates.
When "Device Certificate" was created, the editors of CP/CPS overlooked the ambiguity introduced by documentation of "Device Certificate" and the requirement of explicit documenting BR compliance for policy OID. One reason the ambiguity is not detected until now is that it was more common to determine whether a certificate is in scope of the TLS BR by id-kp-serverAuth and determine the level of identity authentication by subject attributes, so it was rare to check whether a certificate is BR-conformant by policy OID. Another reason is that we often focused on requirements that changed from time to time, but the requirement of OID documentation has been in the BR for a long time, so the possibility of non-compliance to such requirement is more likely to be overlooked when reviewing the CP/CPS.

7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
We will fix the issue in the next version of our CP/CPS, which is scheduled to be released in Q2 2022 at the latest.
We are also working on a more thorough review of our CP/CPS against the requirements in the next year as part of the transferation to next generation of root CA. We are planning to use a pure TLS hierarchy in the next generation of the root CA and exclusive CPS for TLS server certificates, which we hope can prevent issues like this in the first place.

Flags: needinfo?(hcli)

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 the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.
On 2021-11-02 UTC+8, we noticed the discussion on the MDSP list and this bug. In the following discussion on the MDSP Ryan Sleevi pointed out our CP/CPS associated with intermediate CA records is outdated, and thus could be a violation of CCADB Policy, which is part of Mozilla Root Store Policy.

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.
(Times are in UTC+8)
2020-03-18 The CP/CPS URLs on CCADB are updated as part of the 2020 annual audit report update.
2021-03-20 The CP/CPS URLs associated to the root CAs on CCADB are updated as part of the 2021 annual audit report update, but the CP/CPS URLs in intermediate CA records are not updated.
2021-11-02 01:21 In discussion under the MDSP post: Policy unclear for CA "TWCA Secure SSL Certification Authority", Ryan Sleevi mentioned the CPS disclosed on CCADB is outdated and out of compliance of Mozilla Root Store Policy.
2021-11-02 07:35 TWCA noticed the post and started investigating the issue.
2021-11-04 09:40 After internal investigation and further discussion with Ryan Sleevi on the MDSP list, TWCA confirmed that it is actually a violation of Mozilla Root Store Policy.

3. Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
Not applicable.

4. In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
Not applicable.

5. In a case involving TLS server certificates, 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. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
Not applicable.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
TWCA has considered the repository on its website as the authoritative repository for publication of information, including new versions of CP/CPS. While Mozilla also requires CA to keep CP/CPS disclosed on CCADB up to date, our current procedure of CP/CPS publication does not include update the information on CCADB. We have another process in place that for each CCADB Update notified by Mozilla, we check new data fields introduced are properly filled and resolve problem on the Task List of CCADB, but this process also failed to detect the issue.

7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
We will include updating CCADB as part of our publication procedure of the CP/CPS.
Furthermore, we will review all existing data fields on CCADB and incorporate the update processes into our current operation procedures appropriately.

Whiteboard: [ca-compliance]
Summary: TWCA: [Policy OID not set to indicate the assurance level to the issued certs] → TWCA: Policy OID not set to indicate the assurance level to the issued certs

Do you know when your next CPS will be published?

Flags: needinfo?(hcli)

Hi,

The newest version of CPS (the authority approved version, no material changes) has been published on 2021-12-21.
I will include the CPS in the CCADB annual audit update case which will be in around early March.

The next CPS including the correction (asserting Device Certificates are managed in accordance with the BR) are still in progress and scheduled to be published in Q2 2022. I don't have a precise date yet.

Flags: needinfo?(hcli)

As a follow-up, has the CPS with the correction regarding Device Certificates been published yet?

Flags: needinfo?(hcli)

Hi,

We have completed the CPS changes related to this issue, and the changes have been approved by our PMA.
We are now waiting for review by the competent government authority. The final version of CPS will be released after approval with the formal document number assigned. According to past experience, the review could last as long as a year, beyond our planned schedule.
Before that, we can provide the draft version to confirm the issue is resolved in the new CPS if necessary.

Thanks,

Flags: needinfo?(hcli)

A CPS revision process that takes as long as a year to complete presents a problem. Even if it is not assigned a formal document number, is there a repository where these CPSes are posted for public review and consideration? If so, what is the URL?

Flags: needinfo?(hcli)

Hi Ben,
The new CP and CPS has been posted to our official repository: https://www.twca.com.tw/repository?lang=en
Please check TWCA CP (v2.4 2022/5/30) in the first section and Global CPS (v1.7 Draft) in the CP CPS Draft section.
Device Certificate and its OID has been merged into TLS / SSL Certificate in these documents.

Flags: needinfo?(hcli)
Flags: needinfo?(bwilson)

Thanks for that clarification. Unless there are further questions, I will close this sometime next week (9/26-9/30).
Ben

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: