On Wed, Nov 3, 2021 at 4:22 AM Hao-Chun Li <[email protected]> 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. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGH0fcpmTRR%3D5AJ3upbVGrPQDYpnenecCZbQu0CpNMsnw%40mail.gmail.com.
