Ryan Sleevi 在 2021年11月3日 星期三下午11:08:12 [UTC+8] 的信中寫道：
> 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 "Draft" versions are really official publications approved by our PMA that has undergone the required procedures. They are effective for CA operations and WebTrust audits from the date of publication so, for example, the audit reports for 2019 period ( https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238800) did list the "Draft" versions in the audit scope. We used the word "Draft" only to distinguish between versions that have a competent authority approval number and the versions that do not. We have communicated this issue with Mozilla previously when updating annual audit reports, and agreed that the "Draft" CP/CPS are acceptable providing that they are officially published by the CA and consistent with the audit reports, and thus the procedure in BR 9.16.3 was not involved. We understand the word "Draft" is confusing and are planning to adopt a versioning scheme that the approval status will be denoted by version numbers, deprecating the use of the word "Draft". > 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. > We have considered the repository on our website as the authoritative repository for publication of information required by Section 2.2 of the BR. But as you mentioned, it is also required by Mozilla Root Store Policy to keep information on CCADB up-to-date. We have followed CCADB updates posted on this group and updated the information on CCADB, but we did not include updating CCADB in the procedure of publication of new CP/CPS versions. We will file the incident report of failure to keep the information on CCADB up-to-date, and will include updating CCADB as part of our publication procedure of the CP/CPS. > 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. > It is true that after incorporating multiple certificate types into the CP/CPS, it is currently unclear which types of certificate are intended to be in compliance with the BR and which are not, and thus not meeting the requirement to document which policy identifier is managed according to the BR. We will file the incident report regarding this issue and resolve this issue in the next version of the CP/CPS. We have also been working on migration to 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. TWCA has committed to comply with all the requirements. We appreciate all issues and concerns raised in this discussion and carefully review all of them, and will improve our documentation and practice in the future. -- 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/50b4a400-04c3-492e-8529-f3347ad63374n%40mozilla.org.
