Policy unclear for CA "TWCA Secure SSL Certification Authority"
Oscar Koeroo
Ben Wilson
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f79c9a95-b07a-4f04-8a23-e228cd8f43ean%40mozilla.org.
Ryan Sleevi
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZ_izKoqWjxEQ6k22eDw5e14PL-0Zmoz5oJn%2BgwsFBFTg%40mail.gmail.com.
Oscar Koeroo
Ryan and Ben,
Thank you for your thorough analyses in your replies. How do I best proceed into filing a complaint on the found and confirmed non-compliance to the baseline requirements?
Ben Wilson
Oscar Koeroo
Hello Ben,
I've filled the bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1738778
While filling in the forum I noticed the
first numbers in the serial being very much overlapping. As far
as I understand the policy on serial numbers, these must be have
sufficient entropy. This does not show this feature:
95559031384477521445258106110945506283
95559031384477517871019103745820225456
--- 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
--- 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
Would this qualify as another issue to report?
kind regards,
Oscar Koeroo
Buschart, Rufus
Hi Oscar!
I checked ~10 certificates issued by TWCA at crt.sh and the serial numbers all do have the same onset (“47:e5:00:00:00:04”) but these are followed by 64 random bits. Therefore, I would say, this is not a mis-issuance.
/Rufus
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9dca72c0-2a1e-511f-9ee7-1d36f7d87998%40gmail.com.
Hao-Chun Li
Hao-Chun Li
Hi Ryan,
Sorry for not addressing all of the concerns you raised in the first response.
Regarding the policy OID issue, your analysis is correct. We completed the transition to including BR OID in all TLS server certificates on 2020-07-16, so before that date not all certificates include BR OID. The certificates without BR OID were indeed in violation of Microsoft’s root program requirements. All certificates issued after the transition date (and the effective date of OID requirement from BR 1.7.1) include BR OID and are not in violation of the Baseline Requirements.
Regarding the CP/CPS, the most recent CP/CPS are the “Draft” ones (v1.6 for Global CA CPS) on https://www.twca.com.tw/repository?lang=en which have effective date of 2021-05-04. The draft status is due to the lengthy approval process (which is actually still in progress for this version) required by Taiwan Electronic Signature Act. The CP/CPS listed in the Root CA records on CCADB were submitted with the annual audit reports and were up-to-date for the audit period. For the different versions listed in the intermediate CA records, we thought they should have been updated by the audit report case but just realized that ”CP/CPS Same as Parent” is not checked. I have updated the intermediate CA records and will file an update request to CCADB for the Root CA records. We have also been working on releasing new CP/CPS more frequently.
Our current CP/CPS covers both TLS server certificates and certificates for other applications like AATL certificate you mentioned. In these certificate types only “TLS / SSL Certificate” and “Device Certificate” have the id-kp-serverAuth and are subjected to compliance with the Baseline Requirements. Although it is indeed confusing from the naming, but the requirements for “TLS / SSL Certificate” and “Device Certificate”, for example, the description of the identity authentication process (3.2.2), are the same in the CP/CPS. The name “Device Certificate” was originally intended for devices with embedded web server (e.g. NAS) and are distinguished at the business level, thus the different assurance levels in the CP/CPS. But then because they are both TLS server certificates by definition of the Baseline Requirements and root program requirements, we do not really distinguished between these two types of certificate. To avoid confusion, we are planning to combine them into only “TLS / SSL Certificate” in future version of CP/CPS.
Hope above clarifies your concerns.
Do you think we should also post these to Bugzilla, and for which part we should file an incident report?
Pease tell us if you have any further questions.
Thanks,
Hao-Chun Li
Ryan Sleevi
Regarding the CP/CPS, the most recent CP/CPS are the “Draft” ones (v1.6 for Global CA CPS) on https://www.twca.com.tw/repository?lang=en which have effective date of 2021-05-04. The draft status is due to the lengthy approval process (which is actually still in progress for this version) required by Taiwan Electronic Signature Act.
The CP/CPS listed in the Root CA records on CCADB were submitted with the annual audit reports and were up-to-date for the audit period. For the different versions listed in the intermediate CA records, we thought they should have been updated by the audit report case but just realized that ”CP/CPS Same as Parent” is not checked. I have updated the intermediate CA records and will file an update request to CCADB for the Root CA records. We have also been working on releasing new CP/CPS more frequently.
But that's ultimately a question for Ben and Kathleen, as well as other root programs, which rely on the CCADB to understand the state of all CAs in their program.
Our current CP/CPS covers both TLS server certificates and certificates for other applications like AATL certificate you mentioned. In these certificate types only “TLS / SSL Certificate” and “Device Certificate” have the id-kp-serverAuth and are subjected to compliance with the Baseline Requirements. Although it is indeed confusing from the naming, but the requirements for “TLS / SSL Certificate” and “Device Certificate”, for example, the description of the identity authentication process (3.2.2), are the same in the CP/CPS. The name “Device Certificate” was originally intended for devices with embedded web server (e.g. NAS) and are distinguished at the business level, thus the different assurance levels in the CP/CPS. But then because they are both TLS server certificates by definition of the Baseline Requirements and root program requirements, we do not really distinguished between these two types of certificate. To avoid confusion, we are planning to combine them into only “TLS / SSL Certificate” in future version of CP/CPS.
The extension MUST contain one or more policy identifiers that indicate adherence to and compliance with
these Requirements. CAs MUST either use a CA/Browser Forum identifier reserved for this purpose or MUST
use a policy identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement
to indicate the Certificate's compliance with these Requirements.
The issuing CA SHALL document in its Certificate Policy or Certification Practice Statement that the
Certificates it issues containing the specified policy identifier(s) are managed in accordance with these
Requirements.
Hao-Chun Li
On Wed, Nov 3, 2021 at 4:22 AM Hao-Chun Li <hc...@twca.com.tw> wrote:Regarding the CP/CPS, the most recent CP/CPS are the “Draft” ones (v1.6 for Global CA CPS) on https://www.twca.com.tw/repository?lang=en which have effective date of 2021-05-04. The draft status is due to the lengthy approval process (which is actually still in progress for this version) required by Taiwan Electronic Signature Act.
I think it's worth asking Root Programs whether CP/CPSes flagged as "Draft" comply with BRs v1.8.0, Section 2.3, or whether TWCA should have notified an inability to comply with the BRs under Section 9.16.3, so that they would be aware of it. Perhaps TWCA already has done this notification, and could link to it?The issue here is that relying parties rely on CP/CPS to understand what the CA practices, and I'd question whether something flagged "draft" reasonably conveys that. It equally opens up questions for the relevant audits and supervision, and whether or not the auditor's interpretation of "draft" is "not in force", which would materially affect the conclusions of the audits.
The CP/CPS listed in the Root CA records on CCADB were submitted with the annual audit reports and were up-to-date for the audit period. For the different versions listed in the intermediate CA records, we thought they should have been updated by the audit report case but just realized that ”CP/CPS Same as Parent” is not checked. I have updated the intermediate CA records and will file an update request to CCADB for the Root CA records. We have also been working on releasing new CP/CPS more frequently.
This does seem, on its face, a failure to abide by the CCADB Policy. I'm glad that it was as simple a matter of "CP/CPS Same as Parent" not being checked, but it may be appropriate to consider filing an incident on the failure to detect this previously. In particular, it's useful to understand what processes and controls TWCA had in place to ensure all of its disclosed CAs' CP/CPS were correct, why those processes and controls failed to notice this, and how those processes have been improved to better detect issues in this category going forward. That is, the goal isn't to understand that you've simply checked "CP/CPS Same as Parent", or that you've added an extra set of eyes to cross-check during disclosure that it's checked, but rather, to understand the processes to make sure disclosed information (e.g. via CCADB, via the website, etc) is correct.
But that's ultimately a question for Ben and Kathleen, as well as other root programs, which rely on the CCADB to understand the state of all CAs in their program.
Our current CP/CPS covers both TLS server certificates and certificates for other applications like AATL certificate you mentioned. In these certificate types only “TLS / SSL Certificate” and “Device Certificate” have the id-kp-serverAuth and are subjected to compliance with the Baseline Requirements. Although it is indeed confusing from the naming, but the requirements for “TLS / SSL Certificate” and “Device Certificate”, for example, the description of the identity authentication process (3.2.2), are the same in the CP/CPS. The name “Device Certificate” was originally intended for devices with embedded web server (e.g. NAS) and are distinguished at the business level, thus the different assurance levels in the CP/CPS. But then because they are both TLS server certificates by definition of the Baseline Requirements and root program requirements, we do not really distinguished between these two types of certificate. To avoid confusion, we are planning to combine them into only “TLS / SSL Certificate” in future version of CP/CPS.
It's good to hear there are updates. However, I think the question is this:The BRs (1.7.0) required that:The extension MUST contain one or more policy identifiers that indicate adherence to and compliance with
these Requirements. CAs MUST either use a CA/Browser Forum identifier reserved for this purpose or MUST
use a policy identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement
to indicate the Certificate's compliance with these Requirements.The issuing CA SHALL document in its Certificate Policy or Certification Practice Statement that the
Certificates it issues containing the specified policy identifier(s) are managed in accordance with these
Requirements.That is, there's a specific requirement to document that the specified policy identifier is managed according to the Baseline Requirements. In Version 1.5, Dated 2020/01/30, of the Global CA, I couldn't find such documentation in Section 1.2, except for the OID 2.23.140.1.2.2. It's certainly true that Section 2.2 and 9.15 make reference to general compliance, but it doesn't seem fair to generalize. That's because TWCA asserts several types of certificates; for example, in Section 1.4.1 1(4), it lists testing certificates, which clearly don't comply with the Baseline Requirements because TWCA notes that "neither this CA nor the RA will implement subscriber identity authentication in any form."Similarly, in Section 3.1.1, (1) TLS / SSL certificate is a distinct listing than (4) Device Certificate, same as in Section 4.3.1 (1 and 3). Similarly, Section 4.3.1 does not require the information of the "SSL Digital Certificate Application Form" for Device Certificates.My point is that it does not seem anything in the CP/CPS meets the requirement of the BRs, namely, that certificates containing the specified policy identifier(s) are managed in accordance with the Baseline Requirements. It seems that in order for that conclusion to be reached, either all the disclosed policies in the CP/CPS should be assumed to be compliant with the BRs (at which point, all the AATL and S/MIME certificates are misissued, because they're not TLS server certificates, and a BR compliant OID for subscriber certificates means it's a TLS certificate) _or_ that only those explicitly disclosed as compliant (the BR policy OID) complied with BRs 1.7.0.I realize that the most likely issue here is that this is a documentation/translation issue, and thus may seem minor. However, the risk, for Relying Parties, is that it's impossible to tell whether TWCA "intended" to indicate compliance or whether it actually intended to indicate non-compliance. If, for example, it misissued a "Device Certificate", could TWCA argue that it disclosed, in its CP/CPS, that such Device Certificates weren't compliant with the BRs, therefore any issues caused are the Relying Party's fault? That's why the precision matters: to make it clear that there's no "loophole" being intended, and this is why the BRs require the explicit disclosure/commitment, so that it's clear that the CA is guaranteeing such certificates will comply. This may seem a hypothetical risk, but there have been several incidents in the past where CAs have argued such (either by omitting elements from the scope of their audit, or attempting to carve out via their CP/CPS), hence the concern.